Hi Nicolas, Why do you need to resolve some configurations dynamically? Can you provide a concrete example to something you are facing which requires this?
Cheers, Taher Alkhateeb On Wed, Feb 8, 2017 at 12:06 AM, Nicolas Malin <[email protected]> wrote: > Hi, > > After continued my work on common-theme to refactoring UI interface, I > found a limitation with the current system. > > At this time, on many case we resolve some widget configuration directly > from a property call on widget.property file. > > If you check the string : '<property-to-field resource="widget"' or > 'getPropertyValue("widget"' on trunk we are more than one hundred call. > > But to be more flexible with the theme, I need to resolve dynamically some > configuration like the ftl template location and I'm locked. > > After some reflexion, I tried to resolve the configuration by the theme > but this appear like just a patch and not a solution. > > I think we need a dedicate class to manage theses widget configurations on > the user context, like we have the dispatcher for soa, the delegator for > the data, security (for security), we can have an object like widgetTheme > instantiate by an xml definition in each theme. > > It would be a referent to resolve all widget configuration that the screen > renderer need, always present or quickly build with default value if it is > required and why not help to define some specific element dedicate for a > theme. > > It's an open discussion, just to understand on what foot i need to dance :) > Nicolas > -- > [image: logoNrd] <https://nereide.fr/> > Nicolas Malin > The apache way <http://theapacheway.com/> : *Openness* Technical > decisions are made publicly > [email protected] > 8 rue des Déportés 37000 TOURS, 02 47 50 30 54 > Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way > <http://theapacheway.com/>|ofbiz-fr <http://www.ofbiz-fr.org/>|réseau LE > <http://www.libre-entreprise.org/> >
