Complex valueobjects

[WarnerJan Veldhuis <wa...@qprcostcontrol.com>]

Hello,

In order to make some sense to you all, first let me clarify a bit what
my VOs look like. It's called a ModelObjectVO, which has a Map of
AttributeVOs. All AttributeVOs are based on an AttributeDefinitionVO.
These attributes are accessed via a call to
ModelObjectVO#getAttribute(AttributeDefinitionVO). They all return one
or more values, depending on the type (numeric, text, listed, etc). 

What grabbed my enthousiasm, was the feature of the FormTable with the
FieldColumns. I put an AttributeDefinitionVO in my custom FieldColumn,
and the right value was returned by overriding
FieldColumn#getProperty(Object) method. 

Now comes the anti-climax: when that form is submitted, there is no way
to manually set the value for that field. Since the name of the Field
will look like "SA_15", the Ognl lib will look for a property
ModelObjectVO#setSA_15(Object) which is obviously not going to work,
since the value needs to be set on the AttributeVO. 

I immediately wanted to override FieldColum#setValue(), but there was
none :(. Then I was thinking to override Page#onPost() to intercept the
values, but onPost is called *after* Control#onProcess(), where Ognl
bombs out.

Setting the value through Ognl is a nice feature, but, again, just like
all the other frameworks (JSF, Spring, Struts) only work for simple,
bean-like structures. That's the main reason I turned my back on JSF and
Spring, lack of support for complex VOs. Wrapping the ModelObjectVO to
have a gazillion getters/setters is not even an option since the user is
able to define his own AttributeDefintionVOs, so you never know what
you're going to end up with, attribute wise.

What is the best practice for setting values on complex VOs?? Displaying
them is easy, submitting them is a different story...

Sorry for the long boring story, but this is a problem I run into with
every web framework. Thanks for thinking along.

Cheers,

WarnerJan

Re: Complex valueobjects

[WarnerJan Veldhuis <wa...@qprcostcontrol.com>]

Sure, on it.



On Fri, 2009-04-24 at 11:09 +0200, Bob Schellink wrote:
> Hi WarnerJan,
> 
> WarnerJan Veldhuis wrote:
> > 
> > This has resulted in a very clean AbstractAttributeColumn which
> > implements the methods getProperty(Object row) and setProperty(Object
> > row, Field field). I can use the Field to get the Stirng value and parse
> > it to fit my object.
> > 
> > So yes, that would definately work for me. :) 
> 
> 
> Can you file a JIRA for this so we don't forget.
> 
> 
> > 
> > If I can do anything to help Click make more progress I'd be happy to
> > offer my help.
> 
> 
> That's great. There are many ways to contribute depending on what you 
> like to do. For example see:
> 
> http://incubator.apache.org/click/docs/developer-guide/contributing.html
> 
> If you find interesting ways of solving problems with Click you can 
> also add an article to the wiki:
> 
> http://cwiki.apache.org/confluence/display/CLICK/
> 
> kind regards
> 
> bob

Re: Complex valueobjects

[Bob Schellink <sa...@gmail.com>]

Hi WarnerJan,

WarnerJan Veldhuis wrote:
> 
> This has resulted in a very clean AbstractAttributeColumn which
> implements the methods getProperty(Object row) and setProperty(Object
> row, Field field). I can use the Field to get the Stirng value and parse
> it to fit my object.
> 
> So yes, that would definately work for me. :) 


Can you file a JIRA for this so we don't forget.


> 
> If I can do anything to help Click make more progress I'd be happy to
> offer my help.


That's great. There are many ways to contribute depending on what you 
like to do. For example see:

http://incubator.apache.org/click/docs/developer-guide/contributing.html

If you find interesting ways of solving problems with Click you can 
also add an article to the wiki:

http://cwiki.apache.org/confluence/display/CLICK/

kind regards

bob

Re: Complex valueobjects

[Christopher Highway <ch...@gmail.com>]

An idea for an alternative solution which is more generic:

Form supports copyFrom & copyTo which accept a Map object
Maybe this could be implemented in FormTable as well (a list of maps then)

Your VO object sounds a lot like a map, maybe you could implement a
Map interface.

My 2 cents.
Christopher


2009/4/23 WarnerJan Veldhuis <wa...@qprcostcontrol.com>:
> This is how I solved it for now:
>
> - I have overridden FormTable#onProcess() in my own AbstractFormTable
> class
> - Copied the entire contents of FormTable#onProcess()
> - In method onProcess() cast the column to my AbstractAttributeColumn
> - Ripped out the Ognl.setValue(...) part and replaced it with
> myColumn.setProperty(row, field)
> - implemented the setProperty() in various subclasses
>
> This has resulted in a very clean AbstractAttributeColumn which
> implements the methods getProperty(Object row) and setProperty(Object
> row, Field field). I can use the Field to get the Stirng value and parse
> it to fit my object.
>
> So yes, that would definately work for me. :)
>
> If I can do anything to help Click make more progress I'd be happy to
> offer my help.
>
> Cheers,
>
> WarnerJan
>
>
> On Thu, 2009-04-23 at 14:00 +0200, Bob Schellink wrote:
>> WarnerJan Veldhuis wrote:
>> >
>> > Now comes the anti-climax: when that form is submitted, there is no way
>> > to manually set the value for that field. Since the name of the Field
>> > will look like "SA_15", the Ognl lib will look for a property
>> > ModelObjectVO#setSA_15(Object) which is obviously not going to work,
>> > since the value needs to be set on the AttributeVO.
>> >
>> > I immediately wanted to override FieldColum#setValue(), but there was
>> > none :(.
>>
>>
>> Hmm to handle your use case it seems FieldColumn will need a new
>> method setProperty which by default uses OGNL to copy the value to the
>> Object. For more complex use cases it can then be overridden.
>>
>> Would that work for you?
>>
>> kind regards
>>
>> bob
>
>
>

<div><br></div>

Re: Complex valueobjects

[WarnerJan Veldhuis <wa...@qprcostcontrol.com>]

This is how I solved it for now:

- I have overridden FormTable#onProcess() in my own AbstractFormTable
class
- Copied the entire contents of FormTable#onProcess()
- In method onProcess() cast the column to my AbstractAttributeColumn
- Ripped out the Ognl.setValue(...) part and replaced it with
myColumn.setProperty(row, field)
- implemented the setProperty() in various subclasses

This has resulted in a very clean AbstractAttributeColumn which
implements the methods getProperty(Object row) and setProperty(Object
row, Field field). I can use the Field to get the Stirng value and parse
it to fit my object.

So yes, that would definately work for me. :) 

If I can do anything to help Click make more progress I'd be happy to
offer my help.

Cheers,

WarnerJan


On Thu, 2009-04-23 at 14:00 +0200, Bob Schellink wrote:
> WarnerJan Veldhuis wrote:
> > 
> > Now comes the anti-climax: when that form is submitted, there is no way
> > to manually set the value for that field. Since the name of the Field
> > will look like "SA_15", the Ognl lib will look for a property
> > ModelObjectVO#setSA_15(Object) which is obviously not going to work,
> > since the value needs to be set on the AttributeVO. 
> > 
> > I immediately wanted to override FieldColum#setValue(), but there was
> > none :(. 
> 
> 
> Hmm to handle your use case it seems FieldColumn will need a new 
> method setProperty which by default uses OGNL to copy the value to the 
> Object. For more complex use cases it can then be overridden.
> 
> Would that work for you?
> 
> kind regards
> 
> bob

Re: Complex valueobjects

[Bob Schellink <sa...@gmail.com>]

WarnerJan Veldhuis wrote:
> 
> Now comes the anti-climax: when that form is submitted, there is no way
> to manually set the value for that field. Since the name of the Field
> will look like "SA_15", the Ognl lib will look for a property
> ModelObjectVO#setSA_15(Object) which is obviously not going to work,
> since the value needs to be set on the AttributeVO. 
> 
> I immediately wanted to override FieldColum#setValue(), but there was
> none :(. 


Hmm to handle your use case it seems FieldColumn will need a new 
method setProperty which by default uses OGNL to copy the value to the 
Object. For more complex use cases it can then be overridden.

Would that work for you?

kind regards

bob