[jira] [Commented] (OFBIZ-11907) WidgetWorker should not write generated html to Appendable

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (OFBIZ-11907) WidgetWorker should not write generated html to Appendable

Nicolas Malin (Jira)

    [ https://issues.apache.org/jira/browse/OFBIZ-11907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17169835#comment-17169835 ]

ASF subversion and git services commented on OFBIZ-11907:
---------------------------------------------------------

Commit e8dd3c609cd50d757bf0db8263f5ca14c00d2f0f in ofbiz-framework's branch refs/heads/trunk from Jacques Le Roux
[ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=e8dd3c6 ]

Fixed: Server-Side Template Injection using Static (OFBIZ-11871)

Thanks to Alvaro's explanations, the problem was in MacroFormRenderer where, for
lookups, we retrieve _LAST_VIEW_NAME_ as a parameter without encoding it.

I have added getEncodedParameter method in UtilHttp and removed now useless
(after OFBIZ-11907) getEnvironment from MacroFormRenderer.java

Thanks: Alvaro for advice


> WidgetWorker should not write generated html to Appendable
> ----------------------------------------------------------
>
>                 Key: OFBIZ-11907
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-11907
>             Project: OFBiz
>          Issue Type: Sub-task
>          Components: framework/widget
>            Reporter: Daniel Watford
>            Assignee: Daniel Watford
>            Priority: Minor
>             Fix For: Upcoming Branch
>
>
> WidgetWorker is used to create URLs, anchor links and hidden forms (to support hidden-form links). 
> WidgetWorker doesn't just generate these elements but it also writes those elements to an Appendable object normally passed to it from classes like MacroScreenRenderer and MacroFormRenderer.
> Requiring that an Appendable is passed to WidgetWorker unnecessarily forces behaviour onto the calling classes, when all that is really required is for the WidgetWorker to create the elements it has been asked. Calling classes can write the created elements to I/O as they see fit.
> Further, WidgetWorker produces HTML elements rendered to string. By doing this WidgetWorker has assumed knowledge about how the elements are to be used (i.e. within an FTL macro parameter call) and has to apply appropriate encoding.
> Rather than rendering a string, WidgetWorker should create data structures, such as JSoup's elements, to represent the requested elements. The calling classes can then decide how/where to render the elements.
> The above changes are deemed necessary to allow the refactoring of MacroFormRenderer to proceed, as otherwise MacroFormRenderer will have to ensure knowledge of where elements are to be rendered is maintained in order for this information to be passed to WidgetWorker. This is not in-line with the refactoring efforts targeting MacroFormRenderer.
> This changes will reduce the responsibilities of WidgetWorker. It shall be responsible for creating data structures to represent requested elements, without needing to know how to render those elements to a string or other I/O channel.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)