[ 
https://issues.apache.org/jira/browse/PIVOT-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849951#action_12849951
 ] 

Greg Brown commented on PIVOT-445:
----------------------------------

While I definitely see the value in the idea of a "shared component 
repository", I don't think WTKX is the right vehicle for packaging such 
components. It could certainly be part of the solution, but I don't think it 
should *be* the solution. 

For example, consider that you can't use WTKX to create a new class (it is used 
to instantiate existing classes). In order to define a custom component, you'd 
still need to write a Java class (or something that gets compiled to a Java 
class). You could instantiate this class in your WTKX file, but you'd also need 
to make sure that anyone "importing" your WTKX downloaded the associated JAR 
file containing your custom class. 

So while WTKX is great for assembling applications, it isn't quite the right 
tool for creating custom components. For the component repository concept, I 
would think that distributing the components as JARs might work better. 

> 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.

Reply via email to