Menu
▾
▴
springframework-developer
|
From: Steven D. <ste...@gm...> - 2005-04-07 14:00:08
|
Guys, Next to the "formObjectClass" property I think it would the useful to add a "formObjectBean" string property which could be any bean ref id in the bean factory (must be prototypes). This way one could control the creation of the beans through Spring. You could for example already fill in default values which could facilitate the re-use of domain classes as form objects. Another remark regarding usage of domain classes as form objects is about jumping over properties in the form object. Say my form object is a Manager instance which has a "person" property. Person has a "name" property. Is it possible to add a "person.name" HTTP parameter that would set the "name" property on the "person" property? regards Steven -- "If you want to be a different fish, you gotta jump out of the school." -- Captain Beefheart |
|
From: Steven D. <ste...@gm...> - 2005-04-07 14:32:22
|
Apparently "person.name" is supported, that is Spring supports the dotted notation when setting properties. As FormAction re-uses org.springframework.validation.DataBinder I suppose dotted HTTP parameters are supported. On Apr 7, 2005 3:59 PM, Steven Devijver <ste...@gm...> wrote: > Guys, > > Next to the "formObjectClass" property I think it would the useful to > add a "formObjectBean" string property which could be any bean ref id > in the bean factory (must be prototypes). This way one could control > the creation of the beans through Spring. You could for example > already fill in default values which could facilitate the re-use of > domain classes as form objects. > > Another remark regarding usage of domain classes as form objects is > about jumping over properties in the form object. Say my form object > is a Manager instance which has a "person" property. Person has a > "name" property. Is it possible to add a "person.name" HTTP parameter > that would set the "name" property on the "person" property? > > regards > > Steven > > -- > "If you want to be a different fish, you gotta jump out of the school." > -- Captain Beefheart > -- "If you want to be a different fish, you gotta jump out of the school." -- Captain Beefheart |
|
From: Keith D. <ke...@in...> - 2005-04-07 14:46:31
|
Yes, that's fully supported. If you'd like to pull a 'formObject' from the context, you should be able to override the loadFormObject or createFormObject method - you should be able to do that dynamically using method injection. Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Steven Devijver Sent: Thursday, April 07, 2005 10:31 AM To: spr...@li... Subject: [Springframework-developer] Re: webflow: improving FormAction Apparently "person.name" is supported, that is Spring supports the dotted notation when setting properties. As FormAction re-uses org.springframework.validation.DataBinder I suppose dotted HTTP parameters are supported. On Apr 7, 2005 3:59 PM, Steven Devijver <ste...@gm...> wrote: > Guys, > > Next to the "formObjectClass" property I think it would the useful to > add a "formObjectBean" string property which could be any bean ref id > in the bean factory (must be prototypes). This way one could control > the creation of the beans through Spring. You could for example > already fill in default values which could facilitate the re-use of > domain classes as form objects. > > Another remark regarding usage of domain classes as form objects is > about jumping over properties in the form object. Say my form object > is a Manager instance which has a "person" property. Person has a > "name" property. Is it possible to add a "person.name" HTTP parameter > that would set the "name" property on the "person" property? > > regards > > Steven > > -- > "If you want to be a different fish, you gotta jump out of the school." > -- Captain Beefheart > -- "If you want to be a different fish, you gotta jump out of the school." -- Captain Beefheart ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Erwin V. <erw...@er...> - 2005-04-07 14:48:54
|
> Next to the "formObjectClass" property I think it would the useful to
> add a "formObjectBean" string property which could be any bean ref id
> in the bean factory (must be prototypes). This way one could control
> the creation of the beans through Spring. You could for example
> already fill in default values which could facilitate the re-use of
> domain classes as form objects.
Mmm, interesting idea, but I'm not sure we should add this (e.g. why doesn't
the
BaseCommandController has this feature?). Anyway, it would be trivial to do
this
in a FormAction subclass:
public class MyFormAction extends FormAction {
private MyBean myBean;
public void setMyBean(MyBean myBean) {
this.myBean = myBean;
}
protected Object loadRequiredFormObject(RequestContext context) throws
FormObjectRetrievalFailureException, IllegalStateException {
return myBean;
}
}
> Another remark regarding usage of domain classes as form objects is
> about jumping over properties in the form object. Say my form object
> is a Manager instance which has a "person" property. Person has a
> "name" property. Is it possible to add a "person.name" HTTP parameter
> that would set the "name" property on the "person" property?
This is possible with the Spring DataBinder. Ofcourse the "getPerson()"
method
on the Manager class should not return null in that case.
Erwin
|
|
From: Steven D. <ste...@gm...> - 2005-04-07 15:10:10
|
In case of a normalized domain model wizards will typically include form fields that span beyond the single class currently created by FormAction. Creating the form object in Spring offers the advantage that related entities could be set on the form object - as required. This would for example avoid that getPerson() would return null. It's just more flexible. > > Mmm, interesting idea, but I'm not sure we should add this (e.g. why doesn't > the > BaseCommandController has this feature?). Anyway, it would be trivial to do > this > in a FormAction subclass: > |
|
From: Erwin V. <erw...@er...> - 2005-04-07 15:23:45
|
I'm sure there are valid use-cases which are easily supported with a subclass like I showed, or with method injection as Keith mentioned. However, I don't think it is typically a good idea to have Spring manage 'domain objects', and a form object is typically a domain object or a simple DTO. I would say the common case is that the Spring application context manages 'service objects': services, DAOs, controllers, ... Erwin Vervaet erw...@er... ----- Original Message ----- From: "Steven Devijver" <ste...@gm...> To: <spr...@li...> Sent: Thursday, April 07, 2005 5:09 PM Subject: Re: [Springframework-developer] webflow: improving FormAction > In case of a normalized domain model wizards will typically include > form fields that span beyond the single class currently created by > FormAction. Creating the form object in Spring offers the advantage > that related entities could be set on the form object - as required. > This would for example avoid that getPerson() would return null. It's > just more flexible. > >> >> Mmm, interesting idea, but I'm not sure we should add this (e.g. why >> doesn't >> the >> BaseCommandController has this feature?). Anyway, it would be trivial to >> do >> this >> in a FormAction subclass: >> > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
