Re: PortalPage / Portlet / parameters : SGBD versus XML file

[Olivier Heintz <ho...@apache.org>]

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)



>>