Simpler Select configuration

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Simpler Select configuration

Inge Solvoll-2
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;
}
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simpler Select configuration

bobharner
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simpler Select configuration

joshcanfield
> 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" <[hidden email]> 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 <[hidden email]>
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simpler Select configuration

lltyk
In reply to this post by bobharner
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simpler Select configuration

Thiago H de Paula Figueiredo
On Fri, 03 Jun 2011 08:22:13 -0300, LLTYK <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simpler Select configuration

bobharner
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
<[hidden email]> wrote:

> On Fri, 03 Jun 2011 08:22:13 -0300, LLTYK <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simpler Select configuration

Taha Hafeez
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 <[hidden email]> 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
> <[hidden email]> wrote:
> > On Fri, 03 Jun 2011 08:22:13 -0300, LLTYK <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simpler Select configuration

Taha Hafeez
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 <[hidden email]>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 <[hidden email]> 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
>> <[hidden email]> wrote:
>> > On Fri, 03 Jun 2011 08:22:13 -0300, LLTYK <[hidden email]> 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: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simpler Select configuration

Howard Lewis Ship
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 <[hidden email]> 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 <[hidden email]>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 <[hidden email]> 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
>>> <[hidden email]> wrote:
>>> > On Fri, 03 Jun 2011 08:22:13 -0300, LLTYK <[hidden email]> 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: [hidden email]
>>> > For additional commands, e-mail: [hidden email]
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>



--
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simpler Select configuration

Taha Hafeez
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]
> >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 <[hidden email]> 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
> >>> <[hidden email]> wrote:
> >>> > On Fri, 03 Jun 2011 08:22:13 -0300, LLTYK <[hidden email]>
> 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: [hidden email]
> >>> > For additional commands, e-mail: [hidden email]
> >>> >
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>
> >
>
>
>
> --
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simpler Select configuration

lltyk
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simpler Select configuration

Inge Solvoll-2
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Loading...