[
https://issues.apache.org/jira/browse/PIVOT-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849924#action_12849924
]
Todd Volkert commented on PIVOT-445:
------------------------------------
With regards to #1, having a common place where someone could post their useful
WTKX snippets would be appealing, but I'd guess that most applications wouldn't
want to tie their application performance to the performance and latency of
someone else's web site, meaning you'd probably want to copy the WTKX snippet
and include it locally in your app anyway. Also, like you alude to, there are
security concerns -- namely, that you can't make an HTTP request in an applet
to a foreign domain without signing your applet; so applets that could
otherwise be unsigned would have to be signed (which is turn slows down load
time). All in all, I can see where you're coming from, but I'm not sure it's
worth doing.
On #2, I'll admit that it definitely is a slippery slope we've walked. If we
introduced parameters, inevitably the very next request would be for JSP-style
expression syntax (foo="{$a + 1}"), so we've chosen to draw the line somewhere.
I myself have wanted <wtkx:include> parameterization, but then again, I've
always been able to do without it pretty easily too and have yet to see a use
case that really needs it
> 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.
