Yes, what you've described, in general, would work.
Although you wouldn't necessarily need to contribute to
DefaultDataTypeAnalyzer.
If you're already adding the "@DisplayForEdit"-annotated properties in
the decorator, you could easily define the datatype for them
explicitly, as well.
See:
http://tapestry.apache.org/tapestry5.1/apidocs/org/apache/tapestry5/beaneditor/PropertyModel.html#dataType(java.lang.String)
Aside from that, yes, I think the strategy detailed below would work.
Robert
On Jun 9, 2009, at 6/94:55 AM , Michael Gerzabek wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
