> 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" <bobhar...@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 <inge.tapes...@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-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>

Reply via email to