You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Christoph Jaeger <ch...@derwald.at> on 2007/10/27 23:16:17 UTC
T5: BeanEditForm
Hi,
I like using the BeanEditForm, but I think there should be some
additional annotations to make it even easier to use.
There is already an annotation called "NonVisual" to mark properties you
do not want to display on your page.
How about
@Display(type=password)
so you do not have to use
<t:parameter name="password">
<t:label for="password"/>
<t:passwordfield t:id="password" value="person.password"/>
</t:parameter>
or
@Display(type=multiline)
instead of
<t:parameter name="address">
<t:label for="address"/>
<t:textarea t:id="address" value="person.address"/>
</t:parameter>
or
@Display(type=text, length=30)
for
<t:parameter name="email">
<t:label for="email"/>
<t:textfield t:id="email" value="person.email" size="30"/>
</t:parameter>
I think this would increase the chances of using just
<t:beaneditform object="person"/>
in your .tml files. Or is something like this already implemented, and I
just overlooked it?
Thanks,
Christoph Jäger
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: BeanEditForm
Posted by Howard Lewis Ship <hl...@gmail.com>.
I've been thinking in terms of @Type("foo"). Right now, it is deducing the
type exclusively from the Java type: so String and Number -> text, etc.
Allowing @Type would provide an easy way to reference additional, or custom,
types such as "password" or "textarea", etc.
On 10/27/07, Christoph Jaeger <ch...@derwald.at> wrote:
>
> Hi,
>
> I like using the BeanEditForm, but I think there should be some
> additional annotations to make it even easier to use.
>
> There is already an annotation called "NonVisual" to mark properties you
> do not want to display on your page.
>
> How about
>
> @Display(type=password)
>
> so you do not have to use
>
> <t:parameter name="password">
> <t:label for="password"/>
> <t:passwordfield t:id="password" value="person.password"/>
> </t:parameter>
>
> or
>
> @Display(type=multiline)
>
> instead of
>
> <t:parameter name="address">
> <t:label for="address"/>
> <t:textarea t:id="address" value="person.address"/>
> </t:parameter>
>
> or
>
> @Display(type=text, length=30)
>
> for
>
> <t:parameter name="email">
> <t:label for="email"/>
> <t:textfield t:id="email" value="person.email" size="30"/>
> </t:parameter>
>
> I think this would increase the chances of using just
>
> <t:beaneditform object="person"/>
>
> in your .tml files. Or is something like this already implemented, and I
> just overlooked it?
>
> Thanks,
>
> Christoph Jäger
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Partner and Senior Architect at Feature50
Creator Apache Tapestry and Apache HiveMind
Re: T5: BeanEditForm
Posted by Kalle Korhonen <ka...@gmail.com>.
How Trails does it, is that it builds descriptors (that hold metadata) for
the business classes and their properties. You can modify this metadata with
annotations (that you would attach directly to the business entity), or
later on, programmatically in the page class. Type, size, validation, etc
are also meaningful for the persistence layer and in case the user chooses
to integrate with Hibernate and its annotations, Trails would use the same
values as defaults for the property descriptors as much as possible.
Finally, you have an array of property editors that by default are
associated with specific types (Integer, String, Date, a type of association
with another entity), but you can override, customize and change this
association in the page templates as you wish.
I think a separate UI object is a thing of the past; maintaining object's
metadata and making it customizable when needed is a better way to go. Tap5
is a constant topic for us as well, and it's interesting to see how much of
Trails-like functionality and foundation is already in place in Tap5.
Kalle
On 10/27/07, Christoph Jaeger <ch...@derwald.at> wrote:
>
> When I initially saw Howard's screencast, the first thing that came to
> my mind was similar to your thoughts: this binds view and model too
> close together. I don't want to have view-related annotations in my
> business objects.
>
> Then I thought about how to solve this. Somehow you have to define which
> properties of your business object you want to expose to the user for
> editing. Things like the primary key, or a last modified date, which
> automatically updates on each save, do not belong on the edit page.
> Also, you might have situations, where there are several edit pages, one
> for a normal user, who might edit some fields, and one for an
> administrator, who can change more than the normal user.
>
> One possibility of defining this is to create a pure UI object. This
> object only has the properties used for editing (+ some way to find back
> to the original business object, primary key would be a good idea). You
> can have different UI objects for the same business object depending on
> what you want to edit. You can pack any number of view related
> information (annotations) into your object, as this is your view.
>
> Drawback: now you have to write code to create a UI object from a
> business object, and to copy back changes from an UI object to the
> business object, in case the user hits the save button. But this binding
> can be done with the same techniques already used for binding object to
> the UI. For instance, fields with the same name in business object and
> UI object are easy (can be done automatically). Some other bindings may
> need manual coding.
>
> Does this make sense?
>
> Christoph
>
> Christian Gruber wrote:
> > Hmm. I've definitely wondered this as well. Unfortunately, something
> > like this might bind the view and the model too closely together.
> > You're really then instrumenting your model not with business logic
> > (per, validate) but with display characteristics which starts to move
> > away from the point of an MVC architecture. I can see the convenience,
> > but I wonder if there's a more model-oriented way of describing this
> > which the view (beaneditform) can interpret. Can't think of a good
> > approach at the moment, but there should be one. It might amount to the
> > same thing, but with less display-centric terminology.
> >
> > Christian.
> >
> > On 27-Oct-07, at 5:16 PM, Christoph Jaeger wrote:
> >
> >> Hi,
> >>
> >> I like using the BeanEditForm, but I think there should be some
> >> additional annotations to make it even easier to use.
> >>
> >> There is already an annotation called "NonVisual" to mark properties
> you
> >> do not want to display on your page.
> >>
> >> How about
> >>
> >> @Display(type=password)
> >>
> >> so you do not have to use
> >>
> >> <t:parameter name="password">
> >> <t:label for="password"/>
> >> <t:passwordfield t:id="password" value="person.password"/>
> >> </t:parameter>
> >>
> >> or
> >>
> >> @Display(type=multiline)
> >>
> >> instead of
> >>
> >> <t:parameter name="address">
> >> <t:label for="address"/>
> >> <t:textarea t:id="address" value="person.address"/>
> >> </t:parameter>
> >>
> >> or
> >>
> >> @Display(type=text, length=30)
> >>
> >> for
> >>
> >> <t:parameter name="email">
> >> <t:label for="email"/>
> >> <t:textfield t:id="email" value="person.email" size="30"/>
> >> </t:parameter>
> >>
> >> I think this would increase the chances of using just
> >>
> >> <t:beaneditform object="person"/>
> >>
> >> in your .tml files. Or is something like this already implemented, and
> I
> >> just overlooked it?
> >>
> >> Thanks,
> >>
> >> Christoph Jäger
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: T5: BeanEditForm
Posted by Howard Lewis Ship <hl...@gmail.com>.
Two notes:
1) I've moved the annotations out of tapestry proper, into a tiny additional
JAR containing just the annotations. This makes it more palatable to use
them outside of the web tier without dragging in an extra MB or so of
dependencies.
2) The mechanism by which we go from beans and properties to editors is
actually documented (!) and extensible. There's an extensible chain of
command, so if you have an external approach to making this decisions (such
as an XML file) you still have the hooks to get in and make that happen.
See the DataTypeAnalyzer interface
On 10/27/07, Christoph Jaeger <ch...@derwald.at> wrote:
>
> When I initially saw Howard's screencast, the first thing that came to
> my mind was similar to your thoughts: this binds view and model too
> close together. I don't want to have view-related annotations in my
> business objects.
>
> Then I thought about how to solve this. Somehow you have to define which
> properties of your business object you want to expose to the user for
> editing. Things like the primary key, or a last modified date, which
> automatically updates on each save, do not belong on the edit page.
> Also, you might have situations, where there are several edit pages, one
> for a normal user, who might edit some fields, and one for an
> administrator, who can change more than the normal user.
>
> One possibility of defining this is to create a pure UI object. This
> object only has the properties used for editing (+ some way to find back
> to the original business object, primary key would be a good idea). You
> can have different UI objects for the same business object depending on
> what you want to edit. You can pack any number of view related
> information (annotations) into your object, as this is your view.
>
> Drawback: now you have to write code to create a UI object from a
> business object, and to copy back changes from an UI object to the
> business object, in case the user hits the save button. But this binding
> can be done with the same techniques already used for binding object to
> the UI. For instance, fields with the same name in business object and
> UI object are easy (can be done automatically). Some other bindings may
> need manual coding.
>
> Does this make sense?
>
> Christoph
>
> Christian Gruber wrote:
> > Hmm. I've definitely wondered this as well. Unfortunately, something
> > like this might bind the view and the model too closely together.
> > You're really then instrumenting your model not with business logic
> > (per, validate) but with display characteristics which starts to move
> > away from the point of an MVC architecture. I can see the convenience,
> > but I wonder if there's a more model-oriented way of describing this
> > which the view (beaneditform) can interpret. Can't think of a good
> > approach at the moment, but there should be one. It might amount to the
> > same thing, but with less display-centric terminology.
> >
> > Christian.
> >
> > On 27-Oct-07, at 5:16 PM, Christoph Jaeger wrote:
> >
> >> Hi,
> >>
> >> I like using the BeanEditForm, but I think there should be some
> >> additional annotations to make it even easier to use.
> >>
> >> There is already an annotation called "NonVisual" to mark properties
> you
> >> do not want to display on your page.
> >>
> >> How about
> >>
> >> @Display(type=password)
> >>
> >> so you do not have to use
> >>
> >> <t:parameter name="password">
> >> <t:label for="password"/>
> >> <t:passwordfield t:id="password" value="person.password"/>
> >> </t:parameter>
> >>
> >> or
> >>
> >> @Display(type=multiline)
> >>
> >> instead of
> >>
> >> <t:parameter name="address">
> >> <t:label for="address"/>
> >> <t:textarea t:id="address" value="person.address"/>
> >> </t:parameter>
> >>
> >> or
> >>
> >> @Display(type=text, length=30)
> >>
> >> for
> >>
> >> <t:parameter name="email">
> >> <t:label for="email"/>
> >> <t:textfield t:id="email" value="person.email" size="30"/>
> >> </t:parameter>
> >>
> >> I think this would increase the chances of using just
> >>
> >> <t:beaneditform object="person"/>
> >>
> >> in your .tml files. Or is something like this already implemented, and
> I
> >> just overlooked it?
> >>
> >> Thanks,
> >>
> >> Christoph Jäger
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Partner and Senior Architect at Feature50
Creator Apache Tapestry and Apache HiveMind
Re: T5: BeanEditForm
Posted by Christoph Jaeger <ch...@derwald.at>.
When I initially saw Howard's screencast, the first thing that came to
my mind was similar to your thoughts: this binds view and model too
close together. I don't want to have view-related annotations in my
business objects.
Then I thought about how to solve this. Somehow you have to define which
properties of your business object you want to expose to the user for
editing. Things like the primary key, or a last modified date, which
automatically updates on each save, do not belong on the edit page.
Also, you might have situations, where there are several edit pages, one
for a normal user, who might edit some fields, and one for an
administrator, who can change more than the normal user.
One possibility of defining this is to create a pure UI object. This
object only has the properties used for editing (+ some way to find back
to the original business object, primary key would be a good idea). You
can have different UI objects for the same business object depending on
what you want to edit. You can pack any number of view related
information (annotations) into your object, as this is your view.
Drawback: now you have to write code to create a UI object from a
business object, and to copy back changes from an UI object to the
business object, in case the user hits the save button. But this binding
can be done with the same techniques already used for binding object to
the UI. For instance, fields with the same name in business object and
UI object are easy (can be done automatically). Some other bindings may
need manual coding.
Does this make sense?
Christoph
Christian Gruber wrote:
> Hmm. I've definitely wondered this as well. Unfortunately, something
> like this might bind the view and the model too closely together.
> You're really then instrumenting your model not with business logic
> (per, validate) but with display characteristics which starts to move
> away from the point of an MVC architecture. I can see the convenience,
> but I wonder if there's a more model-oriented way of describing this
> which the view (beaneditform) can interpret. Can't think of a good
> approach at the moment, but there should be one. It might amount to the
> same thing, but with less display-centric terminology.
>
> Christian.
>
> On 27-Oct-07, at 5:16 PM, Christoph Jaeger wrote:
>
>> Hi,
>>
>> I like using the BeanEditForm, but I think there should be some
>> additional annotations to make it even easier to use.
>>
>> There is already an annotation called "NonVisual" to mark properties you
>> do not want to display on your page.
>>
>> How about
>>
>> @Display(type=password)
>>
>> so you do not have to use
>>
>> <t:parameter name="password">
>> <t:label for="password"/>
>> <t:passwordfield t:id="password" value="person.password"/>
>> </t:parameter>
>>
>> or
>>
>> @Display(type=multiline)
>>
>> instead of
>>
>> <t:parameter name="address">
>> <t:label for="address"/>
>> <t:textarea t:id="address" value="person.address"/>
>> </t:parameter>
>>
>> or
>>
>> @Display(type=text, length=30)
>>
>> for
>>
>> <t:parameter name="email">
>> <t:label for="email"/>
>> <t:textfield t:id="email" value="person.email" size="30"/>
>> </t:parameter>
>>
>> I think this would increase the chances of using just
>>
>> <t:beaneditform object="person"/>
>>
>> in your .tml files. Or is something like this already implemented, and I
>> just overlooked it?
>>
>> Thanks,
>>
>> Christoph Jäger
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: BeanEditForm
Posted by Christian Gruber <ch...@gmail.com>.
Hmm. I've definitely wondered this as well. Unfortunately, something
like this might bind the view and the model too closely together.
You're really then instrumenting your model not with business logic
(per, validate) but with display characteristics which starts to move
away from the point of an MVC architecture. I can see the
convenience, but I wonder if there's a more model-oriented way of
describing this which the view (beaneditform) can interpret. Can't
think of a good approach at the moment, but there should be one. It
might amount to the same thing, but with less display-centric
terminology.
Christian.
On 27-Oct-07, at 5:16 PM, Christoph Jaeger wrote:
> Hi,
>
> I like using the BeanEditForm, but I think there should be some
> additional annotations to make it even easier to use.
>
> There is already an annotation called "NonVisual" to mark properties
> you
> do not want to display on your page.
>
> How about
>
> @Display(type=password)
>
> so you do not have to use
>
> <t:parameter name="password">
> <t:label for="password"/>
> <t:passwordfield t:id="password" value="person.password"/>
> </t:parameter>
>
> or
>
> @Display(type=multiline)
>
> instead of
>
> <t:parameter name="address">
> <t:label for="address"/>
> <t:textarea t:id="address" value="person.address"/>
> </t:parameter>
>
> or
>
> @Display(type=text, length=30)
>
> for
>
> <t:parameter name="email">
> <t:label for="email"/>
> <t:textfield t:id="email" value="person.email" size="30"/>
> </t:parameter>
>
> I think this would increase the chances of using just
>
> <t:beaneditform object="person"/>
>
> in your .tml files. Or is something like this already implemented,
> and I
> just overlooked it?
>
> Thanks,
>
> Christoph Jäger
>
>
> ---------------------------------------------------------------------
> 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