One way to make the OFBiz Form/Screen/etc widgets more useful and extensible
would be to take another step beyond what Jacopo did a number of years ago with
the FTL macros to produce HTML/CSV/XML/etc.
The current implementation in OFBiz parses the XML file into Java classes and
then when rendering generates macro calls to pass the parameters (XML attribute
values, etc) to the FTL macros. A more flexible and extensible approach is to
use the FTL XML processing features directly instead of going through Java
classes. With this approach adding an attribute or support for a whole new
element in the widget XML files is just a matter of adding it to the FTL macros
that process XML elements.
This is the approach that Moqui Framework uses and it makes it much easier to
improve the supported elements in the framework itself, and for users to add
their own elements without touching any framework code or templates (using a
FTL macros file that includes and then overrides and/or expands the XML
processing macros). For example the FTL macro for processing the "text-area"
element for a form field looks like this (from the DefaultScreenMacros.html.ftl
file; this of course has some Moqui-specific stuff in it, but the general
pattern would be the same in OFBiz):
<#macro "text-area">
<textarea name="<@fieldName .node/>" cols="${.node["@cols"]!"60"}"
rows="${.node["@rows"]!"3"}"<#if .node["@read-only"]!"false" == "true">
readonly="readonly"</#if><#if .node["@maxlength"]?has_content>
maxlength="${.node["@maxlength"]}"</#if> id="<@fieldId .node/>"<#if
.node?parent["@tooltip"]?has_content>
title="${.node?parent["@tooltip"]}"</#if>>${sri.getFieldValueString(.node?parent?parent,
.node["@default-value"]!"", null)?html}</textarea>
</#macro>
As you can see there are no parameters to the FTL macro, it just uses the
built-in ".node" variable that FTL makes available when processing XML elements
to get attributes, child elements, parent elements, etc.
This is still server-side HTML generation, but would make the tool more
flexible. The current approach in OFBiz supports users changing the text output
and could actually be used to drive files that are used for client-side HTML
generation, this just makes it a bit easier to do so and to use the widget XML
files for more instead of having to revert to plain FTL files or some other
tool for the UI (and doing so for the entire screen/form/etc as opposed to just
doing so for certain complex parts of it).
Another enhancement is some simple tags to drop in HTML in various places (FTL
templates or whatever). This can currently be done in OFBiz in various parts of
screen widgets, but for form widget fields and other places it would be useful.
-David
On Jan 6, 2014, at 10:09 AM, Ean Schuessler <e...@brainfood.com> wrote:
> I agree that we should migrate FTL templates to ofbiz widgets for the sake
> of consistency throughout the interfaces. However, I do have to say that
> I would not use form widgets to develop a customer facing site. At this
> point, Brainfood is pretty much at a consensus that we do not want to do
> "page template" oriented development in the server at all. When you look at
> applications like Google Maps it becomes clear that the "send post, alter
> state, regenerate and send page" workflow is incredibly limited. The future
> seems to look a lot more like applications written in Javascript that
> generate HTML directly in the browser.
>
> So, for us, the important feature is the JSON-RPC interface for this remote
> applications. It would be genuinely interesting if we could write a client
> side form widget interpreter that would delegate generation of the interface
> to the client side and then supply the "action" interface via AJAX. That is
> something we would be very interested in.
>
> Refactoring the widget generation code to support greater modularity in the
> HTML
> could be another target of such an effort. I made some modest efforts towards
> a Bootstrap based OFBiz theme and I found it difficult to make progress with
> the
> current setup.
>
> ----- "Gavin Mabie" <kwikst...@gmail.com> wrote:
>
>> It appears that the citing of Drupal/WordPress/Magento solicited quite
>> a
>> lot of comment. It's a side issue really and whether some houses
>> prefer to
>> integrate existing solutions is besides the point. More importantly,
>> most
>> commentators would agree that theme developement in Ofbiz does require
>> more
>> attention. The vast majority of threads on this ML focuss on backend
>> business rules and processes. That in itself is not a problem - if
>> you
>> regard Ofbiz as a Framework only. It only means that, as far as
>> frameworks
>> go, we need a better framework for theming as well. This will
>> encourage
>> more participation from developers who have more of a front-end
>> orientation. I would support a drive towards better "themeability"
>> in
>> 2014. In this regard I would like to suggest that we take a look at
>> the
>> VisualThemeResource entity which currently is currently poorly
>> defined.
>>
>> Gavin
>
> --
> Ean Schuessler, CTO
> e...@brainfood.com
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com
