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:
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 imple
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 annot
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 insta
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 th
Two separate beans--you create one bean on your view page (to be passed into
BeanDisplay), another bean on your edit page (to be passed into
BeanEditForm). They can have completely distinct sets of properties.
On Mon, Jun 8, 2009 at 11:38 AM, Michael Gerzabek
wrote:
> Hi,
>
> BeanModelSource no
