tei-publisher-app issueshttps://gitlab.existsolutions.com/tei-publisher/tei-publisher-app/-/issues2018-09-21T09:04:03Zhttps://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.