You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Inge Solvoll <in...@gmail.com> on 2011/05/31 10:44:44 UTC
Simpler Select configuration
Hi!
In my new job I've worked a lot with Swing GUI code. I immediately saw the
strong need for a framework, in order to provide better abstractions, events
and data binding between GUI and the model layer. The framework market for
Swing applications is very close to dead, but I found a decent dead
framework that could be resurrected, named Genesis. After working with it
for a couple of months, I can see very clear similarities with Tapestry on
several concepts:
- POJO controller instrumented by annotations.
- Seamless client event binding.
- Convention over configuration: Model properties are mapped to GUI controls
with the same name
- Automatic type coercion between model and GUI
- Swing code is isolated and simplified, even more so than T5 templates
Enough off topic :)
When working with T5, one of the (very few) things that I found sub-optimal
is the Select component. You have to implement 2 interfaces, and it requires
extra work when dealing with AJAX, which is a very common requirement. In
Genesis, it is done like the example below. Methods that provide content for
Select boxes are annotated with @DataProvider. If a Select is dependent on
some change in the GUI, the data provider method can be annotated with
@CallWhen to refresh the list when some property on the controller changes.
I would really like to see something similar in T5, allowing the developers
to specify a collection and a property, without using the T5 custom models
for Selects. Also, providing AJAX refresh of the content of a Select,
without exposing AJAX plumbing. I'm thinking the opposite of the zone
support introduced, allowing a refresh something else. I would like the
Select to refresh itself on some condition. Please see examples below.
public class MyGuiPanel extends JPanel {
private javax.swing.JComboBox mySelect;
private javax.swing.JComboBox dependsOnMySelect;
}
public class MyGuiPanelController {
private MyDomainObject someProperty;
private MyDomainObject someOtherProperty;
@DataProvider(widgetId="mySelect", property="someProperty")
public List<MyDoimainObject> getProperties() {
return db.getProperties();
}
@CallWhen("genesis.hasChanged('form:someProperty')")
@DataProvider(widgetId="dependsOnMySelect", property="someOtherProperty")
public List<MyDoimainObject> getOtherProperties() {
return db.getProperties();
}
}
Example ideal T5 code for this:
public class MyPage {
@Component(parameters="value=someProperty, list=properties")
private Select mySelect;
@Component(parameters="value=someOtherProperty, list=otherProperties,
listenForChangesTo=someProperty")
private Select mySelect;
}
Re: Simpler Select configuration
Posted by Josh Canfield <jo...@gmail.com>.
> That is, if you provide a property of type List for the "model"
You can also return a map with label and value which is much more useful for
database objects.
On Jun 1, 2011 6:08 PM, "Bob Harner" <bo...@gmail.com> wrote:
> Inge,
>
> Interesting ideas. I agree that it would be nice to have a SelectModel
> created automatically from the parameters passed to the Select
> component. In fact, Select can do this already, with some limitations.
> That is, if you provide a property of type List for the "model"
> parameter (and don't provide a ValueEncoder), Tapestry automatically
> builds a SelectModel that uses each object's toString() for both the
> select option's encoded value and the user-visible label. For
> database-derrived lists this is rarely useful, however, since after
> form submission you would then have to look up the selected object by
> that label, rather than by an id.
>
> As I understand it, Tapestry uses the SelectModel-and-ValueEncoder
> design partly so as to not require you to put a potentially large list
> of objects in the HttpSession (or, alternatively, to have to
> reconstruct that entire list of objects after form submission when you
> only need one). Unlike Swing, Tapestry is designed to allow stateless
> operation, with (mostly) no assumptions about whether you want to have
> any session data hanging around between the rendering of a form and
> the handling of the form submission.
>
> Still, there is much to think about in your post.
>
> On Tue, May 31, 2011 at 4:44 AM, Inge Solvoll <in...@gmail.com>
wrote:
>> Hi!
>>
>> In my new job I've worked a lot with Swing GUI code. I immediately saw
the
>> strong need for a framework, in order to provide better abstractions,
events
>> and data binding between GUI and the model layer. The framework market
for
>> Swing applications is very close to dead, but I found a decent dead
>> framework that could be resurrected, named Genesis. After working with it
>> for a couple of months, I can see very clear similarities with Tapestry
on
>> several concepts:
>>
>> - POJO controller instrumented by annotations.
>> - Seamless client event binding.
>> - Convention over configuration: Model properties are mapped to GUI
controls
>> with the same name
>> - Automatic type coercion between model and GUI
>> - Swing code is isolated and simplified, even more so than T5 templates
>>
>> Enough off topic :)
>>
>> When working with T5, one of the (very few) things that I found
sub-optimal
>> is the Select component. You have to implement 2 interfaces, and it
requires
>> extra work when dealing with AJAX, which is a very common requirement. In
>> Genesis, it is done like the example below. Methods that provide content
for
>> Select boxes are annotated with @DataProvider. If a Select is dependent
on
>> some change in the GUI, the data provider method can be annotated with
>> @CallWhen to refresh the list when some property on the controller
changes.
>>
>> I would really like to see something similar in T5, allowing the
developers
>> to specify a collection and a property, without using the T5 custom
models
>> for Selects. Also, providing AJAX refresh of the content of a Select,
>> without exposing AJAX plumbing. I'm thinking the opposite of the zone
>> support introduced, allowing a refresh something else. I would like the
>> Select to refresh itself on some condition. Please see examples below.
>>
>>
>> public class MyGuiPanel extends JPanel {
>> private javax.swing.JComboBox mySelect;
>> private javax.swing.JComboBox dependsOnMySelect;
>> }
>>
>> public class MyGuiPanelController {
>>
>> private MyDomainObject someProperty;
>> private MyDomainObject someOtherProperty;
>>
>> @DataProvider(widgetId="mySelect", property="someProperty")
>> public List<MyDoimainObject> getProperties() {
>> return db.getProperties();
>> }
>>
>> @CallWhen("genesis.hasChanged('form:someProperty')")
>> @DataProvider(widgetId="dependsOnMySelect",
property="someOtherProperty")
>> public List<MyDoimainObject> getOtherProperties() {
>> return db.getProperties();
>> }
>> }
>>
>>
>>
>> Example ideal T5 code for this:
>>
>> public class MyPage {
>>
>> @Component(parameters="value=someProperty, list=properties")
>> private Select mySelect;
>>
>> @Component(parameters="value=someOtherProperty, list=otherProperties,
>> listenForChangesTo=someProperty")
>> private Select mySelect;
>> }
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Re: Simpler Select configuration
Posted by Inge Solvoll <in...@gmail.com>.
Thanks for great responses to my thoughts.
I have some ideas myself about AJAX stuff for Select, will try to make time
to blog about it. I don't work with this stuff anymore, so it's harder to
find the time :)
On Mon, Jun 6, 2011 at 2:56 PM, LLTYK <LL...@mailinator.com> wrote:
> Whatever the solution is for making this simpler, it'd be nice if it came
> with Tapestry by default.
>
> --
> View this message in context:
> http://tapestry-users.832.n2.nabble.com/Simpler-Select-configuration-tp6421890p6444986.html
> Sent from the Tapestry Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Simpler Select configuration
Posted by LLTYK <LL...@mailinator.com>.
Whatever the solution is for making this simpler, it'd be nice if it came
with Tapestry by default.
--
View this message in context: http://tapestry-users.832.n2.nabble.com/Simpler-Select-configuration-tp6421890p6444986.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Simpler Select configuration
Posted by Taha Hafeez <ta...@gmail.com>.
Followed your lead
http://tawus.wordpress.com/2011/06/06/a-simpler-select-for-tapestry/
regards
Taha
On Sat, Jun 4, 2011 at 5:56 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> A reminder: org.apache.tapestry5.components.Select is not the only
> class allowed to render a <select> or <option> tag. Rather than
> bending code ment for one purpose too far, why not think in terms of a
> family of components that do similar things, but are applicable to
> different situations?
>
> On Fri, Jun 3, 2011 at 5:24 PM, Taha Hafeez <ta...@gmail.com>
> wrote:
> > Wrote a post about it.
> >
> > http://tawus.wordpress.com/2011/06/04/tapestry-magic-14-easy-selection/
> >
> > and if you find it useful I can add it to the wiki.
> >
> > regards
> > Taha
> >
> >
> > On Fri, Jun 3, 2011 at 8:54 PM, Taha Hafeez <tawus.tapestry@gmail.com
> >wrote:
> >
> >> I use a configuration, which is similar to the one suggested by inge.
> The
> >> usage is
> >>
> >> @InjectSelectSupport(type = User.class, label = "${name}(${address})",
> >> index = "id")
> >> private List<User> users;
> >>
> >>
> >> Using a class transformation, it introduces a method
> >>
> >> public SelectSupport getUsersSupport();
> >>
> >> in the component/page. So in template only
> >>
> >> <t:select t:model='usersSupport' t:encoder='usersSupport'
> t:value='user'/>
> >>
> >> is required
> >>
> >> regards
> >> Taha
> >>
> >>
> >>
> >> On Fri, Jun 3, 2011 at 5:39 PM, Bob Harner <bo...@gmail.com> wrote:
> >>
> >>> I would prefer to see something more familiar-looking:
> >>>
> >>> <t:select model="someList" value="oneItem">
> >>> <option value="oneItem.id">${oneItem.name}</option>
> >>> </t:select>
> >>>
> >>> Not sure how possible that is. But it sure would be a lot more
> >>> flexible, and a lot easier for newbies to understand.
> >>>
> >>> On Fri, Jun 3, 2011 at 7:38 AM, Thiago H. de Paula Figueiredo
> >>> <th...@gmail.com> wrote:
> >>> > On Fri, 03 Jun 2011 08:22:13 -0300, LLTYK <LL...@mailinator.com>
> wrote:
> >>> >
> >>> >> How about a shorthand for selectmodelfactory calls. Something like
> >>> >> <t:select model="someList,valueProperty,labelProperty" />
> >>> >
> >>> > This could (or should) be implemented as a binding prefix.
> >>> >
> >>> > --
> >>> > Thiago H. de Paula Figueiredo
> >>> > Independent Java, Apache Tapestry 5 and Hibernate consultant,
> developer,
> >>> and
> >>> > instructor
> >>> > Owner, Ars Machina Tecnologia da Informação Ltda.
> >>> > http://www.arsmachina.com.br
> >>> >
> >>> > ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>> > For additional commands, e-mail: users-help@tapestry.apache.org
> >>> >
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>
> >>>
> >>
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Simpler Select configuration
Posted by Howard Lewis Ship <hl...@gmail.com>.
A reminder: org.apache.tapestry5.components.Select is not the only
class allowed to render a <select> or <option> tag. Rather than
bending code ment for one purpose too far, why not think in terms of a
family of components that do similar things, but are applicable to
different situations?
On Fri, Jun 3, 2011 at 5:24 PM, Taha Hafeez <ta...@gmail.com> wrote:
> Wrote a post about it.
>
> http://tawus.wordpress.com/2011/06/04/tapestry-magic-14-easy-selection/
>
> and if you find it useful I can add it to the wiki.
>
> regards
> Taha
>
>
> On Fri, Jun 3, 2011 at 8:54 PM, Taha Hafeez <ta...@gmail.com>wrote:
>
>> I use a configuration, which is similar to the one suggested by inge. The
>> usage is
>>
>> @InjectSelectSupport(type = User.class, label = "${name}(${address})",
>> index = "id")
>> private List<User> users;
>>
>>
>> Using a class transformation, it introduces a method
>>
>> public SelectSupport getUsersSupport();
>>
>> in the component/page. So in template only
>>
>> <t:select t:model='usersSupport' t:encoder='usersSupport' t:value='user'/>
>>
>> is required
>>
>> regards
>> Taha
>>
>>
>>
>> On Fri, Jun 3, 2011 at 5:39 PM, Bob Harner <bo...@gmail.com> wrote:
>>
>>> I would prefer to see something more familiar-looking:
>>>
>>> <t:select model="someList" value="oneItem">
>>> <option value="oneItem.id">${oneItem.name}</option>
>>> </t:select>
>>>
>>> Not sure how possible that is. But it sure would be a lot more
>>> flexible, and a lot easier for newbies to understand.
>>>
>>> On Fri, Jun 3, 2011 at 7:38 AM, Thiago H. de Paula Figueiredo
>>> <th...@gmail.com> wrote:
>>> > On Fri, 03 Jun 2011 08:22:13 -0300, LLTYK <LL...@mailinator.com> wrote:
>>> >
>>> >> How about a shorthand for selectmodelfactory calls. Something like
>>> >> <t:select model="someList,valueProperty,labelProperty" />
>>> >
>>> > This could (or should) be implemented as a binding prefix.
>>> >
>>> > --
>>> > Thiago H. de Paula Figueiredo
>>> > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
>>> and
>>> > instructor
>>> > Owner, Ars Machina Tecnologia da Informação Ltda.
>>> > http://www.arsmachina.com.br
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> > For additional commands, e-mail: users-help@tapestry.apache.org
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Simpler Select configuration
Posted by Taha Hafeez <ta...@gmail.com>.
Wrote a post about it.
http://tawus.wordpress.com/2011/06/04/tapestry-magic-14-easy-selection/
and if you find it useful I can add it to the wiki.
regards
Taha
On Fri, Jun 3, 2011 at 8:54 PM, Taha Hafeez <ta...@gmail.com>wrote:
> I use a configuration, which is similar to the one suggested by inge. The
> usage is
>
> @InjectSelectSupport(type = User.class, label = "${name}(${address})",
> index = "id")
> private List<User> users;
>
>
> Using a class transformation, it introduces a method
>
> public SelectSupport getUsersSupport();
>
> in the component/page. So in template only
>
> <t:select t:model='usersSupport' t:encoder='usersSupport' t:value='user'/>
>
> is required
>
> regards
> Taha
>
>
>
> On Fri, Jun 3, 2011 at 5:39 PM, Bob Harner <bo...@gmail.com> wrote:
>
>> I would prefer to see something more familiar-looking:
>>
>> <t:select model="someList" value="oneItem">
>> <option value="oneItem.id">${oneItem.name}</option>
>> </t:select>
>>
>> Not sure how possible that is. But it sure would be a lot more
>> flexible, and a lot easier for newbies to understand.
>>
>> On Fri, Jun 3, 2011 at 7:38 AM, Thiago H. de Paula Figueiredo
>> <th...@gmail.com> wrote:
>> > On Fri, 03 Jun 2011 08:22:13 -0300, LLTYK <LL...@mailinator.com> wrote:
>> >
>> >> How about a shorthand for selectmodelfactory calls. Something like
>> >> <t:select model="someList,valueProperty,labelProperty" />
>> >
>> > This could (or should) be implemented as a binding prefix.
>> >
>> > --
>> > Thiago H. de Paula Figueiredo
>> > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
>> and
>> > instructor
>> > Owner, Ars Machina Tecnologia da Informação Ltda.
>> > http://www.arsmachina.com.br
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
Re: Simpler Select configuration
Posted by Taha Hafeez <ta...@gmail.com>.
I use a configuration, which is similar to the one suggested by inge. The
usage is
@InjectSelectSupport(type = User.class, label = "${name}(${address})", index
= "id")
private List<User> users;
Using a class transformation, it introduces a method
public SelectSupport getUsersSupport();
in the component/page. So in template only
<t:select t:model='usersSupport' t:encoder='usersSupport' t:value='user'/>
is required
regards
Taha
On Fri, Jun 3, 2011 at 5:39 PM, Bob Harner <bo...@gmail.com> wrote:
> I would prefer to see something more familiar-looking:
>
> <t:select model="someList" value="oneItem">
> <option value="oneItem.id">${oneItem.name}</option>
> </t:select>
>
> Not sure how possible that is. But it sure would be a lot more
> flexible, and a lot easier for newbies to understand.
>
> On Fri, Jun 3, 2011 at 7:38 AM, Thiago H. de Paula Figueiredo
> <th...@gmail.com> wrote:
> > On Fri, 03 Jun 2011 08:22:13 -0300, LLTYK <LL...@mailinator.com> wrote:
> >
> >> How about a shorthand for selectmodelfactory calls. Something like
> >> <t:select model="someList,valueProperty,labelProperty" />
> >
> > This could (or should) be implemented as a binding prefix.
> >
> > --
> > Thiago H. de Paula Figueiredo
> > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and
> > instructor
> > Owner, Ars Machina Tecnologia da Informação Ltda.
> > http://www.arsmachina.com.br
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Simpler Select configuration
Posted by Bob Harner <bo...@gmail.com>.
I would prefer to see something more familiar-looking:
<t:select model="someList" value="oneItem">
<option value="oneItem.id">${oneItem.name}</option>
</t:select>
Not sure how possible that is. But it sure would be a lot more
flexible, and a lot easier for newbies to understand.
On Fri, Jun 3, 2011 at 7:38 AM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Fri, 03 Jun 2011 08:22:13 -0300, LLTYK <LL...@mailinator.com> wrote:
>
>> How about a shorthand for selectmodelfactory calls. Something like
>> <t:select model="someList,valueProperty,labelProperty" />
>
> This could (or should) be implemented as a binding prefix.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
> instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Simpler Select configuration
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Fri, 03 Jun 2011 08:22:13 -0300, LLTYK <LL...@mailinator.com> wrote:
> How about a shorthand for selectmodelfactory calls. Something like
> <t:select model="someList,valueProperty,labelProperty" />
This could (or should) be implemented as a binding prefix.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Simpler Select configuration
Posted by LLTYK <LL...@mailinator.com>.
How about a shorthand for selectmodelfactory calls. Something like <t:select
model="someList,valueProperty,labelProperty" />
--
View this message in context: http://tapestry-users.832.n2.nabble.com/Simpler-Select-configuration-tp6421890p6434883.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Simpler Select configuration
Posted by Bob Harner <bo...@gmail.com>.
Inge,
Interesting ideas. I agree that it would be nice to have a SelectModel
created automatically from the parameters passed to the Select
component. In fact, Select can do this already, with some limitations.
That is, if you provide a property of type List for the "model"
parameter (and don't provide a ValueEncoder), Tapestry automatically
builds a SelectModel that uses each object's toString() for both the
select option's encoded value and the user-visible label. For
database-derrived lists this is rarely useful, however, since after
form submission you would then have to look up the selected object by
that label, rather than by an id.
As I understand it, Tapestry uses the SelectModel-and-ValueEncoder
design partly so as to not require you to put a potentially large list
of objects in the HttpSession (or, alternatively, to have to
reconstruct that entire list of objects after form submission when you
only need one). Unlike Swing, Tapestry is designed to allow stateless
operation, with (mostly) no assumptions about whether you want to have
any session data hanging around between the rendering of a form and
the handling of the form submission.
Still, there is much to think about in your post.
On Tue, May 31, 2011 at 4:44 AM, Inge Solvoll <in...@gmail.com> wrote:
> Hi!
>
> In my new job I've worked a lot with Swing GUI code. I immediately saw the
> strong need for a framework, in order to provide better abstractions, events
> and data binding between GUI and the model layer. The framework market for
> Swing applications is very close to dead, but I found a decent dead
> framework that could be resurrected, named Genesis. After working with it
> for a couple of months, I can see very clear similarities with Tapestry on
> several concepts:
>
> - POJO controller instrumented by annotations.
> - Seamless client event binding.
> - Convention over configuration: Model properties are mapped to GUI controls
> with the same name
> - Automatic type coercion between model and GUI
> - Swing code is isolated and simplified, even more so than T5 templates
>
> Enough off topic :)
>
> When working with T5, one of the (very few) things that I found sub-optimal
> is the Select component. You have to implement 2 interfaces, and it requires
> extra work when dealing with AJAX, which is a very common requirement. In
> Genesis, it is done like the example below. Methods that provide content for
> Select boxes are annotated with @DataProvider. If a Select is dependent on
> some change in the GUI, the data provider method can be annotated with
> @CallWhen to refresh the list when some property on the controller changes.
>
> I would really like to see something similar in T5, allowing the developers
> to specify a collection and a property, without using the T5 custom models
> for Selects. Also, providing AJAX refresh of the content of a Select,
> without exposing AJAX plumbing. I'm thinking the opposite of the zone
> support introduced, allowing a refresh something else. I would like the
> Select to refresh itself on some condition. Please see examples below.
>
>
> public class MyGuiPanel extends JPanel {
> private javax.swing.JComboBox mySelect;
> private javax.swing.JComboBox dependsOnMySelect;
> }
>
> public class MyGuiPanelController {
>
> private MyDomainObject someProperty;
> private MyDomainObject someOtherProperty;
>
> @DataProvider(widgetId="mySelect", property="someProperty")
> public List<MyDoimainObject> getProperties() {
> return db.getProperties();
> }
>
> @CallWhen("genesis.hasChanged('form:someProperty')")
> @DataProvider(widgetId="dependsOnMySelect", property="someOtherProperty")
> public List<MyDoimainObject> getOtherProperties() {
> return db.getProperties();
> }
> }
>
>
>
> Example ideal T5 code for this:
>
> public class MyPage {
>
> @Component(parameters="value=someProperty, list=properties")
> private Select mySelect;
>
> @Component(parameters="value=someOtherProperty, list=otherProperties,
> listenForChangesTo=someProperty")
> private Select mySelect;
> }
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org