Hm, I'm not sure I fully understand your use-case.
For instance, in the example you provide, using createDisplayModel
would already pick up the read-only "description" property.
In any event, there are lots of ways you could go imagine handling this.
For example, you could write a custom annotation:
@DisplayForEdit
And then you could provide a service override (or a service decorator)
of BeanModelSource that checks for properties with DisplayForEdit and
adds them to the model. Then your call to:
modelSource.createEditModel would include all read-only properties
annotated with DisplayForEdit, as well as the editable properties.
But you'd have to be careful with an approach like that because unless
you define a custom block for displaying the property, tapestry will,
by default, try to create an editor for the property (if you're using
BeanEditor or BeanEditForm), and it'll complain that there's no setter
for your property.
Additionally, the BeanDisplay, BeanEditor, BeanEditForm, and Grid
components all accept "include", "exclude", "add", and "reorder"
parameters, so you can decide what belongs in your model in a
declarative fashion:
<t:beandisplay object="myobj" include="description"/>
<t:beaneditform object="myobj" include="declared"/>
Robert
On Jun 8, 2009, at 6/811:39 PM , Michael Gerzabek wrote:
Thank you Robert!
To give you a way of looking at my problem.
Bean Customizing has some usual properties that are read only, like
symbol, isDeclared, etc. but only one property that is writeable,
the value. The read only properties provide meaning to the person
fostering the Customizing instance.
Now there is the usual approach that I prepare a distinct page
(which in fact I did) to collect the value for the Customizing
instance. This page displays the rest of the bean in a verbose mode
to the user. Straight forward, no problem.
Anyway, I'm just curious: Since I can imagine many occasions where a
bean not only would hold data but also some semantics on the data
that would be useful to be displayed to a person editing this bean.
Is there a standard way to get this job done by BeanEditor/ BeanModel?
To pick up your snippet: On my concrete BeanModel for bean
Customizing I would need something like
BeanModel<Customizing> getModel() {
BeanModel<Customizing> model =
beanModelSource.createDisplayModel( Customizing.class, messages );
// property description is read only but contains information on how
the
// fostering of this Customizing instance will influence the
behaviour of
// the application
model.display( "description" );
return model;
}
Is there a way to get this done? Would be nice somehow.
Michael
Zeigler schrieb:
So:
1) createDisplayModel() acts the same as
createModel(...,false,...); and createEditModel is like
createModel(...,true,...)
So if you have your bean, the @NonVisual properties won't show
up for editing or display. Using createDisplayModel will add all
properties with a getter that aren't otherwise marked as
@NonVisual, and using createEditModel will only add the properties
will getters and setters. But once you have the model, you can
manipulate it anyway you want. For example:
BeanModel<MyBean> getModel() {
BeanModel<MyBean> model =
beanModelSource.createDisplayModel(MyBean.class,messages);
model.exclude("someProp");
return model;
}
Robert
On Jun 8, 2009, at 6/810:38 AM , Michael Gerzabek wrote:
Hi,
BeanModelSource now has deprecated create(..) in favor of
createDisplayModel(..) and createEditModel(..). This is a nice
feature leaving me with one question:
I want to edit a bean that has some properties that should not be
displayed at all (@NonVisual), some properties that should be
displayed but not enabled for editing. Those properties can have
setters but some also don't have setters at all. And then there
are some properties that should be editable. How would I achive
this?
Thanks for your help,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
