tei-publisher-app issueshttps://gitlab.existsolutions.com/tei-publisher/tei-publisher-app/-/issues2019-09-12T17:18:06Zhttps://gitlab.existsolutions.com/tei-publisher/tei-publisher-app/-/issues/190migrate to Polymer 32019-09-12T17:18:06ZJoern Turnermigrate to Polymer 3The following list reflects the findings so far that are necessary or advisable for a complete, extensible and scalable migration.
First a list of shortcomings with the firsts componentized version:
* we use a central dependencies-dev ...The following list reflects the findings so far that are necessary or advisable for a complete, extensible and scalable migration.
First a list of shortcomings with the firsts componentized version:
* we use a central dependencies-dev file to list all UI resources of the map. This means we are loading all or nothing which results in a rather large initial download
* the pubsub implementation has some issues or cannot fully cover our needs. We'll already decided to go for polymer-redux here
* by centralizing the import it is rather unclear what is actually depended
* the current version is not a single-page app which may lead to some complications with the toolchain (polymer-cli, modulizer etc.) which rather expects this pattern
# move to best practices
Following practices are considered good practice when developing Polymer apps:
1. follow PRPL pattern to quickly load initial app, precache needed resources and lazy load optional routes.
1. use single-page pattern with routing for individual views
1. import dependencies in the respective component
1. use unidirectional data flow for view synchronization
# dealing with third-party components
Third-party components must be upgraded to their respective Polymer 3 versions. There is NO way to make Polymer2 run in paralell with Polymer3.
If no updated version exists for a component we can decide wether to migrate it ourselves if no alternatives exist on webcomponents.org. Migrations might be contributed back as pull requests or we decide to host a fork ourselves.
# polymer build step
The new resource loading with JS modules brings in 'named packages'. These are prefixed with '@' (e.g. @polymer). However these modules cannot be resolved by the browser at runtime. For this to work
relative pathes with './' or '../' must be used. The modulizer can output the right pathes. However
there are some pathes inside of Polymer itself that use the named module notation that will fail at runtime.
To circumvent this issue a single build step can be used to expand the references in @polymer module. However then the app must be served with that compiled version which would cause certain necessary adaptions of our current deployment (creation of xars, gulp integration).
An alternative might be the use of a specific controller.xql rule that matches all pathes starting with 'components/@' and redirecting those to 'components/node_modules/@[modulename]
Joern TurnerJoern Turnerhttps://gitlab.existsolutions.com/tei-publisher/tei-publisher-app/-/issues/151Styling views via external CSS?2018-08-30T17:11:10ZWolfgangStyling views via external CSS?Because text views are now loaded via `pb-view`, global CSS styles have no effect because the webcomponent is completely encapsulated. This has many benefits (because we can show completely disparate documents on one page without interfe...Because text views are now loaded via `pb-view`, global CSS styles have no effect because the webcomponent is completely encapsulated. This has many benefits (because we can show completely disparate documents on one page without interference), but some downsides as well. Previously our recommendation was:
1. styles which reflect the original structure or semantics of the document (e.g. highlights, emphasis, deletions, additions ...) should be defined in the ODD (e.g. bold, small-caps, underline ...)
2. styles which apply to the appearance of the document in general should be defined in external stylesheets (because designing them is the job of the web designer, not the editor)
With our switch to polymer, 2. is no longer possible and the only means to apply styles is via the ODD.
Possible solutions:
1. add a property to `pb-view` to allow an external style module to be imported dynamically. I'm sure this is possible but I don't know if it is desirable @joern?
2. extend the ODD to support global styles to be defined somewhere in teiHeader (@magda where?) and include those styles into the generated css
I lean towards solution 2 as it appears much cleaner to me. The encapsulation of styles would be preserved and everything applying to a particular type of document would stay in one place. Downside: designers would need to look into the ODD.Version 4.0https://gitlab.existsolutions.com/tei-publisher/tei-publisher-app/-/issues/140options to evolve app generation2018-09-21T09:04:03ZJoern Turneroptions to evolve app generation# App generation in Web Components age
## what is 'App generation'
'App generation' (AG) is available as 'App Generator' from the admin menu of TEI-Publisher.
## what is discussed in this paper?
This discussion is about how to evolve...# App generation in Web Components age
## what is 'App generation'
'App generation' (AG) is available as 'App Generator' from the admin menu of TEI-Publisher.
## what is discussed in this paper?
This discussion is about how to evolve the AG. There are certainly different aspects mixing up in the current layout that need further work.
## what is the purpose of the AG?
Seems to be an obvious question but also raises some questions in the way it currently exists.
Naively the purpose is to create a website for publishing text in some form or another. It can be seen as a website generator.
But when you generate a site you actually get more than the website. For logged-in users there is the possibility to edit and manage odd-files that are the basis for the various text representations the site uses (Html, PDF, ePub). It can be argued that this is actually a separate app (the one that initially creates a site plus the odd editing (in a broad sense).
## what needs improvement?
The abovementioned two-fold nature of an generated app also has implications on the layout. A website does not follow the same principles as an app regarding layout or structuring of the navigation.
I the Material Design world e.g. there no top-navigation as found in websites (and generated by AG currently). Of course the app can integrate into some website view (as is the case now) but this creates issues with responsiveness and the menu might break if there are more links. In contrast a standalone app in Material Design uses usually a left drawer navigation to switch between views.
So, here a little mismatch exists that should be resolved.
## separate generated site from publisher app?
I consiously used a question mark here. Given the above points it might make sense to completely separate out the functionality of the publisher app.
Everything that deals with:
* creating an odd
* editing an odd
* switching the odd for a document
* uploading an odd
* regenerting an odd
* update index
* recompile odd
* generate application
would go into a standalone app that uses a Material Design (Polymer app-layout) layout and give us a working frame for a responsive and even mobile-ready application.
Furthermore i can imagine that the separation into a *generating* and *generated* part is easier to understand when using the publisher. A person with access to the Publisher App would deal with the app in one window (tab) and (re)generate the publication at will. If a user publishes more than one publication with Publisher there would still be just one copy of the app needed. Some further workflow support might be easier to integrate 'when looking at an publication from the outside'.
The separation of concerns would lead to smaller apps and should also be easier to maintain.
For me currently it's not totally obvious which technical implications this creates. So this is certainly an aspect to be considered when making such a change.
## conclusion
First of all we should clarify if the above is valid and a separation makes sense. I'd suggest to vote up or do an '+1' comment to signal your view of things.
I brought this to the table as this has been discussed before several times here in Berlin in some personal talks and it at least seemed to be a valid topic which we should handle now as we're in the process of introducting web components into publisher.