Thank you Mathieu and Nicolas for your remarks They help me identify the highest priority tasks...
some comments in line Le 30/12/2019 à 17:43, Nicolas Malin a écrit : > 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. Currently, without portal-portlet, it's necessary to have a functional developer with its development environment to change some screen parameters, or page organization. Parameters available are not easily readable. With current PortalPage tools, I have already seen some ProductOwner/keyUsers test some solutions alone before choosing the right one (for them), it's very efficient for functional consultant. > > 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. You are totally right, and clearly my next priority will be to check if I find a Portal-Portlet configuration feature that I can't easily achieve with "classical" screen / decorator. If I find one, I will ask you how to solve the issue, because I already assume it will be possible. ;-) > > 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? That's a part of my proposal, and your implementation proposition give me a better idea of how to present it.. Well, first of all. I will re-uses portalPage, column, portlet, attribute entities to be able to design a short POC. I'm not sure to generate the xml directly, but something similar; the goal being a ready-to-use XML In the second stage This will involve identifying the screens that can be used as a "component" (in a GUI point of view) >>