[
https://issues.apache.org/jira/browse/OFBIZ-11907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17169001#comment-17169001 ]
Daniel Watford commented on OFBIZ-11907:
----------------------------------------
Hi Jacques,
The encodeAmpersands method call was removed as WidgetWorker is no longer concerned with whether the URI is being written out to a string as part of an HTML/XML attribute anymore. Instead the URIBuilder handles breaking the target string into relevant components for us which can then be appropriately rendered by some other process later.
The issue you found with loading the example page was due to WidgetWorker trying to parse spaces in target strings such as:
{code:java}
"javascript: document.FindExamples.action='ListExampleExport'; document.FindExamples.submit();"{code}
This has been resolved by URL encoding spaces as %20 before parsing the target string using URI Builder.
Please see the updated commit on the PR.
> 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
>
> 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)
Locked
