Re: New widget renderers

[Jacopo Cappellato]

It is very easy to disable them: just revert the change I did in rev. 767101

Jacopo

On Apr 21, 2009, at 12:27 PM, Hans Bakker wrote:

as long we have a way to disable them ?

i use the trunk version in production. At the moment the dust is a bit

some more problems again.....so let me know not to use them...

Regards,
hans

On Tue, 2009-04-21 at 12:12 +0200, Jacopo Cappellato wrote:

settling down so i upgraded my company version. I am sure this will give

During the last  2 weeks I did some tests (and fixes) for the macro
renderers and now, with rev. 767101, I have decided to enable them so
that the whole community will help to test them :-)

Please report any bug you find, or help enhance the output, and feel
free to ask if you need more details about the structure of the new
renderers.

Thanks,

Jacopo


On Apr 5, 2009, at 1:24 PM, guo weizhan wrote:

Hi Jacopo

Thanks for your effort, I'm waiting for test result:) .

Guo

2009/4/5 Jacopo Cappellato <jacopo.cappell...@hotwaxmedia.com>

Thank you, Scott,

actually our lunch time conversations in SLC have been insiping :-)

By the way I am going to create new tasks for the work that still
needs to
be done.

Jacopo


On Apr 3, 2009, at 10:52 AM, Scott Gray wrote:

Hi Jacopo

Thanks for all your hard work, it's great to hear that this effort
has
come along so far and I will certainly take a look over the
weekend and see
what I can do to help out.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 2/04/2009, at 8:21 PM, Jacopo Cappellato wrote:

Hi all,

renderers (one for the forms and one for the screens) that have
been
implemented recently.
The idea is that you can define new view handlers (for screen
widgets) by
setting their properties in the widget.properties file (no more
java code is
required). Then the actual output produced by each renderer is
defined by
Freemarker macros (the new renderer actually just prepares the
macro call)
defined in macro libraries ftl files (under widget/templates).
We have already created renderers for the html, xml and text
output.
This should simplify the maintenance of our widget code (less
code, no
java code mixed with html/xml/etc...), it will make it easier to
create new
renderers or customize the existing ones (you can change the
macros on the
fly and see the result without recompiling or restarting OFBiz).
This has been a collaborative effort: Anil Patel explained me his
idea,
then I discussed it with Scott Gray, I started implementing a
proof of
concept, then David Jones provided directions to fix some of the
problems I
faced; then I completed the work for the xml and text renderers
(that are
simple ones) in order to provide a real world example and I have
submitted
my patch in OFBIZ-1235; then Guo Weizhan continued my work and
implemented
the (very complex) html renderers that I committed during the
last few days
(thanks Guo!).

You can easily test the work by enabling the new renderers
replacing the
following lines in the common-controller.xml:

 <handler name="screen" type="view"
class="org.ofbiz.widget.screen.ScreenWidgetViewHandler"/>
 <handler name="screenxml" type="view"
class="org.ofbiz.widget.screen.ScreenXmlViewHandler"/>
 <handler name="screentext" type="view"
class="org.ofbiz.widget.screen.ScreenTextViewHandler"/>

with these ones:

 <handler name="screen" type="view"
class="org.ofbiz.widget.screen.MacroScreenViewHandler"/>
 <handler name="screenxml" type="view"
class="org.ofbiz.widget.screen.MacroScreenViewHandler"/>
 <handler name="screentext" type="view"
class="org.ofbiz.widget.screen.MacroScreenViewHandler"/>

Next steps:

1) more tests, fixes for the new renderers and macro libraries
(html,
xml, text)

2) make the new html, xml, text macro view handler the default

3) there is still some code (very few lines marked with a FIXME
comment)
in the new renderers that is specific to html; we will have to
clean it and
move everything in the macro libraries

4) removing the old renderers and handlers:
ScrrenTextViewHandler
ScreenWidgetViewHandler
ScreenXmlViewHandler
(all the above are replaced by the new MacroScreenViewHandler)
HtmlFormRenderer
TextFormRenderer
XmlFormRenderer
(all the above are replaced by the MacroFormRenderer)
HtmlScreenRenderer
TextScreenRenderer
(all the above are replaced by the MacroScreenRenderer)

5) implement ftl macro library for fop output and then remove the
fop
handler and renderers

6) implement macro renderer for trees

Please let me know what you think

Jacopo

I am asking you to help to test the new "Macro" widget handler and

--
Antwebsystems.com: Quality OFBiz services for competitive rates

smime.p7s
Description: S/MIME cryptographic signature