[
https://issues.apache.org/jira/browse/OFBIZ-3766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875317#action_12875317
]
Adrian Crum commented on OFBIZ-3766:
------------------------------------
I was looking at the rendering code a while back and thought it would be best
to use the factory pattern for renderers. Factory methods could take rendering
format and widget type as arguments, and then return the appropriate renderer.
I agree that there are a lot of problems in the rendering code.
> MacroScreenRenderer still uses HtmlFormRenderer (dependencies on html
> renderers)
> --------------------------------------------------------------------------------
>
> Key: OFBIZ-3766
> URL: https://issues.apache.org/jira/browse/OFBIZ-3766
> Project: OFBiz
> Issue Type: Bug
> Components: framework
> Affects Versions: Release Branch 10.04, SVN trunk
> Reporter: Blas Rodriguez Somoza
> Assignee: Jacques Le Roux
> Priority: Minor
> Fix For: Release Branch 10.04, SVN trunk
>
> Attachments: OFBIZ-3766_html_dependencies.diff
>
>
> There are a bug in MacroScreenRenderer.renderScreenletSubWidget. and several
> pages of the demo uses HtmlFormRenderer instead of MacroFormRenderer.
> The dependencies in org.ofbiz.widget.<non-html> directories against
> org.ofbiz.widget.html are the following
> 1.- org\ofbiz\widget\menu\MenuWrapTransform.java --> import
> org.ofbiz.widget.html.HtmlMenuWrapper;
> 2.- org\ofbiz\widget\screen\MacroScreenRenderer.java -->:import
> org.ofbiz.widget.html.HtmlScreenRenderer.ScreenletMenuRenderer;
> 3.- org\ofbiz\widget\screen\ModelScreenWidget.java -->:import
> org.ofbiz.widget.html.HtmlMenuRenderer;
> 4.- org\ofbiz\widget\screen\ModelScreenWidget.java -->:import
> org.ofbiz.widget.html.HtmlFormRenderer;
> 5.- org\ofbiz\widget\screen\MacroScreenRenderer.java -->:import
> org.ofbiz.widget.html.HtmlFormRenderer;
> 6.- org\ofbiz\widget\screen\ScreenFopViewHandler.java -->:import
> org.ofbiz.widget.html.HtmlScreenRenderer;
> I excluded:
> ScreenWidgetViewHandler.java which is in widget.screen but is a piece of the
> html renderers
> References to HtmlWidgetRenderer, which although it is in the html directory
> doesn't depend on other html directory sources.
> Comments:
> 1.- OK.
> 2.- The real dependency is with HtmlMenuRenderer.
> 3,4.- To avoid default renderers, ModelScreenWidget should use only the
> renderer stored in the context.
> 5.- bug.
> 6.- if macro renderer will be the default one then this must be changed. It
> will be better if the default renderer can be taken from the context but
> AFAIK it isn't a default renderer in the context.
> After the patch the dependencies against html directory are:
> org\ofbiz\widget\menu\MenuWrapTransform.java --> import
> org.ofbiz.widget.html.HtmlMenuWrapper;
> org\ofbiz\widget\screen\MacroScreenRenderer.java -->:import
> org.ofbiz.widget.html.HtmlMenuRenderer;
> org\ofbiz\widget\screen\MacroScreenViewHandler.java -->:import
> org.ofbiz.widget.html.HtmlMenuRenderer;
> which are the expected ones, only with HtmlMenu because it isn't a macro
> replacement.
> Patch:
> MacroScreenRenderer.java
> - renderScreenletSubWidget method must use MacroFormRenderer instead of
> HtmlFormRenderer
> - Added ScreenletMenuRenderer copied from HtmlScreenRenderer. This make the
> dependency on HtmlMenuRenderer explicit and avoid the dependency on
> HtmlScreenRenderer
> MacroScreenViewHandler.java
> - To avoid using defaults in ModelScreenWidget each ViewHandler must store
> its form, tree and menu renderers in the context.
> ModelScreenWidget.java
> - There are not default renderers, each ScreenViewHandler must put its form,
> tree and menu renderers in the context.
> ScreenFopViewHandler.java
> - Use MacroScreenRenderer instead HtmlScreenRenderer.
> ScreenWidgetViewHandler.java (aka ScreenHtmlViewHandler)
> - To avoid using defaults in ModelScreenWidget each ViewHandler must store
> its form, tree and menu renderers in the context.
> ScreenXmlViewHandler.java
> - Should not depend on ScreenWidgetViewHandler
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
