You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by William Shulman <wi...@metaconsortium.com> on 2001/12/07 12:06:43 UTC

servlet question

Assume one is using a servlet container (like Tomcat or similar).
Is there a way to specify to the servlet container which class 
implementations to use for HttpServletRequest and Session ? 
I am guessing that there may exist factories for producing 
instances of these classes and I am wondering if there is a 
hook, standard or specific to vendor, that will allow me to 
specify my own implementations of these classes / interfaces.

thanks in advance
-will

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Struts Design question

Posted by Ted Husted <hu...@apache.org>.
Ted Husted wrote:
> If you find something that works better for you, be sure to report back.
> We aren't jealous ;-) Adopt and adapt.

Or, if you find one I haven't listed here, be sure to let me know. 

http://husted.com/struts/links.htm#mvc/frameworks


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Struts Design question

Posted by Ted Husted <hu...@apache.org>.
Jon Wall wrote:
> 1.  The String/boolean requirement.  Everything I'd
> tested happened to be String or boolean, but Ted
> pointed out this wouldn't work for nested tags.  I'm
> assuming, then, that the ActionForm performs another
> function that I hadn't thought about - converting the
> String and boolean props that you're bringing in on
> the web to the navtive structure used by the backend.
> Is this true?  So what you're telling me is...I not
> only need to create an ActionForm class for each of my
> many components (100+) that actually implements each
> of the public methods, but for each of the non
> String/boolean properties I need to make a sort of
> formatter method.  

The ActionForm is really about buffering. It gives the HTML controls
persistance, until the data can be validated and/of converted to your
native structures. What happens when someone tries to toss "47a" at an
Integer property? HTTP is a hostile, uncontrolled environment, and the
ActionForms are designed to compensate for that. 

But keep in mind that ActionForms are just for HTML Form input. They are
not expected to be used as anything but buffers for the html form tags.
You do not have to use them to retrieve widgets, just to send widgets
data they need to store.

Once the ActionForm is validated, the BeanUtils can be a very handy way
to copy the data over to your native beans. Usually, you just need to
define your ActionForm properties to match your native bean property
names. The problem is, you need a place to stand if the data fails
validation, and can't be transferred to your native beans. There lies
the rub.


> And keep up with this process with
> every new component, and more difficult yet keep up
> with every new method on existing components.  Eeek.
> I know that I can automate this kind of thing...but it
> might be enough to keep me from using this framework.
> I understand the ROI theory and all that, but the
> unfortunate reality is that my development schedule is
> way too tight to take time out to work on something
> like this.  Am I grasping if I ask if there's any
> generic tools out there to do something like this?

If you find something that works better for you, be sure to report back.
We aren't jealous ;-) Adopt and adapt.



> 2.  This also explains my original troubles with my
> Save action I think, because I was trying to nest my
> components.  The real issue is that i need to call
> WidgetForm.setWidget() to initialize my widget's
> properties to what is already in the database before
> Struts autopopulates the widget properties using
> values from the form.  My new understanding of the
> Struts paradigm (please correct me if I'm wrong) is
> that the ActionForm shouldn't nest the components, but
> rather should mirror it and not contain the widget at
> all.  Let Struts autopopulate the ActionForm, and then
> use BeanUtils.populate() to copy the info over.

In practice, most pre-existing components are not suited for use as a
buffer for HTML controls, which is what the ActionForms do. If a
component is suited as a buffer for a HTML control, then there is no
reason not to nest it.

A good candidate for a HTML buffer uses a String or boolean for storage,
and can store invalid input before committing it to your model.
Generally, most components are designed to do exactly the opposite --
accept or reject input, period.


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Struts Design question

Posted by Jon Wall <jw...@yahoo.com>.
Hi Ted -

Thanks for the input.  A light went on when I read
this...I'd initially wanted to just include my
existing components in a thin "composition" ActionForm
class - in other words, if I had a "Widget" component,
I'd create a WidgetForm class with getWidget() and
setWidget(), then my form would use the nested syntax,
ie "widget.prop1", "widget.prop2".  This was working
great for the Edit and Add actions, but was probably
the cause for my problems with the Save action.  I'm
realizing a couple of problems with this method...

1.  The String/boolean requirement.  Everything I'd
tested happened to be String or boolean, but Ted
pointed out this wouldn't work for nested tags.  I'm
assuming, then, that the ActionForm performs another
function that I hadn't thought about - converting the
String and boolean props that you're bringing in on
the web to the navtive structure used by the backend. 
Is this true?  So what you're telling me is...I not
only need to create an ActionForm class for each of my
many components (100+) that actually implements each
of the public methods, but for each of the non
String/boolean properties I need to make a sort of
formatter method.  And keep up with this process with
every new component, and more difficult yet keep up
with every new method on existing components.  Eeek. 
I know that I can automate this kind of thing...but it
might be enough to keep me from using this framework. 
I understand the ROI theory and all that, but the
unfortunate reality is that my development schedule is
way too tight to take time out to work on something
like this.  Am I grasping if I ask if there's any
generic tools out there to do something like this?  

2.  This also explains my original troubles with my
Save action I think, because I was trying to nest my
components.  The real issue is that i need to call
WidgetForm.setWidget() to initialize my widget's
properties to what is already in the database before
Struts autopopulates the widget properties using
values from the form.  My new understanding of the
Struts paradigm (please correct me if I'm wrong) is
that the ActionForm shouldn't nest the components, but
rather should mirror it and not contain the widget at
all.  Let Struts autopopulate the ActionForm, and then
use BeanUtils.populate() to copy the info over.  



thanks again for any help...
-jon



--- Ted Husted <hu...@apache.org> wrote:
> Jon Wall wrote:
> > 
> > I've been lurking on this list for a while, and I
> > finally have time to look hard at Struts for a web
> > application that I'm working on. I have a coupla
> > questions.. 1. This first question I found
> reference
> > to in the archives
> >
>
(http://www.mail-archive.com/struts-user@jakarta.apache.org/msg18281.html)
> > but couldn't find an answer.
> 
> We tried making the ActionForm an interface in the
> first place, but, in
> practice, there were simply too many side effects. 
> 
>
http://www.mail-archive.com/struts-dev%40jakarta.apache.org/msg03590.html
> 
>
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg08070.html
> 
> If your JavaBean only uses String and boolean
> properties, and doesn't
> make immediate state changes to your model, you can
> nest it and use the
> dotted syntax. Otherwise, it's a wild goose chase.
> 
> 
> > In the application I'm
> > working on the business logic is already written
> and
> > is being added to by another team (it's supporting
> > other applications besides the web). So I've got a
> > whole slew of JavaBeans (100+) already written for
> me,
> > but now I'm facing the task of wrapping them in
> > ActionForm subclasses, cursing under my breath
> that it
> > isn't an interface. I understand that the purpose
> of
> > the ActionForm is as a buffer..perform validation
> and
> > all that. But my beans already contain the
> validation!
> > Besides, performing the validation in the
> ActionForm
> > is effectively tying business logic (data
> validation)
> > to the web framework dontya think?
> 
> It's really more about correction than validation.
> The validate method
> can wrap methods from the business layer, or the
> Action can do that
> instead and then return the ActionForm itself. But
> the main thing is
> that most existing beans expect native types that
> can't be properly
> represented by a HTML control.
> 
> Your beans may contain validation, but can they
> return the invalid input
> to the user for correction? That's what ActionForms
> are for. To buffer
> data so it ~can be~ validated, and returned for
> correction if it is not.
> 
> So, you take the data from the ActionForm, and
> present it to your bean.
> If your bean rejects it, you use the ActionForm to
> ferry the whole
> she-bang back to the user, so they can fix it and
> try again.
> 
> The ActionForm also serves as firewall, since the
> autopopulation
> mechanism can be used to affect any public method on
> your JavaBean, not
> just the ones you put on the form. This is
> exploitable by a hostile
> user.
> 
> 
> > Rules such as no
> > invoice numbers under 1000 (Ted's example) should
> be
> > handled by the business logic, and given my
> situation
> > (probably a common one), this logic needs to be
> shared
> > between applications. I can't go into the server
> > system and fit ActionForm into the class
> heirarchy,
> > but I sure could have thrown an interface in
> there.
> 
> It should not be in your heirarchy, but used to
> transfer data *to* your
> heirarchy. One good way to do this is to match the
> ActionForm properties
> to the properties on your JavaBeans, and use the
> reflection methods in
> BeanUtils to punch it over. If you put describe and
> populate together,
> you can populate just about anything from just about
> anything.
> 
> 
> 
> > Input on this is appreciated. 2. This has to have
> come
> > up before, but I couldn't find any references. All
> of
> > my JavaBeans map to persistent components, all of
> > which have id's. I've written some actions to
> display
> > lists of these components and the like and
> everything
> > works great. I also started to try the
> Add/Edit/Save
> > pattern, which occurs everywhere in the app, and
> I'm
> > having a problem with the Save action. The issue
> is
> > that I need to retrieve the object from the
> datastore
> > (using the id) *before* the ActionForm is
> populated
> > with the request parameters.
> > What I'd like is to have
> > the bean populated from the database, and then any
> > parameters that are present on the request object
> set
> > on the bean, then persist. I can't figure out how
> to
> > initialize the bean to the datastore before it
> gets to
> > me in the Action. 
> 
> Go to the Action first, populate the ActionForm and
> then forward to the
> JSP. The form tags will see the ActionForm, and use
> it to populate
> themselves. Then when the form is submitted, it is
> populated from the
> request parameters "again", closing the loop.
> 
> 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/struts/
> 
> --
> To unsubscribe, e-mail:  
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 


__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Struts Design question

Posted by Ted Husted <hu...@apache.org>.
Jon Wall wrote:
> 
> I've been lurking on this list for a while, and I
> finally have time to look hard at Struts for a web
> application that I'm working on. I have a coupla
> questions.. 1. This first question I found reference
> to in the archives
> (http://www.mail-archive.com/struts-user@jakarta.apache.org/msg18281.html)
> but couldn't find an answer.

We tried making the ActionForm an interface in the first place, but, in
practice, there were simply too many side effects. 

http://www.mail-archive.com/struts-dev%40jakarta.apache.org/msg03590.html

http://www.mail-archive.com/struts-user@jakarta.apache.org/msg08070.html

If your JavaBean only uses String and boolean properties, and doesn't
make immediate state changes to your model, you can nest it and use the
dotted syntax. Otherwise, it's a wild goose chase.


> In the application I'm
> working on the business logic is already written and
> is being added to by another team (it's supporting
> other applications besides the web). So I've got a
> whole slew of JavaBeans (100+) already written for me,
> but now I'm facing the task of wrapping them in
> ActionForm subclasses, cursing under my breath that it
> isn't an interface. I understand that the purpose of
> the ActionForm is as a buffer..perform validation and
> all that. But my beans already contain the validation!
> Besides, performing the validation in the ActionForm
> is effectively tying business logic (data validation)
> to the web framework dontya think?

It's really more about correction than validation. The validate method
can wrap methods from the business layer, or the Action can do that
instead and then return the ActionForm itself. But the main thing is
that most existing beans expect native types that can't be properly
represented by a HTML control.

Your beans may contain validation, but can they return the invalid input
to the user for correction? That's what ActionForms are for. To buffer
data so it ~can be~ validated, and returned for correction if it is not.

So, you take the data from the ActionForm, and present it to your bean.
If your bean rejects it, you use the ActionForm to ferry the whole
she-bang back to the user, so they can fix it and try again.

The ActionForm also serves as firewall, since the autopopulation
mechanism can be used to affect any public method on your JavaBean, not
just the ones you put on the form. This is exploitable by a hostile
user.


> Rules such as no
> invoice numbers under 1000 (Ted's example) should be
> handled by the business logic, and given my situation
> (probably a common one), this logic needs to be shared
> between applications. I can't go into the server
> system and fit ActionForm into the class heirarchy,
> but I sure could have thrown an interface in there.

It should not be in your heirarchy, but used to transfer data *to* your
heirarchy. One good way to do this is to match the ActionForm properties
to the properties on your JavaBeans, and use the reflection methods in
BeanUtils to punch it over. If you put describe and populate together,
you can populate just about anything from just about anything.



> Input on this is appreciated. 2. This has to have come
> up before, but I couldn't find any references. All of
> my JavaBeans map to persistent components, all of
> which have id's. I've written some actions to display
> lists of these components and the like and everything
> works great. I also started to try the Add/Edit/Save
> pattern, which occurs everywhere in the app, and I'm
> having a problem with the Save action. The issue is
> that I need to retrieve the object from the datastore
> (using the id) *before* the ActionForm is populated
> with the request parameters.
> What I'd like is to have
> the bean populated from the database, and then any
> parameters that are present on the request object set
> on the bean, then persist. I can't figure out how to
> initialize the bean to the datastore before it gets to
> me in the Action. 

Go to the Action first, populate the ActionForm and then forward to the
JSP. The form tags will see the ActionForm, and use it to populate
themselves. Then when the form is submitted, it is populated from the
request parameters "again", closing the loop.


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Struts Design question

Posted by "Edward Q. Bridges" <eb...@argotec.de>.
i believe that you could subclass ActionServlet and implement the
processPreprocess method.  this is called before processActionForm and
processPopulate.


On Fri, 7 Dec 2001 13:08:10 -0800 (PST), Jon Wall wrote:

.
.
.
>having a problem with the Save action. The issue is
>that I need to retrieve the object from the datastore
>(using the id) *before* the ActionForm is populated
>with the request parameters. What I'd like is to have

--------------------------------------------
<argo_tec gmbh>
     ed.q.bridges
     tel. 089-368179.552
     fax 089-368179.79
     osterwaldstraße 10 
     (haus F eingang 21)
     80805 münchen
</argo_tec gmbh>
--------------------------------------------  



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Struts Design question

Posted by Jon Wall <jw...@yahoo.com>.
I've been lurking on this list for a while, and I
finally have time to look hard at Struts for a web
application that I'm working on. I have a coupla
questions.. 1. This first question I found reference
to in the archives
(http://www.mail-archive.com/struts-user@jakarta.apache.org/msg18281.html)
but couldn't find an answer. In the application I'm
working on the business logic is already written and
is being added to by another team (it's supporting
other applications besides the web). So I've got a
whole slew of JavaBeans (100+) already written for me,
but now I'm facing the task of wrapping them in
ActionForm subclasses, cursing under my breath that it
isn't an interface. I understand that the purpose of
the ActionForm is as a buffer..perform validation and
all that. But my beans already contain the validation!
Besides, performing the validation in the ActionForm
is effectively tying business logic (data validation)
to the web framework dontya think? Rules such as no
invoice numbers under 1000 (Ted's example) should be
handled by the business logic, and given my situation
(probably a common one), this logic needs to be shared
between applications. I can't go into the server
system and fit ActionForm into the class heirarchy,
but I sure could have thrown an interface in there.
Input on this is appreciated. 2. This has to have come
up before, but I couldn't find any references. All of
my JavaBeans map to persistent components, all of
which have id's. I've written some actions to display
lists of these components and the like and everything
works great. I also started to try the Add/Edit/Save
pattern, which occurs everywhere in the app, and I'm
having a problem with the Save action. The issue is
that I need to retrieve the object from the datastore
(using the id) *before* the ActionForm is populated
with the request parameters. What I'd like is to have
the bean populated from the database, and then any
parameters that are present on the request object set
on the bean, then persist. I can't figure out how to
initialize the bean to the datastore before it gets to
me in the Action. If I make the ActionForm session
scoped, it works great...is this the common practice?
If so, how is cleanup performed? IE, user clicks to
Edit Widget 137, my EditWidgetAction class populates
WidgetForm and sticks it in the session, the user
never submits the form and goes to a different section
of the site. How would I get the bean out of the
session? Any help is appreciated. -jon

__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>