You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ja...@hotwaxmedia.com> on 2009/04/02 09:21:28 UTC
New widget renderers
Hi all,
I am asking you to help to test the new "Macro" widget handler and
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
Re: New widget renderers: problem
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Ok, I have fixed both the errors reported.
Jacopo
On Apr 22, 2009, at 7:50 AM, Ashish Vijaywargiya wrote:
> I am totally fine with either option Vikas.
> Can you do the needful ?
>
> Thanks !
> --
> Ashish
>
> Vikas Mayur wrote:
>> Ashish, Do you think it would be better to go with the same way as
>> Jacques did for Securing URLs in Freemarker templates, that is
>> creating a separate issue under a parent task.
>>
>> Vikas
>>
>> On Apr 22, 2009, at 10:06 AM, Ashish Vijaywargiya wrote:
>>
>>> For any progress on this issue please refer JIRA issue no. :
>>> *OFBIZ-2337 <https://issues.apache.org/jira/browse/OFBIZ-2337>
>>>
>>> *Post other issues there as well if you find any in future.
>>> Thanks for your cooperation Hans !
>>>
>>> --
>>> Ashish
>>>
>>>
>>
Re: New widget renderers: problem
Posted by Ashish Vijaywargiya <as...@hotwaxmedia.com>.
I am totally fine with either option Vikas.
Can you do the needful ?
Thanks !
--
Ashish
Vikas Mayur wrote:
> Ashish, Do you think it would be better to go with the same way as
> Jacques did for Securing URLs in Freemarker templates, that is
> creating a separate issue under a parent task.
>
> Vikas
>
> On Apr 22, 2009, at 10:06 AM, Ashish Vijaywargiya wrote:
>
>> For any progress on this issue please refer JIRA issue no. :
>> *OFBIZ-2337 <https://issues.apache.org/jira/browse/OFBIZ-2337>
>>
>> *Post other issues there as well if you find any in future.
>> Thanks for your cooperation Hans !
>>
>> --
>> Ashish
>>
>>
>
Re: New widget renderers: problem
Posted by Vikas Mayur <vi...@hotwaxmedia.com>.
Ashish, Do you think it would be better to go with the same way as
Jacques did for Securing URLs in Freemarker templates, that is
creating a separate issue under a parent task.
Vikas
On Apr 22, 2009, at 10:06 AM, Ashish Vijaywargiya wrote:
> For any progress on this issue please refer JIRA issue no. :
> OFBIZ-2337
>
> Post other issues there as well if you find any in future.
> Thanks for your cooperation Hans !
>
> --
> Ashish
>
>
> Hans Bakker wrote:
>>
>> In the ofbiz system when i go to: project -> requestlist
>>
>> and have a certain amount of data in the request list i get the
>> following error in the log:
>>
>> 2009-04-22 11:21:46,123 (http-0.0.0.0-8443-2) [
>> GenericDAO.java:755:INFO ] Ran query in 227 milli-seconds: SELECT
>> CRT.DESCRIPTION, SI.DESCRIPTION, WE.PRIORITY, WE.DESCRIPTION,
>> WE.CREATED_DATE, WE.CREATED_BY_USER_LOGIN, WE.LAST_MODIFIED_DATE,
>> WE.LAST_MODIFIED_BY_USER_LOGIN, CRWE.CUST_REQUEST_ID,
>> CRWE.WORK_EFFORT_ID, CR.CUST_REQUEST_TYPE_ID,
>> CR.CUST_REQUEST_CATEGORY_ID, CR.STATUS_ID, CR.FROM_PARTY_ID,
>> CR.PRIORITY, CR.CUST_REQUEST_DATE, CR.RESPONSE_REQUIRED_DATE,
>> CR.CUST_REQUEST_NAME, CR.DESCRIPTION, CR.MAXIMUM_AMOUNT_UOM_ID,
>> CR.PRODUCT_STORE_ID, CR.SALES_CHANNEL_ENUM_ID,
>> CR.FULFILL_CONTACT_MECH_ID, CR.CURRENCY_UOM_ID, CR.OPEN_DATE_TIME,
>> CR.CLOSED_DATE_TIME, CR.INTERNAL_COMMENT, CR.REASON, CR.CREATED_DATE,
>> CR.CREATED_BY_USER_LOGIN, CR.LAST_MODIFIED_DATE,
>> CR.LAST_MODIFIED_BY_USER_LOGIN, WE.WORK_EFFORT_TYPE_ID,
>> WE.CURRENT_STATUS_ID, WE.LAST_STATUS_UPDATE,
>> WE.WORK_EFFORT_PURPOSE_TYPE_ID, WE.WORK_EFFORT_PARENT_ID,
>> WE.SCOPE_ENUM_ID, WE.PERCENT_COMPLETE, WE.WORK_EFFORT_NAME,
>> WE.SHOW_AS_ENUM_ID, WE.SEND_NOTIFICATION_EMAIL, WE.LOCATION_DESC,
>> WE.ESTIMATED_START_DATE, WE.ESTIMATED_COMPLETION_DATE,
>> WE.ACTUAL_START_DATE, WE.ACTUAL_COMPLETION_DATE,
>> WE.ESTIMATED_MILLI_SECONDS, WE.ESTIMATED_SETUP_MILLIS,
>> WE.ESTIMATE_CALC_METHOD, WE.ACTUAL_MILLI_SECONDS,
>> WE.ACTUAL_SETUP_MILLIS, WE.TOTAL_MILLI_SECONDS_ALLOWED,
>> WE.TOTAL_MONEY_ALLOWED, WE.MONEY_UOM_ID, WE.SPECIAL_TERMS,
>> WE.TIME_TRANSPARENCY, WE.UNIVERSAL_ID, WE.SOURCE_REFERENCE_ID,
>> WE.FIXED_ASSET_ID, WE.FACILITY_ID, WE.INFO_URL,
>> WE.RECURRENCE_INFO_ID,
>> WE.TEMP_EXPR_ID, WE.RUNTIME_DATA_ID, WE.NOTE_ID,
>> WE.SERVICE_LOADER_NAME,
>> WE.QUANTITY_TO_PRODUCE, WE.QUANTITY_PRODUCED, WE.QUANTITY_REJECTED,
>> WE.RESERV_PERSONS, WE.RESERV2ND_P_P_PERC, WE.RESERV_NTH_P_P_PERC,
>> WE.ACCOMMODATION_MAP_ID, WE.ACCOMMODATION_SPOT_ID, WE.REVISION_NUMBER
>> FROM (((OFBIZ.CUST_REQUEST_WORK_EFFORT CRWE INNER JOIN
>> OFBIZ.CUST_REQUEST CR ON CRWE.CUST_REQUEST_ID = CR.CUST_REQUEST_ID)
>> INNER JOIN OFBIZ.WORK_EFFORT WE ON CRWE.WORK_EFFORT_ID =
>> WE.WORK_EFFORT_ID) LEFT OUTER JOIN OFBIZ.CUST_REQUEST_TYPE CRT ON
>> CR.CUST_REQUEST_TYPE_ID = CRT.CUST_REQUEST_TYPE_ID) LEFT OUTER JOIN
>> OFBIZ.STATUS_ITEM SI ON CR.STATUS_ID = SI.STATUS_ID WHERE
>> (CR.STATUS_ID
>> = ?) ORDER BY CR.CREATED_DATE ASC
>> 2009-04-22 11:21:46,167 (http-0.0.0.0-8443-2) [
>> ModelForm.java:1345:INFO ] preparePager: low - high = 0 - 20
>> 2009-04-22 11:21:46,172 (http-0.0.0.0-8443-2) [
>> ModelForm.java:1363:INFO ] preparePager: Found rows = 20
>> 2009-04-22 11:21:46,175 (http-0.0.0.0-8443-2)
>> [ Log4JLoggerFactory.java:96 :ERROR]
>>
>> Macro renderScreenletPaginateMenu has no such argument: lastLinkUrl
>> The problematic instruction:
>> ----------
>> ==> macro renderScreenletPaginateMenu [on line 88, column 1 in
>> component://widget/templates/htmlScreenMacroLibrary.ftl]
>> in user-directive renderScreenletPaginateMenu [on line 1, column 1
>> in
>> Wed Apr 22 11:21:46 ICT 2009]
>> ----------
>>
>> Java backtrace for programmers:
>> ----------
>> freemarker.template.TemplateException: Macro
>> renderScreenletPaginateMenu
>> has no such argument: lastLinkUrl
>> at freemarker.core.Environment.visit(Environment.java:564)
>> at freemarker.core.UnifiedCall.accept(UnifiedCall.java:106)
>> at freemarker.core.Environment.visit(Environment.java:209)
>> at freemarker.core.Environment.include(Environment.java:1482)
>> at
>> org
>> .ofbiz
>> .widget
>> .screen.MacroScreenRenderer.executeMacro(MacroScreenRenderer.java:98)
>> at
>> org
>> .ofbiz
>> .widget
>> .screen
>> .MacroScreenRenderer
>> .renderScreenletPaginateMenu(MacroScreenRenderer.java:835)
>> at
>> org
>> .ofbiz
>> .widget
>> .screen
>> .MacroScreenRenderer.renderScreenletBegin(MacroScreenRenderer.java:
>> 628)
>> at org.ofbiz.widget.screen.ModelScreenWidget
>> $Screenlet.renderWidgetString(ModelScreenWidget.java:396)
>> at
>> org
>> .ofbiz
>> .widget
>> .screen
>> .ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
>> at org.ofbiz.widget.screen.ModelScreenWidget
>> $DecoratorSection.renderWidgetString(ModelScreenWidget.java:676)
>> at org.ofbiz.widget.screen.ModelScreenWidget
>> $SectionsRenderer.render(ModelScreenWidget.java:167)
>> at org.ofbiz.widget.screen.ModelScreenWidget
>> $DecoratorSectionInclude.renderWidgetString(ModelScreenWidget.java:
>> 706)
>> at
>> org
>> .ofbiz
>> .widget
>> .screen
>> .ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
>> at org.ofbiz.widget.screen.ModelScreenWidget
>> $Container.renderWidgetString(ModelScreenWidget.java:292)
>> at
>> org
>> .ofbiz
>> .widget
>> .screen
>> .ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
>> at org.ofbiz.widget.screen.ModelScreenWidget
>> $Container.renderWidgetString(ModelScreenWidget.java:292)
>> at
>> org
>> .ofbiz
>> .widget
>> .screen
>> .ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
>> at org.ofbiz.widget.screen.ModelScreenWidget
>> $Container.renderWidgetString(ModelScreenWidget.java:292)
>> at
>> org
>> .ofbiz
>> .widget
>> .screen
>> .ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
>> at org.ofbiz.widget.screen.ModelScreenWidget
>> $Section.renderWidgetString(ModelScreenWidget.java:227)
>> at
>> org
>> .ofbiz
>> .widget.screen.ModelScreen.renderScreenString(ModelScreen.java:393)
>> at org.ofbiz.widget.screen.ModelScreenWidget
>> $IncludeScreen.renderWidgetString(ModelScreenWidget.java:552)
>> at
>> org
>> .ofbiz
>> .widget
>> .screen
>> .ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
>> at org.ofbiz.widget.screen.ModelScreenWidget
>> $Section.renderWidgetString(ModelScreenWidget.java:227)
>> at
>> org
>> .ofbiz
>> .widget.screen.ModelScreen.renderScreenString(ModelScreen.java:393)
>> at org.ofbiz.widget.screen.ModelScreenWidget
>> $IncludeScreen.renderWidgetString(ModelScreenWidget.java:552)
>> at
>> org
>> .ofbiz
>> .widget
>> .screen
>> .ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
>> at org.ofbiz.widget.screen.ModelScreenWidget
>> $Section.renderWidgetString(ModelScreenWidget.java:227)
>> at
>> org
>> .ofbiz
>> .widget.screen.ModelScreen.renderScreenString(ModelScreen.java:393)
>> at org.ofbiz.widget.screen.ModelScreenWidget
>> $DecoratorScreen.renderWidgetString(ModelScreenWidget.java:646)
>> at
>> org
>> .ofbiz
>> .widget
>> .screen
>> .ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
>> at org.ofbiz.widget.screen.ModelScreenWidget
>> $Section.renderWidgetString(ModelScreenWidget.java:227)
>> at
>> org
>> .ofbiz
>> .widget.screen.ModelScreen.renderScreenString(ModelScreen.java:393)
>> at
>> org.ofbiz.widget.screen.ScreenRenderer.render(ScreenRenderer.java:
>> 129)
>> at
>> org.ofbiz.widget.screen.ScreenRenderer.render(ScreenRenderer.java:92)
>> at
>> org
>> .ofbiz
>> .widget
>> .screen.MacroScreenViewHandler.render(MacroScreenViewHandler.java:
>> 110)
>> at
>> org
>> .ofbiz.webapp.control.RequestHandler.renderView(RequestHandler.java:
>> 781)
>> at
>> org
>> .ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:
>> 533)
>> at
>> org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:
>> 201)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>> at
>> org
>> .apache
>> .catalina
>> .core
>> .ApplicationFilterChain
>> .internalDoFilter(ApplicationFilterChain.java:290)
>> at
>> org
>> .apache
>> .catalina
>> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
>> 206)
>> at
>> org.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:
>> 259)
>> at
>> org
>> .apache
>> .catalina
>> .core
>> .ApplicationFilterChain
>> .internalDoFilter(ApplicationFilterChain.java:235)
>> at
>> org
>> .apache
>> .catalina
>> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
>> 206)
>> at
>> org
>> .apache
>> .catalina
>> .core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
>> at
>> org
>> .apache
>> .catalina
>> .core.StandardContextValve.invoke(StandardContextValve.java:175)
>> at
>> org
>> .apache
>> .catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>> at
>> org
>> .apache
>> .catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>> at
>> org
>> .apache
>> .catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
>> 109)
>> at
>> org
>> .apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
>> 568)
>> at
>> org
>> .ofbiz
>> .catalina
>> .container
>> .CrossSubdomainSessionValve.invoke(CrossSubdomainSessionValve.java:
>> 44)
>> at
>> org
>> .apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
>> 286)
>> at
>> org
>> .apache.coyote.http11.Http11Processor.process(Http11Processor.java:
>> 844)
>> at org.apache.coyote.http11.Http11Protocol
>> $Http11ConnectionHandler.process(Http11Protocol.java:583)
>> at org.apache.tomcat.util.net.JIoEndpoint
>> $Worker.run(JIoEndpoint.java:447)
>> at java.lang.Thread.run(Thread.java:619)
>>
>>
>>
Re: New widget renderers: problem
Posted by Ashish Vijaywargiya <as...@hotwaxmedia.com>.
For any progress on this issue please refer JIRA issue no. : *OFBIZ-2337
<https://issues.apache.org/jira/browse/OFBIZ-2337>
*Post other issues there as well if you find any in future.
Thanks for your cooperation Hans !
--
Ashish
Hans Bakker wrote:
> In the ofbiz system when i go to: project -> requestlist
>
> and have a certain amount of data in the request list i get the
> following error in the log:
>
> 2009-04-22 11:21:46,123 (http-0.0.0.0-8443-2) [
> GenericDAO.java:755:INFO ] Ran query in 227 milli-seconds: SELECT
> CRT.DESCRIPTION, SI.DESCRIPTION, WE.PRIORITY, WE.DESCRIPTION,
> WE.CREATED_DATE, WE.CREATED_BY_USER_LOGIN, WE.LAST_MODIFIED_DATE,
> WE.LAST_MODIFIED_BY_USER_LOGIN, CRWE.CUST_REQUEST_ID,
> CRWE.WORK_EFFORT_ID, CR.CUST_REQUEST_TYPE_ID,
> CR.CUST_REQUEST_CATEGORY_ID, CR.STATUS_ID, CR.FROM_PARTY_ID,
> CR.PRIORITY, CR.CUST_REQUEST_DATE, CR.RESPONSE_REQUIRED_DATE,
> CR.CUST_REQUEST_NAME, CR.DESCRIPTION, CR.MAXIMUM_AMOUNT_UOM_ID,
> CR.PRODUCT_STORE_ID, CR.SALES_CHANNEL_ENUM_ID,
> CR.FULFILL_CONTACT_MECH_ID, CR.CURRENCY_UOM_ID, CR.OPEN_DATE_TIME,
> CR.CLOSED_DATE_TIME, CR.INTERNAL_COMMENT, CR.REASON, CR.CREATED_DATE,
> CR.CREATED_BY_USER_LOGIN, CR.LAST_MODIFIED_DATE,
> CR.LAST_MODIFIED_BY_USER_LOGIN, WE.WORK_EFFORT_TYPE_ID,
> WE.CURRENT_STATUS_ID, WE.LAST_STATUS_UPDATE,
> WE.WORK_EFFORT_PURPOSE_TYPE_ID, WE.WORK_EFFORT_PARENT_ID,
> WE.SCOPE_ENUM_ID, WE.PERCENT_COMPLETE, WE.WORK_EFFORT_NAME,
> WE.SHOW_AS_ENUM_ID, WE.SEND_NOTIFICATION_EMAIL, WE.LOCATION_DESC,
> WE.ESTIMATED_START_DATE, WE.ESTIMATED_COMPLETION_DATE,
> WE.ACTUAL_START_DATE, WE.ACTUAL_COMPLETION_DATE,
> WE.ESTIMATED_MILLI_SECONDS, WE.ESTIMATED_SETUP_MILLIS,
> WE.ESTIMATE_CALC_METHOD, WE.ACTUAL_MILLI_SECONDS,
> WE.ACTUAL_SETUP_MILLIS, WE.TOTAL_MILLI_SECONDS_ALLOWED,
> WE.TOTAL_MONEY_ALLOWED, WE.MONEY_UOM_ID, WE.SPECIAL_TERMS,
> WE.TIME_TRANSPARENCY, WE.UNIVERSAL_ID, WE.SOURCE_REFERENCE_ID,
> WE.FIXED_ASSET_ID, WE.FACILITY_ID, WE.INFO_URL, WE.RECURRENCE_INFO_ID,
> WE.TEMP_EXPR_ID, WE.RUNTIME_DATA_ID, WE.NOTE_ID, WE.SERVICE_LOADER_NAME,
> WE.QUANTITY_TO_PRODUCE, WE.QUANTITY_PRODUCED, WE.QUANTITY_REJECTED,
> WE.RESERV_PERSONS, WE.RESERV2ND_P_P_PERC, WE.RESERV_NTH_P_P_PERC,
> WE.ACCOMMODATION_MAP_ID, WE.ACCOMMODATION_SPOT_ID, WE.REVISION_NUMBER
> FROM (((OFBIZ.CUST_REQUEST_WORK_EFFORT CRWE INNER JOIN
> OFBIZ.CUST_REQUEST CR ON CRWE.CUST_REQUEST_ID = CR.CUST_REQUEST_ID)
> INNER JOIN OFBIZ.WORK_EFFORT WE ON CRWE.WORK_EFFORT_ID =
> WE.WORK_EFFORT_ID) LEFT OUTER JOIN OFBIZ.CUST_REQUEST_TYPE CRT ON
> CR.CUST_REQUEST_TYPE_ID = CRT.CUST_REQUEST_TYPE_ID) LEFT OUTER JOIN
> OFBIZ.STATUS_ITEM SI ON CR.STATUS_ID = SI.STATUS_ID WHERE (CR.STATUS_ID
> = ?) ORDER BY CR.CREATED_DATE ASC
> 2009-04-22 11:21:46,167 (http-0.0.0.0-8443-2) [
> ModelForm.java:1345:INFO ] preparePager: low - high = 0 - 20
> 2009-04-22 11:21:46,172 (http-0.0.0.0-8443-2) [
> ModelForm.java:1363:INFO ] preparePager: Found rows = 20
> 2009-04-22 11:21:46,175 (http-0.0.0.0-8443-2)
> [ Log4JLoggerFactory.java:96 :ERROR]
>
> Macro renderScreenletPaginateMenu has no such argument: lastLinkUrl
> The problematic instruction:
> ----------
> ==> macro renderScreenletPaginateMenu [on line 88, column 1 in
> component://widget/templates/htmlScreenMacroLibrary.ftl]
> in user-directive renderScreenletPaginateMenu [on line 1, column 1 in
> Wed Apr 22 11:21:46 ICT 2009]
> ----------
>
> Java backtrace for programmers:
> ----------
> freemarker.template.TemplateException: Macro renderScreenletPaginateMenu
> has no such argument: lastLinkUrl
> at freemarker.core.Environment.visit(Environment.java:564)
> at freemarker.core.UnifiedCall.accept(UnifiedCall.java:106)
> at freemarker.core.Environment.visit(Environment.java:209)
> at freemarker.core.Environment.include(Environment.java:1482)
> at
> org.ofbiz.widget.screen.MacroScreenRenderer.executeMacro(MacroScreenRenderer.java:98)
> at
> org.ofbiz.widget.screen.MacroScreenRenderer.renderScreenletPaginateMenu(MacroScreenRenderer.java:835)
> at
> org.ofbiz.widget.screen.MacroScreenRenderer.renderScreenletBegin(MacroScreenRenderer.java:628)
> at org.ofbiz.widget.screen.ModelScreenWidget
> $Screenlet.renderWidgetString(ModelScreenWidget.java:396)
> at
> org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
> at org.ofbiz.widget.screen.ModelScreenWidget
> $DecoratorSection.renderWidgetString(ModelScreenWidget.java:676)
> at org.ofbiz.widget.screen.ModelScreenWidget
> $SectionsRenderer.render(ModelScreenWidget.java:167)
> at org.ofbiz.widget.screen.ModelScreenWidget
> $DecoratorSectionInclude.renderWidgetString(ModelScreenWidget.java:706)
> at
> org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
> at org.ofbiz.widget.screen.ModelScreenWidget
> $Container.renderWidgetString(ModelScreenWidget.java:292)
> at
> org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
> at org.ofbiz.widget.screen.ModelScreenWidget
> $Container.renderWidgetString(ModelScreenWidget.java:292)
> at
> org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
> at org.ofbiz.widget.screen.ModelScreenWidget
> $Container.renderWidgetString(ModelScreenWidget.java:292)
> at
> org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
> at org.ofbiz.widget.screen.ModelScreenWidget
> $Section.renderWidgetString(ModelScreenWidget.java:227)
> at
> org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:393)
> at org.ofbiz.widget.screen.ModelScreenWidget
> $IncludeScreen.renderWidgetString(ModelScreenWidget.java:552)
> at
> org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
> at org.ofbiz.widget.screen.ModelScreenWidget
> $Section.renderWidgetString(ModelScreenWidget.java:227)
> at
> org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:393)
> at org.ofbiz.widget.screen.ModelScreenWidget
> $IncludeScreen.renderWidgetString(ModelScreenWidget.java:552)
> at
> org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
> at org.ofbiz.widget.screen.ModelScreenWidget
> $Section.renderWidgetString(ModelScreenWidget.java:227)
> at
> org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:393)
> at org.ofbiz.widget.screen.ModelScreenWidget
> $DecoratorScreen.renderWidgetString(ModelScreenWidget.java:646)
> at
> org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
> at org.ofbiz.widget.screen.ModelScreenWidget
> $Section.renderWidgetString(ModelScreenWidget.java:227)
> at
> org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:393)
> at
> org.ofbiz.widget.screen.ScreenRenderer.render(ScreenRenderer.java:129)
> at
> org.ofbiz.widget.screen.ScreenRenderer.render(ScreenRenderer.java:92)
> at
> org.ofbiz.widget.screen.MacroScreenViewHandler.render(MacroScreenViewHandler.java:110)
> at
> org.ofbiz.webapp.control.RequestHandler.renderView(RequestHandler.java:781)
> at
> org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:533)
> at
> org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:201)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:259)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568)
> at
> org.ofbiz.catalina.container.CrossSubdomainSessionValve.invoke(CrossSubdomainSessionValve.java:44)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> at org.apache.coyote.http11.Http11Protocol
> $Http11ConnectionHandler.process(Http11Protocol.java:583)
> at org.apache.tomcat.util.net.JIoEndpoint
> $Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run(Thread.java:619)
>
>
>
Re: New widget renderers: problem
Posted by Hans Bakker <ma...@antwebsystems.com>.
In the ofbiz system when i go to: project -> requestlist
and have a certain amount of data in the request list i get the
following error in the log:
2009-04-22 11:21:46,123 (http-0.0.0.0-8443-2) [
GenericDAO.java:755:INFO ] Ran query in 227 milli-seconds: SELECT
CRT.DESCRIPTION, SI.DESCRIPTION, WE.PRIORITY, WE.DESCRIPTION,
WE.CREATED_DATE, WE.CREATED_BY_USER_LOGIN, WE.LAST_MODIFIED_DATE,
WE.LAST_MODIFIED_BY_USER_LOGIN, CRWE.CUST_REQUEST_ID,
CRWE.WORK_EFFORT_ID, CR.CUST_REQUEST_TYPE_ID,
CR.CUST_REQUEST_CATEGORY_ID, CR.STATUS_ID, CR.FROM_PARTY_ID,
CR.PRIORITY, CR.CUST_REQUEST_DATE, CR.RESPONSE_REQUIRED_DATE,
CR.CUST_REQUEST_NAME, CR.DESCRIPTION, CR.MAXIMUM_AMOUNT_UOM_ID,
CR.PRODUCT_STORE_ID, CR.SALES_CHANNEL_ENUM_ID,
CR.FULFILL_CONTACT_MECH_ID, CR.CURRENCY_UOM_ID, CR.OPEN_DATE_TIME,
CR.CLOSED_DATE_TIME, CR.INTERNAL_COMMENT, CR.REASON, CR.CREATED_DATE,
CR.CREATED_BY_USER_LOGIN, CR.LAST_MODIFIED_DATE,
CR.LAST_MODIFIED_BY_USER_LOGIN, WE.WORK_EFFORT_TYPE_ID,
WE.CURRENT_STATUS_ID, WE.LAST_STATUS_UPDATE,
WE.WORK_EFFORT_PURPOSE_TYPE_ID, WE.WORK_EFFORT_PARENT_ID,
WE.SCOPE_ENUM_ID, WE.PERCENT_COMPLETE, WE.WORK_EFFORT_NAME,
WE.SHOW_AS_ENUM_ID, WE.SEND_NOTIFICATION_EMAIL, WE.LOCATION_DESC,
WE.ESTIMATED_START_DATE, WE.ESTIMATED_COMPLETION_DATE,
WE.ACTUAL_START_DATE, WE.ACTUAL_COMPLETION_DATE,
WE.ESTIMATED_MILLI_SECONDS, WE.ESTIMATED_SETUP_MILLIS,
WE.ESTIMATE_CALC_METHOD, WE.ACTUAL_MILLI_SECONDS,
WE.ACTUAL_SETUP_MILLIS, WE.TOTAL_MILLI_SECONDS_ALLOWED,
WE.TOTAL_MONEY_ALLOWED, WE.MONEY_UOM_ID, WE.SPECIAL_TERMS,
WE.TIME_TRANSPARENCY, WE.UNIVERSAL_ID, WE.SOURCE_REFERENCE_ID,
WE.FIXED_ASSET_ID, WE.FACILITY_ID, WE.INFO_URL, WE.RECURRENCE_INFO_ID,
WE.TEMP_EXPR_ID, WE.RUNTIME_DATA_ID, WE.NOTE_ID, WE.SERVICE_LOADER_NAME,
WE.QUANTITY_TO_PRODUCE, WE.QUANTITY_PRODUCED, WE.QUANTITY_REJECTED,
WE.RESERV_PERSONS, WE.RESERV2ND_P_P_PERC, WE.RESERV_NTH_P_P_PERC,
WE.ACCOMMODATION_MAP_ID, WE.ACCOMMODATION_SPOT_ID, WE.REVISION_NUMBER
FROM (((OFBIZ.CUST_REQUEST_WORK_EFFORT CRWE INNER JOIN
OFBIZ.CUST_REQUEST CR ON CRWE.CUST_REQUEST_ID = CR.CUST_REQUEST_ID)
INNER JOIN OFBIZ.WORK_EFFORT WE ON CRWE.WORK_EFFORT_ID =
WE.WORK_EFFORT_ID) LEFT OUTER JOIN OFBIZ.CUST_REQUEST_TYPE CRT ON
CR.CUST_REQUEST_TYPE_ID = CRT.CUST_REQUEST_TYPE_ID) LEFT OUTER JOIN
OFBIZ.STATUS_ITEM SI ON CR.STATUS_ID = SI.STATUS_ID WHERE (CR.STATUS_ID
= ?) ORDER BY CR.CREATED_DATE ASC
2009-04-22 11:21:46,167 (http-0.0.0.0-8443-2) [
ModelForm.java:1345:INFO ] preparePager: low - high = 0 - 20
2009-04-22 11:21:46,172 (http-0.0.0.0-8443-2) [
ModelForm.java:1363:INFO ] preparePager: Found rows = 20
2009-04-22 11:21:46,175 (http-0.0.0.0-8443-2)
[ Log4JLoggerFactory.java:96 :ERROR]
Macro renderScreenletPaginateMenu has no such argument: lastLinkUrl
The problematic instruction:
----------
==> macro renderScreenletPaginateMenu [on line 88, column 1 in
component://widget/templates/htmlScreenMacroLibrary.ftl]
in user-directive renderScreenletPaginateMenu [on line 1, column 1 in
Wed Apr 22 11:21:46 ICT 2009]
----------
Java backtrace for programmers:
----------
freemarker.template.TemplateException: Macro renderScreenletPaginateMenu
has no such argument: lastLinkUrl
at freemarker.core.Environment.visit(Environment.java:564)
at freemarker.core.UnifiedCall.accept(UnifiedCall.java:106)
at freemarker.core.Environment.visit(Environment.java:209)
at freemarker.core.Environment.include(Environment.java:1482)
at
org.ofbiz.widget.screen.MacroScreenRenderer.executeMacro(MacroScreenRenderer.java:98)
at
org.ofbiz.widget.screen.MacroScreenRenderer.renderScreenletPaginateMenu(MacroScreenRenderer.java:835)
at
org.ofbiz.widget.screen.MacroScreenRenderer.renderScreenletBegin(MacroScreenRenderer.java:628)
at org.ofbiz.widget.screen.ModelScreenWidget
$Screenlet.renderWidgetString(ModelScreenWidget.java:396)
at
org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
at org.ofbiz.widget.screen.ModelScreenWidget
$DecoratorSection.renderWidgetString(ModelScreenWidget.java:676)
at org.ofbiz.widget.screen.ModelScreenWidget
$SectionsRenderer.render(ModelScreenWidget.java:167)
at org.ofbiz.widget.screen.ModelScreenWidget
$DecoratorSectionInclude.renderWidgetString(ModelScreenWidget.java:706)
at
org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
at org.ofbiz.widget.screen.ModelScreenWidget
$Container.renderWidgetString(ModelScreenWidget.java:292)
at
org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
at org.ofbiz.widget.screen.ModelScreenWidget
$Container.renderWidgetString(ModelScreenWidget.java:292)
at
org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
at org.ofbiz.widget.screen.ModelScreenWidget
$Container.renderWidgetString(ModelScreenWidget.java:292)
at
org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
at org.ofbiz.widget.screen.ModelScreenWidget
$Section.renderWidgetString(ModelScreenWidget.java:227)
at
org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:393)
at org.ofbiz.widget.screen.ModelScreenWidget
$IncludeScreen.renderWidgetString(ModelScreenWidget.java:552)
at
org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
at org.ofbiz.widget.screen.ModelScreenWidget
$Section.renderWidgetString(ModelScreenWidget.java:227)
at
org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:393)
at org.ofbiz.widget.screen.ModelScreenWidget
$IncludeScreen.renderWidgetString(ModelScreenWidget.java:552)
at
org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
at org.ofbiz.widget.screen.ModelScreenWidget
$Section.renderWidgetString(ModelScreenWidget.java:227)
at
org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:393)
at org.ofbiz.widget.screen.ModelScreenWidget
$DecoratorScreen.renderWidgetString(ModelScreenWidget.java:646)
at
org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:138)
at org.ofbiz.widget.screen.ModelScreenWidget
$Section.renderWidgetString(ModelScreenWidget.java:227)
at
org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:393)
at
org.ofbiz.widget.screen.ScreenRenderer.render(ScreenRenderer.java:129)
at
org.ofbiz.widget.screen.ScreenRenderer.render(ScreenRenderer.java:92)
at
org.ofbiz.widget.screen.MacroScreenViewHandler.render(MacroScreenViewHandler.java:110)
at
org.ofbiz.webapp.control.RequestHandler.renderView(RequestHandler.java:781)
at
org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:533)
at
org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:201)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:259)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568)
at
org.ofbiz.catalina.container.CrossSubdomainSessionValve.invoke(CrossSubdomainSessionValve.java:44)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol
$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint
$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Re: New widget renderers
Posted by Hans Bakker <ma...@antwebsystems.com>.
Yes jacopo,
i reacted too quick. thanks.
On Tue, 2009-04-21 at 12:31 +0200, Jacopo Cappellato wrote:
> 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
> > settling down so i upgraded my company version. I am sure this will
> > give
> > 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:
> >> 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 <ja...@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,
> >>>>>>
> >>>>>> I am asking you to help to test the new "Macro" widget handler
> >>>>>> and
> >>>>>> 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
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> > --
> > Antwebsystems.com: Quality OFBiz services for competitive rates
> >
>
--
Antwebsystems.com: Quality OFBiz services for competitive rates
Re: New widget renderers
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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
> settling down so i upgraded my company version. I am sure this will
> give
> 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:
>> 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 <ja...@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,
>>>>>>
>>>>>> I am asking you to help to test the new "Macro" widget handler
>>>>>> and
>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>
> --
> Antwebsystems.com: Quality OFBiz services for competitive rates
>
Re: New widget renderers
Posted by Hans Bakker <ma...@antwebsystems.com>.
as long we have a way to disable them ?
i use the trunk version in production. At the moment the dust is a bit
settling down so i upgraded my company version. I am sure this will give
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:
> 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 <ja...@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,
> >>>>
> >>>> I am asking you to help to test the new "Macro" widget handler and
> >>>> 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
> >>>>
> >>>>
> >>>
> >>
>
--
Antwebsystems.com: Quality OFBiz services for competitive rates
Re: New widget renderers
Posted by guo weizhan <gu...@gmail.com>.
It should has included the widget boundary comments, do you found any
problem?
2009/4/22 Jacopo Cappellato <ja...@hotwaxmedia.com>
> I am now looking into this.
>
> Jacopo
>
>
> On Apr 21, 2009, at 7:27 PM, Adrian Crum wrote:
>
> Jacopo,
>>
>> Thank you for all your work on this! I noticed that the widget boundary
>> comments are missing.
>>
>> -Adrian
>>
>> Jacopo Cappellato wrote:
>>
>>> 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 <ja...@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,
>>>>>>
>>>>>>>
>>>>>>> I am asking you to help to test the new "Macro" widget handler and
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>
Re: New widget renderers
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
I am now looking into this.
Jacopo
On Apr 21, 2009, at 7:27 PM, Adrian Crum wrote:
> Jacopo,
>
> Thank you for all your work on this! I noticed that the widget
> boundary comments are missing.
>
> -Adrian
>
> Jacopo Cappellato wrote:
>> 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 <ja...@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,
>>>>>>
>>>>>> I am asking you to help to test the new "Macro" widget handler
>>>>>> and
>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
Re: New widget renderers
Posted by Adrian Crum <ad...@hlmksw.com>.
Jacopo,
Thank you for all your work on this! I noticed that the widget boundary
comments are missing.
-Adrian
Jacopo Cappellato wrote:
> 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 <ja...@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,
>>>>>
>>>>> I am asking you to help to test the new "Macro" widget handler and
>>>>> 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
>>>>>
>>>>>
>>>>
>>>
>
Re: New widget renderers
Posted by Ashish Vijaywargiya <vi...@gmail.com>.
+1 - for enabling this on trunk now.
This will help to improve the code.
Thanks for enabling this, Jacopo :-)
--
Ashish
On Tue, Apr 21, 2009 at 3:42 PM, Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> wrote:
> 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
Re: New widget renderers
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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 <ja...@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,
>>>>
>>>> I am asking you to help to test the new "Macro" widget handler and
>>>> 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
>>>>
>>>>
>>>
>>
Re: New widget renderers
Posted by guo weizhan <gu...@gmail.com>.
Hi Jacopo
Thanks for your effort, I'm waiting for test result:) .
Guo
2009/4/5 Jacopo Cappellato <ja...@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,
>>>
>>> I am asking you to help to test the new "Macro" widget handler and
>>> 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
>>>
>>>
>>
>
Re: New widget renderers
Posted by Jacopo Cappellato <ja...@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,
>>
>> I am asking you to help to test the new "Macro" widget handler and
>> 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
>>
>
Re: New widget renderers
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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,
>
> I am asking you to help to test the new "Macro" widget handler and
> 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
>