[
https://issues.apache.org/jira/browse/PIVOT-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849934#action_12849934
]
Anthony J. Bufort commented on PIVOT-445:
-----------------------------------------
I am appreciating our back-and-forth on this. Thanks.
On #2, I understand the slippery-slope incentive to draw lines in the sand. :)
With reagrd to my parameterization example, it's fairly straightforward to do
the multiple non-parameterized includes and then programmatically go back and
access the array of sub-components and populate their attributes, right? So I
do see how one can survive otherwise.
Regarding #1, I suppose security really is the kicker on that one. Speaking to
latency, I don't buy that one as much, because we're only talking about
downloading some text here, not an entire codebase or even a significant
portion of one. Granted, some server setups are pathetic and cause even text
files to take a while to download. But we're talking K here, not MB.
Additionally, whether or not performance is a consideration should be left up
to the author utilizing the outside code to determine. It is conceivable that
the code might be worth the (likely usually minimal) wait. Regarding latency
as an incentive to copy snippets locally, that may or may not be true,
depending on the situation. I see the incentive not to copy as being keeping
code maintenance on the 3rd party's side, but even more importantly being able
to instantly capture any updates to the code. I suppose that on the level on
which I am speaking, 'snippets' is a misleading term. We're talking at this
point of more than a few lines, but less than a full, independent app. Not
quite an applet, but it could be made to be so.
I grant that the lines are becoming blurry at this point. :)
Again, thanks for the discussion. I look to Pivot longingly and with great
hope, as I introduced Thinlet to Boeing for rapid prototyping, and loved
working with it. Granted, it had its sometimes-annoying limits, and was not
polished in several respects, but it sure was damn useful and, for the most
part, intuitive to understand. Additionally, there was the bonus of the
Theodore GUI builder, written by a 3rd party.
> 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.
