You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Michael Gerzabek <mi...@gmx.net> on 2009/06/08 17:38:47 UTC
T5.1 Question regarding BeanModel and BeanModelSource
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.1 Question regarding BeanModel and BeanModelSource
Posted by Andy Huhn <am...@gmail.com>.
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
<mi...@gmx.net>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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: T5.1 Question regarding BeanModel and BeanModelSource
Posted by Robert Zeigler <ro...@scazdl.org>.
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-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.1 Question regarding BeanModel and BeanModelSource
Posted by Michael Gerzabek <mi...@gmx.net>.
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-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.1 Question regarding BeanModel and BeanModelSource
Posted by Robert Zeigler <ro...@scazdl.org>.
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-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.1 Question regarding BeanModel and BeanModelSource
Posted by Michael Gerzabek <mi...@gmx.net>.
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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.1 Question regarding BeanModel and BeanModelSource
Posted by Robert Zeigler <ro...@scazdl.org>.
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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org