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
