You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Mike Whittaker <mi...@ntlworld.com> on 2003/05/22 21:25:16 UTC
Why not just use Request.getParameterMap() ?
I've been wrestling (and that is the right word) with Struts for a week now.
I'm a bit disillusioned.
Started out tackling the Action & Action Form concept, had a really good
look at the reasoning behing Action Forms, and thought pretty good,
provision for intelligent form use when required, and I can get my old
parameters this way to, all wrapped up in a neat class, then I see that I
have to copy all this data into another object for transmission to Model
layer, a) to keep in with MVC especially since AF uses HttpRequest b) To
ensure forms represent user input and nothing more. Okay fine a routine can
take care of that, shame about the extra object but what the heck. Now I
kick myself and realise I have to deal with links too. Same parameter data
as far as http but is it dealt with by struts? Well I haven't found it. So
it's just the same old HttpRequest.getParameterMap() or whatever. Fine, but
then I might as well get all form input that way too. I suppose the form
validation, when required can call the same model layer code that would
otherwise or also deal with the input.
This isn't really a problem, but I've just heard so much mention of the
process in getting form bean data to the model layer. Why is this
important, there is no difference as far as the Model layer goes between
parameters that originate from forms and those from href tags. So why not
just process a parameter map?
I'm sure when I get into the View side of things, I'll be more impressed.
Please enlighted me.
--
Mike W
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Why not just use Request.getParameterMap() ?
Posted by Erik Price <ep...@ptc.com>.
Mike Whittaker wrote:
[...]
> I see that I
> have to copy all this data into another object for transmission to Model
> layer, a) to keep in with MVC especially since AF uses HttpRequest b) To
> ensure forms represent user input and nothing more. Okay fine a routine can
> take care of that, shame about the extra object but what the heck. Now I
> kick myself and realise I have to deal with links too. Same parameter data
> as far as http but is it dealt with by struts? Well I haven't found it. So
> it's just the same old HttpRequest.getParameterMap() or whatever. Fine, but
> then I might as well get all form input that way too.
[...]
Good point I'm interested in hearing the responses too. Should we build
an Action for processing the GET data out of big hyperlinks too?
(i.e.
<http://domain.com/resource.do?user=2342&searchcrit=some+criteria+here&results=25&offset=20>
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Why not just use Request.getParameterMap() ?
Posted by Ted Husted <hu...@apache.org>.
The ActionForm is suppose to represent the input requirements of your
use-case. Whether the input is entered by hand or entered through a link
or hidden field isn't important.
Many developers now use facades to access their business or system
(persistence) logic. A facade is a coarse-grained representation of the
business API. A good way to think about an ActionForm is as a data-entry
facade. It's a coarse-grained representation of the input requirements
of your application (or module).
There's no requirement that every property on an ActionForm be used by a
particular Action or validation. It's easy to create a base ActionForm
with all the properties your application (or module) needs, and then
subclass it for different use-cases by specializing the validation. With
the Struts validator, this means creating a different form-bean for each
use-case (request/Action/response) that uses a different set of
validations. You can reuse ActionForms with form-beans in the same way
you can reuse the same Action with action-mappings.
Personally, I've found that once you've started to use a business
facade, there's a good case of using a data-entry facade object to go
with it. So, I define a business interface to represent a facade's
data-transfer (or "helper") object. I then implement that interface as
an ActionForm. This way you can pass the ActionForm directly to the
facade (under its interface). For unit tests, I write the tests against
the helper interface, but use the ActionForm implementation.
The *implementation* of both the facade and the facade DTO may use
business objects, but that is not exposed by the interface. (This being
the central idea of a facade.) There is a little extra work here, since
sometimes a property like clientAddress needs to be passed to
client.address. But a flat interface keeps the business API out of the
presentation tier, and the properties can make sure that the business
methods are being accessed safely. (Of course, you could also use a
nested reference, but that can create dependencies on the internal
business API.)
So, for the price of a few extra accessors, you can safely eliminate
duplication and eliminate dependency (Beck's Golden Rule).
HTH, Ted.
Mike Whittaker wrote:
>>There are some decent designs to keep down the amount of duplicate objects
>>you need.
>>
>>1) You can place you model objects into your form and then use nested
>>properties (form.model.property) to set/get them. It works well for forms
>>(though probably wouldn't work very nicely for URL parameters). That way
>>you action class can just pull the fully created model object out of the
>>form and pass it off to the business layer.
>
>
> But the form is supposed to represent user input alone.
> If you ship it to Model layer then change it (eg sql escapeing)...
> Or is this only applicable before validation, after it can't possibly get
> back to the view??
> But what about session forms?
>
>
>>2) Have you business layer expect interfaces (instead of objects)
>>which have
>>no presentation ties. Have you ActionForm implement that interface. Then
>>passing your action form to the business layer isn't so bad. You business
>>layer has no clue that there are presentation related functionality in the
>>model interface coming back to it.
>>
>
> Then you have to have an interface for virtually every form. More
> duplication.
> What if you have (more or less) just one form for your entire app? Then you
> can have one interface. Still doesn't answer the concerns with 1) above
> though.
>
> --
> Mike W.
--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Why not just use Request.getParameterMap() ?
Posted by Mike Whittaker <mi...@ntlworld.com>.
>
>There are some decent designs to keep down the amount of duplicate objects
>you need.
>
>1) You can place you model objects into your form and then use nested
>properties (form.model.property) to set/get them. It works well for forms
>(though probably wouldn't work very nicely for URL parameters). That way
>you action class can just pull the fully created model object out of the
>form and pass it off to the business layer.
But the form is supposed to represent user input alone.
If you ship it to Model layer then change it (eg sql escapeing)...
Or is this only applicable before validation, after it can't possibly get
back to the view??
But what about session forms?
>2) Have you business layer expect interfaces (instead of objects)
>which have
>no presentation ties. Have you ActionForm implement that interface. Then
>passing your action form to the business layer isn't so bad. You business
>layer has no clue that there are presentation related functionality in the
>model interface coming back to it.
>
Then you have to have an interface for virtually every form. More
duplication.
What if you have (more or less) just one form for your entire app? Then you
can have one interface. Still doesn't answer the concerns with 1) above
though.
--
Mike W.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Why not just use Request.getParameterMap() ?
Posted by Jordan Reed <jo...@hotmail.com>.
There are some decent designs to keep down the amount of duplicate objects
you need.
1) You can place you model objects into your form and then use nested
properties (form.model.property) to set/get them. It works well for forms
(though probably wouldn't work very nicely for URL parameters). That way
you action class can just pull the fully created model object out of the
form and pass it off to the business layer.
2) Have you business layer expect interfaces (instead of objects) which have
no presentation ties. Have you ActionForm implement that interface. Then
passing your action form to the business layer isn't so bad. You business
layer has no clue that there are presentation related functionality in the
model interface coming back to it.
-jdr
On 5/22/03 12:25 PM, "Mike Whittaker" <mi...@ntlworld.com> wrote:
> I've been wrestling (and that is the right word) with Struts for a week now.
> I'm a bit disillusioned.
>
> Started out tackling the Action & Action Form concept, had a really good
> look at the reasoning behing Action Forms, and thought pretty good,
> provision for intelligent form use when required, and I can get my old
> parameters this way to, all wrapped up in a neat class, then I see that I
> have to copy all this data into another object for transmission to Model
> layer, a) to keep in with MVC especially since AF uses HttpRequest b) To
> ensure forms represent user input and nothing more. Okay fine a routine can
> take care of that, shame about the extra object but what the heck. Now I
> kick myself and realise I have to deal with links too. Same parameter data
> as far as http but is it dealt with by struts? Well I haven't found it. So
> it's just the same old HttpRequest.getParameterMap() or whatever. Fine, but
> then I might as well get all form input that way too. I suppose the form
> validation, when required can call the same model layer code that would
> otherwise or also deal with the input.
> This isn't really a problem, but I've just heard so much mention of the
> process in getting form bean data to the model layer. Why is this
> important, there is no difference as far as the Model layer goes between
> parameters that originate from forms and those from href tags. So why not
> just process a parameter map?
> I'm sure when I get into the View side of things, I'll be more impressed.
>
> Please enlighted me.
>
> --
> Mike W
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org