Hello, Ten yearsagoI would've leaned over on a solution to improve on this way, but now with practical field experience I understood that it was a chimera on business production site.
All is currently present on screen-widget.xsd to define easily a screen structure. The scenario “ProductOwner/keyUser/endUser” is already supported, I didn't hear at Néréide for functional developer that they are some difficulties to translate businessspecificationsfromany of theserolesthrough screen definition. Rather than concentrating on adding model layers, we willwin not to let the code grow too much and identify what is really missing on screensand rely on portal page only for caseswhere the end user can edit his own configuration page. I'm more in favor to put away all current portal page out of the framework, keep only one plugin as example and convert them with good practice to help other developersand functional developersto extend the framework. In this way I found the Mathieu'sbelowidea: fun :) Nicolas On 29/12/2019 11:36, Mathieu Lirzin wrote: > Hello Olivier,[...] > > One idea would be to have a specific webtools screen taking the form of > a client-side Javascript program allowing users to compose a screen > graphically and to export it as XML. This would fit the scenario you > describe without the need of adding a general screen configuration > mechanism inside the database. > > What do you think? >
pEpkey.asc
Description: application/pgp-keys
