Ok, thank you Robert!
Let me rephrase/ summarize that using the @DisplayForEdit approach you
kindly offered.
Step 1: Create a custom annotation @DisplayForEdit for properties
without setter that should be displayed when editing is used in
BeanEdit/Form.
Step 2: Then a decorator would implement the logic for detecting this
annotation and adding the corresponding property to the BeanModel.
This would be done with something like
model.add( "display" );
in my former example. The decorator would be configured like explained
in the ioc cookbook [1].
Now my call to modelSource.createEditModel(..) includes 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."
Ok. I use BeanEditor/Form, so this is something I've to get clear about.
I found that the @DataType annotation makes it explicit what property
editor to use for a specific property. So when I enhance the
@DisplayForEdit annotation to further act like the @DataType annotation
I could contribute a new property editor like pointed out in the
BeanEditFormGuide [2].
So let's continue with Step 3:
I would
public static void contributeDefaultDataTypeAnalyzer(MappedConfiguration<Class,
String> configuration) {
configuration.add( Object.class, "display" );
}
add a property block to my AppPropertyEditBlocks and contribute this to
the BeanBlockSource.
The PropertyEditBlocks would simply return a NOPValidator and a
NOPTranslator. My block would look like
<t:block id="display">
<t:label for="display"/>
<t:div t:id="display">${display}</div>
</t:block>
where I've something like @Component(..) private Object display; in my
PropertyEditBlocks.
Is this what you suggested - what would work?
Thanks,
Michael
[1]
http://tapestry.apache.org/tapestry5.1/tapestry-ioc/cookbook/override.html
[2] http://tapestry.apache.org/tapestry5.1/guide/beaneditform.html
Robert Zeigler schrieb:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
