ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Malin <nicolas.ma...@nereide.fr>
Subject Re: [DISCUSSION] Widget refactoring, create a new configuration object ?
Date Tue, 14 Feb 2017 07:13:39 GMT
Hello Taher,

The better example come from resolve the freemarker template.

Currently we have this on MacroScreenViewHandler :

         String screenMacroLibraryPath = 
UtilProperties.getPropertyValue("widget", getName() + ".screenrenderer");
         String formMacroLibraryPath = 
UtilProperties.getPropertyValue("widget", getName() + ".formrenderer");
         String treeMacroLibraryPath = 
UtilProperties.getPropertyValue("widget", getName() + ".treerenderer");
         String menuMacroLibraryPath = 
UtilProperties.getPropertyValue("widget", getName() + ".menurenderer");

For the common-theme, we can change the library location to surcharge it 
by a theme, so I set configurable the the properties file.
But do to that, we need to know the Theme, and with the theme define new 
data for define the visual theme.
After that, we need to change all call like this :
* CMSEvent.java : FormStringRenderer formStringRenderer = new 
"screen.formrenderer", delegator), request, response);
* FoPrintServerEvent.java : ScreenStringRenderer screenStringRenderer = 
new MacroScreenRenderer(EntityUtilProperties.getPropertyValue("widget", 
"screen.name", dctx.getDelegator()), 
EntityUtilProperties.getPropertyValue("widget", "screen.screenrenderer", 

My suggest would be write a class dedicate to the prepare the screen 
engine throw the theme definition and replace VisualThemeResources data 
by a xml definition for each theme. The class instanciation would 
beinitialize at the top level like the dispatcher and delegator on the 
user session and It would be more simple to manage the different 
properties than the currently case.

And I'm sure we can found some other case cover by this class :)


Le 08/02/2017 à 12:38, Taher Alkhateeb a écrit :
> 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 
> <nicolas.malin@nereide.fr <mailto:nicolas.malin@nereide.fr>> 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
>     -- 
>     logoNrd <https://nereide.fr/>
>     	Nicolas Malin
>     The apache way <http://theapacheway.com/> : *Openness* Technical
>     decisions are made publicly
>     information@nereide.fr <mailto:information@nereide.fr>
>     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/>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message