[
https://issues.apache.org/jira/browse/PIVOT-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849920#action_12849920
]
Anthony J. Bufort commented on PIVOT-445:
-----------------------------------------
With regard to #2 (passing args to included wtkx), I can understand and respect
that. Doesn't necessarily mean I wouldn't like to see it, but I can respect
the thinking backing that. To my mind, once you folks allowed
JSP-ish-scriptlet-type coding within wtkx, however, you already kind of opened
up the floodgates on that. I acknowledge the sensitivity that goes into making
decisions regarding provision for flexibility while retaining limitations.
Regarding #1 (url attribute for include), I just think it would make a great
avenue for centrally-located reusable components authored by third parties. In
the same way you can include an entire applet authored elsewhere on a page
written by you, Pivot could also allow useful wtkx sub-components to exist
across the web which can be included as widgets within larger apps.
Advantages to #1:
- Encourages code-sharing and reuse of 3rd-party wtkx components
- Above results in delegation of code maintenance and responsibility
- Can result in additional 'Pivot usage juices' flowing across the web, as
intrepid authors could publish useful wtkx snippets across the Internet for use
in anyone's applications
Disadvantages:
- Possible security issues?
> Provide Inclusion Mechanism WIthin WTKX Files to Allow For Reusable WTKX
> Sub-Components
> ---------------------------------------------------------------------------------------
>
> Key: PIVOT-445
> URL: https://issues.apache.org/jira/browse/PIVOT-445
> Project: Pivot
> Issue Type: New Feature
> Components: wtk-wtkx
> Reporter: Anthony J. Bufort
>
> Provide a mechanism (directive) by which WTKX snippets may be included within
> larger WTKX files. Ideally, inclusion mechanism would provide option to pass
> String arguments to snippets being included. Snippets used in such a manner
> could then function as templates into which variable data can be poured for
> flexible reuse.
> Included files, once parsed, could even be cacheable such that future reads
> can be done from cache instead of always going to the filesystem (perhaps,
> via a boolean 'cache' attribute). A value of "true" would populate the cache
> with the sub-component if it isn't already present. If it is present, it
> would read from it instead of going out to the filesystem. A value of
> "false" would cause a read from the filesystem.
> EXAMPLE:
> (file to include sub-component in)
> <Window title="Hello WTKX!" maximized="true"
> xmlns:wtkx="http://pivot.apache.org/wtkx";
> xmlns="org.apache.pivot.wtk">
> <content>
> <Panel wtkx:id="master_panel" styles="{backgroundColor:'#ffffff'}">
> <FlowPane wtkx:id="maste_flowpane"
> styles="{verticalSpacing:'20'}" x="40" y="40" width="500" height="300">
> <Include file="subcomponents/ButtonPairComponent.wtkx"
> args="{'row_1','Button Text #1', 'Button Text #2'}" cache="true"/>
> <Include file="subcomponents/ButtonPairComponent.wtkx"
> args="{'row_2','Button Text #3', 'Button Text #4'}" cache="true"/>
> <Include file="subcomponents/ButtonPairComponent.wtkx"
> args="{'row_3','Button Text #5', 'Button Text #6'}" cache="true"/>
> </FlowPane>
> <Label text="HEADER" preferredWidth="170"/>
> </Panel>
> </content>
> </Window>
> (included sub-component)
> <BoxPane wtkx:id="$1" styles="{spacing:'75'}">
> <PushButton buttonData="$2" preferredWidth="170" styles="{}"/>
> <PushButton buttonData="$3" preferredWidth="170" styles="{}"/>
> </BoxPane>
> Additionally, a version of include for URLs can also be provided.
> EXAMPLE CALL:
> <Include
> url="http://www.myurl.com/myapp/wtkx/subcomponents/ButtonPairComponent.wtkx";
> args="{'row_4','Button Text #7', 'Button Text #8'}" cache="false"/>
> Note that in the above sub-component, empty "styles" atributes exist. This
> highlights the idea that, instead of needing to provide styles every time
> this sub-component would have been rewritten without the include mechanism,
> they now need only be provided in one file.
> The author is aware that programmatic inclusion might well be achievable with
> the current codebase, but is suggesting a higher, and more convenient,
> standard here. It would be familiar to JSPers, and useful to both desktop
> and web app developers alike. Most importantly, all GUI elements would
> remain within the WTKX layer.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
