On Wed, 05 Nov 2014 07:23:03 -0200, Ivano Luberti <lube...@archicoop.it>
wrote:
Hi, I'm trying to figure out how to add a PropertyEditBlock to have drop
down lists fed by a List type.
What do you mean by "a List type"? java.util.List<SomeClass>?
I have found this example:
http://wiki.apache.org/tapestry/Tapestry5HowToCreateAPropertyEditBlock
but I see links to code are not working anymore: can someone tell me if
that is the right approach before I try it out?
Thank heavens the link to GenericSelectModel is broken, as it was a really
bad idea.
I prefer http://tapestry.apache.org/beaneditform-guide.html, which is a
better description than the page you mentioned above.
http://wiki.apache.org/tapestry/Tapestry5HowToCreateAPropertyEditBlock has
something I don't like at all: creating a class (DropDownList) just for
being used in BeanModel-based components (BeanEditForm, BeanEditor, Grid,
BeanDisplay), not being the type of the field in your domain or entity
class, which would be String, int, an enum, some other custom class, etc.
Instead, I prefer to keep the field in its right type, which is the type
of the options you want to provide.
The implementation varies a bit depending on what the type of the
selection is. If it's an enum or some custom class, you can follow the
http://wiki.apache.org/tapestry/Tapestry5HowToCreateAPropertyEditBlock
example replacing DropDownList by your class and writing an appropriate
ValueEncoder for it. You don't need to subclass AbstractModel yourself:
just use the SelectModelFactory service methods instead.
If it's something like, for example, an int field with values from 0 to
10, the only difference would be creating an annotation (@Rating, for
example), then implementing a DataTypeAnalyzer which retuns "rate" when
the field has @Rating and contribute your newly-written
RatingDataTypeAnalyzer to the DataTypeAnalyzer service. The rest stays the
same.
It seems to me that using List for drop down list is quite mandatory to
manage forms in real world applications.
Yeah, but the way you describe this is too vague to have a single good
implementation for all cases.
BTW: if it is the right approach why not moving that example to official
documentation?
Because the right approach for adding BeanModel edition and viewing blocks
is already at http://tapestry.apache.org/beaneditform-guide.html, Adding
New Property Editors section. ;)
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
