There are two problems with using DOM trees in OFBiz:
1. They consume a lot of memory. Keep in mind the entire XML file is
kept in memory, not just the bits you are interested in.
2. They are not thread-safe.
I did some refactoring a while ago where I replaced that approach with
a thread-safe approach. But that was done in other parts of the
framework, not in the screen widgets.
-Adrian
Quoting "David E. Jones" <d...@me.com>:
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
