[
https://issues.apache.org/jira/browse/OFBIZ-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882286#comment-13882286
]
Jacques Le Roux commented on OFBIZ-5040:
----------------------------------------
Let me clarify. To develop *backend UIs* in OOTB OFBiz, from file level, you
start with menu widgets, which call controllers, themself calling screen
widgets (with either actions or groovy scripts) and either form widgets or
Freemarker templates. So what are we are comparing here are the leaves: form
widgets and Freemarker templates. Note that screen widgets share (at least)
actions and styles with form widgets.
Though they are surely OFBiz specific, I don't agree form widgets have a steep
learning curve. In my opinion, if you use an XML auto-completer editor, they
actually are even easier to use than Freemarker. Moreover there are plenty of
good examples OOTB, wich by construction uses best practices. Then, if you
refer to ftl templates in OFBIz you are never sure to get best practices, worse
there are currently a lot of faulty practices in them.
One thing you don't have intrinsically with macros is consistency. If you
encourage people to use macros in the context of OFBiz OOTB, you can be sure
you will get *entropy* (see what we have now). Not because of macros
themselwes, which I agree are good in ftl context, should be used more, and
more could be added to simplify frontend developers lifes. But because of the
context where they will be used. The definitive advantages you have with form
widgets is it forces people in a design framework which guarantees
*consistency*. You have also not to learn/remember tons of macros, they are
used underneath. A contrario, see my list below "problems with Freemarker and
macros".
Let me recall the advantages and add new to my list. Why should form widgets be
preferred in backend under freemarker templates?
* they are ready to use
* they have been already well thought out
* they guarantee *consistency*
* they guarantee legibility (generated and well indented HTML)
* they are stable and reliable
* more can be added[1]
* You have not to learn/remember tons of Freemarker macros
[1] I wish I had the time to hide the way I introduced the dependent and
multiples drop-downs, like we did when layering lookups.
The problems with Freemarker and macros, as I see them currently:
* no good editors with auto-completion (barely for Freemarker, none for macros)
* no way to have a kind of API documentation (like XSDs are)
* hard to keep the generated HTML legible (indentation) while keeping ftl
sources also well indented
There are few cases (to be demonstrated for bakend UIs) where form widgets are
not enough. Then you can always use Freemarker as fallback (should be by
derogation in backend).
Again, this is only for OOTB backend. People are of course free to use
Freemarker for their custom projects ;)
Before closing, quoting you:
{quote}
If they are easy to use (like <@ofbiz.widget>Lalalala</@ofbiz.widget>) it is
more likely for others to use them as well.
{quote}
Do you really believe, this is possible? For instance compare
{code}
<td width="26%" align="right"
class="label">${uiLabelMap.ProductPrimaryParentCategory}</td>
<td> </td>
<td width="74%">
<@htmlTemplate.lookupField
value="${(productCategory.primaryParentCategoryId)?default('')}"
formName="productCategoryForm" name="primaryParentCategoryId"
id="primaryParentCategoryId" fieldFormName="LookupProductCategory"/>
</td>
{code}
with
{code}
<field name="productCategoryId" title="${uiLabelMap.ProductProductCategoryId}">
<lookup target-form-name="LookupProductCategory"/>
</field>
{code}
I fear abuse of macros lead/continue to hard to maintain code.
OK, these are Paul's and my opinions, what are yours?
> Backend widget & application HTML clean-up
> ------------------------------------------
>
> Key: OFBIZ-5040
> URL: https://issues.apache.org/jira/browse/OFBIZ-5040
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL APPLICATIONS
> Reporter: Paul Piper
> Labels: html, webapp, widget, widgetrendering
>
> I am sure that this is a common thing to know: the current backoffice
> application relies heavily on widgets. This is good, but the current
> standard-html-structure is not flexible enough and often lacks proper w3c
> implementation.
> To make matters worse, you can often find applications avoiding widgets at
> all and rather overriding the standards with custom ftl implementations. It
> is these customizations that break the html on numerous screens and make it
> difficult, if not tedious to create new themes for the backoffice.
> This task is hence to:
> * Find a consensus on a new widget standard
> * Go over each of the application ftls and convert these to the new standard
> * Recreate the themes and simplify/clean-up special rules
> Since redoing the theme is a rather large task, we should consider to add an
> additional css for now which stylises the replacement html instead of working
> with the old.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
