Reflexion on extend Widget Renderer

[Malin Nicolas <ma...@librenberry.net>]

Hello,

I work on little POC to extend the screen widget macro freemarker with 
customer dedicated attribute to help the creation of specific renderer.

My first step was going to pass any parameters to the macro library 
without modify the MacroFormRenderer.
To realise this, I add a path attribute on all rendered elements 
(extParams) that converted a Map to a String for the macro call and 
reverted to Map during macro process. After the information contains on 
adding element would be rendered directly on the specific provider macro

Like this on Display field element :
+++ src/org/ofbiz/widget/form/MacroFormRenderer.java    (copie de travail)
@@ -218,6 +218,8 @@
          sr.append(modelFormField.getWidgetStyle());
          sr.append("\" alert=\"");
          sr.append(modelFormField.shouldBeRed(context) ? "true" : "false");
+        sr.append("\" extParams=\"");
+        sr.append(UtilMisc.toMap("my", "map with my").toString());
          if (ajaxEnabled) {
              String url = inPlaceEditor.getUrl(context);
+++ templates/htmlFormMacroLibrary.ftl    (copie de travail)
@@ -23,7 +23,7 @@
    </#if>
  </#macro>

-<#macro renderDisplayField type imageLocation idName description title 
class alert inPlaceEditorUrl="" inPlaceEditorParams="">
+<#macro renderDisplayField type imageLocation idName description title 
class alert extParam inPlaceEditorUrl="" inPlaceEditorParams="">
    <#if type?has_content && type=="image">
      <img src="${imageLocation}" alt=""><#lt/>
    <#else>
@@ -45,6 +45,10 @@
        </script><#lt/>
      </#if>
    </#if>
+  <#if extParams?has_content> OK ExtParams present
+      <#assign extParamsMap = 
Static["org.ofbiz.base.util.StringUtil"].toMap(extParams)>
+      <#if extParamsMap.my?has_content>${extParamsMap.my}</#if>
+  </#if>
  </#macro>

Of course the last example to use the extParams would be never present 
on ofbiz ootb.

The next step would be build automatic the map from the xsd definition. 
An ofbiz provider can be extend the *-widget xsd and the macro renderer 
search the new element to adding on path attribute

I see two solutions :
1. By prefixed attribute
<field>
     <display ext-key1="value1"/>
</field>

2. Dedicate sub-element
<field>
     <display>
         <extend key1="value1">
            <my-display-sub-element/>
         </extend>
     </display>
</field>

It's possible to support the both solution.
If you have an other idea (I'm not a xsd hacker)

I just started my thinks on this subject so if you have an other idea, 
I'm really open !

Re: Reflexion on extend Widget Renderer

[Adrian Crum <ad...@sandglass-software.com>]

I think I have a better approach:

1. Make the widget models more generic. Every widget contains a Map of 
attributes and a List of child widgets. This will enable easy extension 
by add-on components. Existing model accessor methods will be preserved 
for those cases where you want parsed/converted types instead of plain 
Strings.

2. Have all widget models implement the DOM interfaces. This will enable 
easy model navigation using XPath or FreeMarker's XML navigation 
features. Mutative DOM methods will throw UnsupportedOperationException 
so the models will be thread-safe.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 3/20/2014 10:38 AM, Malin Nicolas wrote:
> Hello,
>
> I work on little POC to extend the screen widget macro freemarker with
> customer dedicated attribute to help the creation of specific renderer.
>
> My first step was going to pass any parameters to the macro library
> without modify the MacroFormRenderer.
> To realise this, I add a path attribute on all rendered elements
> (extParams) that converted a Map to a String for the macro call and
> reverted to Map during macro process. After the information contains on
> adding element would be rendered directly on the specific provider macro
>
> Like this on Display field element :
> +++ src/org/ofbiz/widget/form/MacroFormRenderer.java    (copie de travail)
> @@ -218,6 +218,8 @@
>           sr.append(modelFormField.getWidgetStyle());
>           sr.append("\" alert=\"");
>           sr.append(modelFormField.shouldBeRed(context) ? "true" :
> "false");
> +        sr.append("\" extParams=\"");
> +        sr.append(UtilMisc.toMap("my", "map with my").toString());
>           if (ajaxEnabled) {
>               String url = inPlaceEditor.getUrl(context);
> +++ templates/htmlFormMacroLibrary.ftl    (copie de travail)
> @@ -23,7 +23,7 @@
>     </#if>
>   </#macro>
>
> -<#macro renderDisplayField type imageLocation idName description title
> class alert inPlaceEditorUrl="" inPlaceEditorParams="">
> +<#macro renderDisplayField type imageLocation idName description title
> class alert extParam inPlaceEditorUrl="" inPlaceEditorParams="">
>     <#if type?has_content && type=="image">
>       <img src="${imageLocation}" alt=""><#lt/>
>     <#else>
> @@ -45,6 +45,10 @@
>         </script><#lt/>
>       </#if>
>     </#if>
> +  <#if extParams?has_content> OK ExtParams present
> +      <#assign extParamsMap =
> Static["org.ofbiz.base.util.StringUtil"].toMap(extParams)>
> +      <#if extParamsMap.my?has_content>${extParamsMap.my}</#if>
> +  </#if>
>   </#macro>
>
> Of course the last example to use the extParams would be never present
> on ofbiz ootb.
>
> The next step would be build automatic the map from the xsd definition.
> An ofbiz provider can be extend the *-widget xsd and the macro renderer
> search the new element to adding on path attribute
>
> I see two solutions :
> 1. By prefixed attribute
> <field>
>      <display ext-key1="value1"/>
> </field>
>
> 2. Dedicate sub-element
> <field>
>      <display>
>          <extend key1="value1">
>             <my-display-sub-element/>
>          </extend>
>      </display>
> </field>
>
> It's possible to support the both solution.
> If you have an other idea (I'm not a xsd hacker)
>
> I just started my thinks on this subject so if you have an other idea,
> I'm really open !