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 !
