Re: request.setAttribute
Why you are putting it into the request yaar?? U can put it into the session.. Regards, Shyam Honza Spurný [EMAIL PROTECTED] 11/28/03 05:10 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject request.setAttribute Hi there, I have small problem with adding some objects to the request. I need to store quite huge object into request variable MyObject o = new MyObject(); o.setObjectName(name); request.setAttribute(myObejct, o); These are correct steps how to make it, aren't they? But the object MyObject is really huge. Is it possible, tak the huge objects are not store into request variable? Because when I store there object that surely exists, and then I call MyObject o2 = (MyObject)request.getAttribute(o); if (o2 == null) System.out.println(NULL); else System.out.println(o.getObjectName()); I always get NULL on output. Can be there problem with the size of such object? Thanks Sporak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: request.setAttribute
snip request.setAttribute(myObejct, o); ... MyObject o2 = (MyObject)request.getAttribute(o); /snip You arent looking up the same attribute that you stored it under. Thats why you get null! Try: MyObject o2 = (MyObject)request.getAttribute(myObejct); (btw: object is spelt object not obejct) The size of the object shouldnt be an issue in the request attributes as the request object becomes eligible for gc after the container has written the response. (otoh If you needed to store it in the session then you might have cause for concern). -Original Message- From: Honza Spurn [mailto:[EMAIL PROTECTED] Sent: Friday, 28 November 2003 19:40 To: [EMAIL PROTECTED] Subject: request.setAttribute Hi there, I have small problem with adding some objects to the request. I need to store quite huge object into request variable MyObject o = new MyObject(); o.setObjectName(name); request.setAttribute(myObejct, o); These are correct steps how to make it, aren't they? But the object MyObject is really huge. Is it possible, tak the huge objects are not store into request variable? Because when I store there object that surely exists, and then I call MyObject o2 = (MyObject)request.getAttribute(o); if (o2 == null) System.out.println(NULL); else System.out.println(o.getObjectName()); I always get NULL on output. Can be there problem with the size of such object? Thanks Sporak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: request.setAttribute
You are storing it in the request with the name myObejct but trying to retrieve it with the name o. Use: MyObject o2 = (MyObject)request.getAttribute(myObejct); Paul -Original Message- From: Honza Spurn [mailto:[EMAIL PROTECTED] Sent: 28 November 2003 11:40 To: [EMAIL PROTECTED] Subject: request.setAttribute Hi there, I have small problem with adding some objects to the request. I need to store quite huge object into request variable MyObject o = new MyObject(); o.setObjectName(name); request.setAttribute(myObejct, o); These are correct steps how to make it, aren't they? But the object MyObject is really huge. Is it possible, tak the huge objects are not store into request variable? Because when I store there object that surely exists, and then I call MyObject o2 = (MyObject)request.getAttribute(o); if (o2 == null) System.out.println(NULL); else System.out.println(o.getObjectName()); I always get NULL on output. Can be there problem with the size of such object? Thanks Sporak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ** Axios Email Confidentiality Footer Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message, and notify us immediately. If you or your employer does not consent to Internet email messages of this kind, please advise us immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by my Company or employer unless otherwise indicated by an authorised representative independent of this message. WARNING: While Axios Systems Ltd takes steps to prevent computer viruses from being transmitted via electronic mail attachments we cannot guarantee that attachments do not contain computer virus code. You are therefore strongly advised to undertake anti virus checks prior to accessing the attachment to this electronic mail. Axios Systems Ltd grants no warranties regarding performance use or quality of any attachment and undertakes no liability for loss or damage howsoever caused. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: request.setAttribute
Shyam Krishnan wrote: Why you are putting it into the request yaar?? U can put it into the session.. I don't want it in session, I need this object just for a request... Regards, Shyam Honza Spurný [EMAIL PROTECTED] 11/28/03 05:10 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject request.setAttribute Hi there, I have small problem with adding some objects to the request. I need to store quite huge object into request variable MyObject o = new MyObject(); o.setObjectName(name); request.setAttribute(myObejct, o); These are correct steps how to make it, aren't they? But the object MyObject is really huge. Is it possible, tak the huge objects are not store into request variable? Because when I store there object that surely exists, and then I call MyObject o2 = (MyObject)request.getAttribute(o); if (o2 == null) System.out.println(NULL); else System.out.println(o.getObjectName()); I always get NULL on output. Can be there problem with the size of such object? Thanks Sporak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: request.setAttribute
The correct sentence for that is: MyObject o2 = (MyObject)request.getAttribute(myObejct); Not MyObject o2 = (MyObject)request.getAttribute(o); You must get the name of the Attribute and the method returns the instance T-Systems ITC Services España, S.A. Félix López Depto. Sanidad Telf. 932 535 100 Ext. 4325 [EMAIL PROTECTED] -Mensaje original- De: Honza Spurný [mailto:[EMAIL PROTECTED] Enviado el: viernes, 28 de noviembre de 2003 12:40 Para: [EMAIL PROTECTED] Asunto: request.setAttribute Hi there, I have small problem with adding some objects to the request. I need to store quite huge object into request variable MyObject o = new MyObject(); o.setObjectName(name); request.setAttribute(myObejct, o); These are correct steps how to make it, aren't they? But the object MyObject is really huge. Is it possible, tak the huge objects are not store into request variable? Because when I store there object that surely exists, and then I call MyObject o2 = (MyObject)request.getAttribute(o); if (o2 == null) System.out.println(NULL); else System.out.println(o.getObjectName()); I always get NULL on output. Can be there problem with the size of such object? Thanks Sporak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Aquest missatge electrònic pot contenir informació confidencial o privilegiada. Si vostè no és el destinatari del missatge, o l'ha rebut per error, si us plau notifiqui-ho al remitent i destrueixi el missatge amb tot el seu contingut. Està completament prohibida qualsevol còpia, ús o distribució no autoritzada del contingut d'aquest missatge electrònic. Este mensaje electrónico puede contener información confidencial o privilegiada. Si usted no es el destinatario de este mensaje o lo ha recibido por error, por favor notifíquelo al remitente y destruya el mensaje con todo su contenido. Queda expresamente prohibida cualquier copia, utilización o distribución no autorizada del contenido de este mensaje electrónico. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: request.setAttribute
Andrew Hill wrote: snip request.setAttribute(myObejct, o); ... MyObject o2 = (MyObject)request.getAttribute(o); /snip You arent looking up the same attribute that you stored it under. Thats why you get null! Try: MyObject o2 = (MyObject)request.getAttribute(myObejct); (btw: object is spelt object not obejct) SORRY, these was my mistake, of cause I'm searching for myObject in the request variable... sorry, sorry, sorry... The size of the object shouldnt be an issue in the request attributes as the request object becomes eligible for gc after the container has written the response. (otoh If you needed to store it in the session then you might have cause for concern). -Original Message- From: Honza Spurn [mailto:[EMAIL PROTECTED] Sent: Friday, 28 November 2003 19:40 To: [EMAIL PROTECTED] Subject: request.setAttribute Hi there, I have small problem with adding some objects to the request. I need to store quite huge object into request variable MyObject o = new MyObject(); o.setObjectName(name); request.setAttribute(myObejct, o); These are correct steps how to make it, aren't they? But the object MyObject is really huge. Is it possible, tak the huge objects are not store into request variable? Because when I store there object that surely exists, and then I call MyObject o2 = (MyObject)request.getAttribute(o); if (o2 == null) System.out.println(NULL); else System.out.println(o.getObjectName()); I always get NULL on output. Can be there problem with the size of such object? Thanks Sporak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: request.setAttribute
Hi Sporak, The name which you have given your object is myObejct so when you try to retrieve this object off of the request, you need to do: MyObject o2 = (MyObject)request.getAttribute(myObejct); and not: MyObject o2 = (MyObject)request.getAttribute(o); Doing it this way (the way you have done it) would try to retrieve an object that has been given the key o but you have no object on the request with that name, so o2 will be null. This is why you're getting the NullPointer exception. Hope that helps Claire :) -Original Message- From: Honza Spurný [mailto:[EMAIL PROTECTED] Sent: 28 November 2003 11:40 To: [EMAIL PROTECTED] Subject: request.setAttribute Hi there, I have small problem with adding some objects to the request. I need to store quite huge object into request variable MyObject o = new MyObject(); o.setObjectName(name); request.setAttribute(myObejct, o); These are correct steps how to make it, aren't they? But the object MyObject is really huge. Is it possible, tak the huge objects are not store into request variable? Because when I store there object that surely exists, and then I call MyObject o2 = (MyObject)request.getAttribute(o); if (o2 == null) System.out.println(NULL); else System.out.println(o.getObjectName()); I always get NULL on output. Can be there problem with the size of such object? Thanks Sporak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: request.setAttribute
Corrected version: MyObject o = new MyObject(); o.setObjectName(name); request.setAttribute(myObejct, o); MyObject o2 = (MyObject)request.getAttribute(myObject); if (o2 == null) System.out.println(NULL); else System.out.println(o.getObjectName()); The problem still occures. I'm not able to download from request such MyObject as I have stored in. Can it be caused by the huge size of object? Sporak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: request.setAttribute
It still isn't correct. You staore it as myObejct and try and retrieve it as myObject Paul -Original Message- From: Honza Spurn [mailto:[EMAIL PROTECTED] Sent: 28 November 2003 11:51 To: Struts Users Mailing List; Honza Spurn Subject: Re: request.setAttribute Corrected version: MyObject o = new MyObject(); o.setObjectName(name); request.setAttribute(myObejct, o); MyObject o2 = (MyObject)request.getAttribute(myObject); if (o2 == null) System.out.println(NULL); else System.out.println(o.getObjectName()); The problem still occures. I'm not able to download from request such MyObject as I have stored in. Can it be caused by the huge size of object? Sporak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ** Axios Email Confidentiality Footer Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message, and notify us immediately. If you or your employer does not consent to Internet email messages of this kind, please advise us immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by my Company or employer unless otherwise indicated by an authorised representative independent of this message. WARNING: While Axios Systems Ltd takes steps to prevent computer viruses from being transmitted via electronic mail attachments we cannot guarantee that attachments do not contain computer virus code. You are therefore strongly advised to undertake anti virus checks prior to accessing the attachment to this electronic mail. Axios Systems Ltd grants no warranties regarding performance use or quality of any attachment and undertakes no liability for loss or damage howsoever caused. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: request.setAttribute
Paul McCulloch wrote: It still isn't correct. You staore it as myObejct and try and retrieve it as myObject OK OK, that is only overwrite, sorry... but this is not copied from code, this is written to make easy view of the problem... In code I have correct values, realy. so: MyObject o = new MyObject(); o.setObjectName(name); request.setAttribute(myObject, o); MyObject o2 = (MyObject)request.getAttribute(myObject); if (o2 == null) System.out.println(NULL); else System.out.println(o.getObjectName()); Paul -Original Message- From: Honza Spurn [mailto:[EMAIL PROTECTED] Sent: 28 November 2003 11:51 To: Struts Users Mailing List; Honza Spurn Subject: Re: request.setAttribute Corrected version: MyObject o = new MyObject(); o.setObjectName(name); request.setAttribute(myObejct, o); MyObject o2 = (MyObject)request.getAttribute(myObject); if (o2 == null) System.out.println(NULL); else System.out.println(o.getObjectName()); The problem still occures. I'm not able to download from request such MyObject as I have stored in. Can it be caused by the huge size of object? Sporak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ** Axios Email Confidentiality Footer Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message, and notify us immediately. If you or your employer does not consent to Internet email messages of this kind, please advise us immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by my Company or employer unless otherwise indicated by an authorised representative independent of this message. WARNING: While Axios Systems Ltd takes steps to prevent computer viruses from being transmitted via electronic mail attachments we cannot guarantee that attachments do not contain computer virus code. You are therefore strongly advised to undertake anti virus checks prior to accessing the attachment to this electronic mail. Axios Systems Ltd grants no warranties regarding performance use or quality of any attachment and undertakes no liability for loss or damage howsoever caused. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: request.setAttribute
Have something print out all of the request scope attributes and see what's
there. I've attached a bit of jsp which I use to diagnose this sort of
issue. Alternatively set a breakpoint in your code after setting the
attribute and have a look in the debugger.
bean:page id=this_request property=request /
%
java.util.Enumeration e2 =
this_request.getAttributeNames();
while (e2.hasMoreElements()) {
String element =
(String)e2.nextElement();
out.write(br + element + : +
this_request.getAttribute(element).getClass().getName());
out.write(brbr +
this_request.getAttribute(element).toString() + br);
}
%
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 11:59
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
It still isn't correct. You staore it as myObejct and try and
retrieve it
as myObject
OK OK, that is only overwrite, sorry... but this is not
copied from code,
this is written to make easy view of the problem... In code I
have correct
values, realy.
so:
MyObject o = new MyObject();
o.setObjectName(name);
request.setAttribute(myObject, o);
MyObject o2 = (MyObject)request.getAttribute(myObject);
if (o2 == null) System.out.println(NULL);
else System.out.println(o.getObjectName());
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 11:51
To: Struts Users Mailing List; Honza Spurn
Subject: Re: request.setAttribute
Corrected version:
MyObject o = new MyObject();
o.setObjectName(name);
request.setAttribute(myObejct, o);
MyObject o2 = (MyObject)request.getAttribute(myObject);
if (o2 == null) System.out.println(NULL);
else System.out.println(o.getObjectName());
The problem still occures. I'm not able to download from
request such
MyObject as I have stored in. Can it be caused by the huge
size of object?
Sporak
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
**
Axios Email Confidentiality Footer
Privileged/Confidential Information may be contained in
this message.
If you are not the addressee indicated in this message (or
responsible for delivery of the message to such person), you may not
copy or deliver this message to anyone. In such case, you should
destroy this message, and notify us immediately. If you or your
employer does not consent to Internet email messages of this kind,
please advise us immediately. Opinions, conclusions and other
information expressed in this message are not given or
endorsed by my
Company or employer unless otherwise indicated by an authorised
representative independent of this message.
WARNING:
While Axios Systems Ltd takes steps to prevent computer viruses from
being transmitted via electronic mail attachments we cannot
guarantee
that attachments do not contain computer virus code. You are
therefore strongly advised to undertake anti virus checks prior to
accessing the attachment to this electronic mail. Axios Systems Ltd
grants no warranties regarding performance use or quality of any
attachment and undertakes no liability for loss or damage howsoever
caused.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: request.setAttribute
Paul McCulloch wrote:
Have something print out all of the request scope attributes and see
what's there. I've attached a bit of jsp which I use to diagnose this
sort of issue. Alternatively set a breakpoint in your code after
setting the attribute and have a look in the debugger.
bean:page id=this_request property=request /
%
java.util.Enumeration e2 =
this_request.getAttributeNames();
while (e2.hasMoreElements()) {
String element =
(String)e2.nextElement();
out.write(br + element + : +
this_request.getAttribute(element).getClass().getName());
out.write(brbr +
this_request.getAttribute(element).toString() + br);
}
%
The MyObject is there, but always I want it download from request, I get
null object.
Why?
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 11:59
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
It still isn't correct. You staore it as myObejct and try and
retrieve it
as myObject
OK OK, that is only overwrite, sorry... but this is not
copied from code,
this is written to make easy view of the problem... In code I
have correct
values, realy.
so:
MyObject o = new MyObject();
o.setObjectName(name);
request.setAttribute(myObject, o);
MyObject o2 = (MyObject)request.getAttribute(myObject);
if (o2 == null) System.out.println(NULL);
else System.out.println(o.getObjectName());
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 11:51
To: Struts Users Mailing List; Honza Spurn
Subject: Re: request.setAttribute
Corrected version:
MyObject o = new MyObject();
o.setObjectName(name);
request.setAttribute(myObejct, o);
MyObject o2 = (MyObject)request.getAttribute(myObject);
if (o2 == null) System.out.println(NULL);
else System.out.println(o.getObjectName());
The problem still occures. I'm not able to download from
request such
MyObject as I have stored in. Can it be caused by the huge
size of object?
Sporak
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
**
Axios Email Confidentiality Footer
Privileged/Confidential Information may be contained in
this message.
If you are not the addressee indicated in this message (or
responsible for delivery of the message to such person), you may not
copy or deliver this message to anyone. In such case, you should
destroy this message, and notify us immediately. If you or your
employer does not consent to Internet email messages of this kind,
please advise us immediately. Opinions, conclusions and other
information expressed in this message are not given or
endorsed by my
Company or employer unless otherwise indicated by an authorised
representative independent of this message.
WARNING:
While Axios Systems Ltd takes steps to prevent computer viruses from
being transmitted via electronic mail attachments we cannot
guarantee
that attachments do not contain computer virus code. You are
therefore strongly advised to undertake anti virus checks prior to
accessing the attachment to this electronic mail. Axios Systems Ltd
grants no warranties regarding performance use or quality of any
attachment and undertakes no liability for loss or damage howsoever
caused.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: request.setAttribute
Please send some real code. I think you may have over simplfified what you
are showing us.
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 12:09
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
Have something print out all of the request scope attributes and see
what's there. I've attached a bit of jsp which I use to
diagnose this
sort of issue. Alternatively set a breakpoint in your code after
setting the attribute and have a look in the debugger.
bean:page id=this_request property=request /
%
java.util.Enumeration e2 =
this_request.getAttributeNames();
while (e2.hasMoreElements()) {
String element =
(String)e2.nextElement();
out.write(br + element + : +
this_request.getAttribute(element).getClass().getName());
out.write(brbr +
this_request.getAttribute(element).toString() + br);
}
%
The MyObject is there, but always I want it download from
request, I get
null object.
Why?
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 11:59
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
It still isn't correct. You staore it as myObejct and try and
retrieve it
as myObject
OK OK, that is only overwrite, sorry... but this is not
copied from code,
this is written to make easy view of the problem... In code I
have correct
values, realy.
so:
MyObject o = new MyObject();
o.setObjectName(name);
request.setAttribute(myObject, o);
MyObject o2 = (MyObject)request.getAttribute(myObject);
if (o2 == null) System.out.println(NULL);
else System.out.println(o.getObjectName());
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 11:51
To: Struts Users Mailing List; Honza Spurn
Subject: Re: request.setAttribute
Corrected version:
MyObject o = new MyObject();
o.setObjectName(name);
request.setAttribute(myObejct, o);
MyObject o2 = (MyObject)request.getAttribute(myObject);
if (o2 == null) System.out.println(NULL);
else System.out.println(o.getObjectName());
The problem still occures. I'm not able to download from
request such
MyObject as I have stored in. Can it be caused by the huge
size of object?
Sporak
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
**
Axios Email Confidentiality Footer
Privileged/Confidential Information may be contained in
this message.
If you are not the addressee indicated in this message (or
responsible for delivery of the message to such person),
you may not
copy or deliver this message to anyone. In such case, you should
destroy this message, and notify us immediately. If you or your
employer does not consent to Internet email messages of this kind,
please advise us immediately. Opinions, conclusions and other
information expressed in this message are not given or
endorsed by my
Company or employer unless otherwise indicated by an authorised
representative independent of this message.
WARNING:
While Axios Systems Ltd takes steps to prevent computer
viruses from
being transmitted via electronic mail attachments we cannot
guarantee
that attachments do not contain computer virus code. You are
therefore strongly advised to undertake anti virus checks prior to
accessing the attachment to this electronic mail. Axios
Systems Ltd
grants no warranties regarding performance use or quality of any
attachment and undertakes no liability for loss or damage
howsoever
caused.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: request.setAttribute
Paul McCulloch wrote:
Please send some real code. I think you may have over simplfified
what you are showing us.
Paul
No no, this is realy all :)
look:
public final class CreateServerAction extends Action
{
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
{
request.setAttribute(serverBean, new Server());
return(mapping.findForward(success));
}
}
in apropriate jsp page is used:
jsp:useBean id=serverBean class=cz.master.is.tech.server.Server
scope=request /
but by my opinion the problem is in the Server class, since it has about 125
attributes (each attribute has setter and getter method), so this object is
realy huge...
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 12:09
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
Have something print out all of the request scope attributes and see
what's there. I've attached a bit of jsp which I use to
diagnose this
sort of issue. Alternatively set a breakpoint in your code after
setting the attribute and have a look in the debugger.
bean:page id=this_request property=request /
%
java.util.Enumeration e2 =
this_request.getAttributeNames();
while (e2.hasMoreElements()) {
String element =
(String)e2.nextElement();
out.write(br + element + : +
this_request.getAttribute(element).getClass().getName());
out.write(brbr +
this_request.getAttribute(element).toString() + br);
}
%
The MyObject is there, but always I want it download from
request, I get
null object.
Why?
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 11:59
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
It still isn't correct. You staore it as myObejct and try and
retrieve it
as myObject
OK OK, that is only overwrite, sorry... but this is not
copied from code,
this is written to make easy view of the problem... In code I
have correct
values, realy.
so:
MyObject o = new MyObject();
o.setObjectName(name);
request.setAttribute(myObject, o);
MyObject o2 = (MyObject)request.getAttribute(myObject);
if (o2 == null) System.out.println(NULL);
else System.out.println(o.getObjectName());
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 11:51
To: Struts Users Mailing List; Honza Spurn
Subject: Re: request.setAttribute
Corrected version:
MyObject o = new MyObject();
o.setObjectName(name);
request.setAttribute(myObejct, o);
MyObject o2 = (MyObject)request.getAttribute(myObject);
if (o2 == null) System.out.println(NULL);
else System.out.println(o.getObjectName());
The problem still occures. I'm not able to download from
request such
MyObject as I have stored in. Can it be caused by the huge
size of object?
Sporak
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
**
Axios Email Confidentiality Footer
Privileged/Confidential Information may be contained in
this message.
If you are not the addressee indicated in this message (or
responsible for delivery of the message to such person),
you may not
copy or deliver this message to anyone. In such case, you should
destroy this message, and notify us immediately. If you or your
employer does not consent to Internet email messages of this kind,
please advise us immediately. Opinions, conclusions and other
information expressed in this message are not given or
endorsed by my
Company or employer unless otherwise indicated by an authorised
representative independent of this message.
WARNING:
While Axios Systems Ltd takes steps to prevent computer
viruses from
being transmitted via electronic mail attachments we cannot
guarantee that attachments do not contain computer virus code.
You are therefore strongly advised to undertake anti virus checks
prior to accessing the attachment to this electronic mail. Axios
Systems Ltd
grants no warranties regarding performance use or quality of any
attachment and undertakes no liability for loss or damage
howsoever
caused.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe
RE: request.setAttribute
The request attributes are all in a standard HashMap so I very much doubt
there is any intrinsic size limit.
What shows in your page if you paste in the fragment of jsp I put in one of
my messages?
Are you sure that you aren't doing a redirect to the jsp?
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 12:22
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
Please send some real code. I think you may have over simplfified
what you are showing us.
Paul
No no, this is realy all :)
look:
public final class CreateServerAction extends Action
{
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
{
request.setAttribute(serverBean, new Server());
return(mapping.findForward(success));
}
}
in apropriate jsp page is used:
jsp:useBean id=serverBean class=cz.master.is.tech.server.Server
scope=request /
but by my opinion the problem is in the Server class, since
it has about 125
attributes (each attribute has setter and getter method), so
this object is
realy huge...
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 12:09
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
Have something print out all of the request scope
attributes and see
what's there. I've attached a bit of jsp which I use to
diagnose this
sort of issue. Alternatively set a breakpoint in your code after
setting the attribute and have a look in the debugger.
bean:page id=this_request property=request /
%
java.util.Enumeration e2 =
this_request.getAttributeNames();
while (e2.hasMoreElements()) {
String element =
(String)e2.nextElement();
out.write(br + element + : +
this_request.getAttribute(element).getClass().getName());
out.write(brbr +
this_request.getAttribute(element).toString() + br);
}
%
The MyObject is there, but always I want it download from
request, I get
null object.
Why?
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 11:59
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
It still isn't correct. You staore it as myObejct and try and
retrieve it
as myObject
OK OK, that is only overwrite, sorry... but this is not
copied from code,
this is written to make easy view of the problem... In code I
have correct
values, realy.
so:
MyObject o = new MyObject();
o.setObjectName(name);
request.setAttribute(myObject, o);
MyObject o2 = (MyObject)request.getAttribute(myObject);
if (o2 == null) System.out.println(NULL);
else System.out.println(o.getObjectName());
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 11:51
To: Struts Users Mailing List; Honza Spurn
Subject: Re: request.setAttribute
Corrected version:
MyObject o = new MyObject();
o.setObjectName(name);
request.setAttribute(myObejct, o);
MyObject o2 = (MyObject)request.getAttribute(myObject);
if (o2 == null) System.out.println(NULL);
else System.out.println(o.getObjectName());
The problem still occures. I'm not able to download from
request such
MyObject as I have stored in. Can it be caused by the huge
size of object?
Sporak
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
**
Axios Email Confidentiality Footer
Privileged/Confidential Information may be contained in
this message.
If you are not the addressee indicated in this message (or
responsible for delivery of the message to such person),
you may not
copy or deliver this message to anyone. In such case, you should
destroy this message, and notify us immediately. If you or your
employer does not consent to Internet email messages of
this kind,
please advise us immediately. Opinions, conclusions and other
information expressed in this message are not given or
endorsed by my
Company or employer unless otherwise indicated by an authorised
representative independent of this message.
WARNING:
While Axios Systems Ltd takes steps to prevent computer
viruses from
being transmitted via electronic mail attachments we cannot
guarantee that attachments do not contain computer virus code.
You are therefore strongly advised to undertake anti
virus checks
prior to accessing the attachment to this electronic
mail. Axios
Systems Ltd
grants no warranties regarding performance use or quality of any
attachment and undertakes no liability for loss or damage
Re: request.setAttribute
Paul McCulloch wrote:
The request attributes are all in a standard HashMap so I very much
doubt there is any intrinsic size limit.
What shows in your page if you paste in the fragment of jsp I put in
one of my messages?
...
serverBean : cz.master.is.tech.server.Server
[EMAIL PROTECTED]
...
Are you sure that you aren't doing a redirect to the jsp?
I don't understand well how do you mean it...
the fragmnet of struts-config is:
action path=/server/createServer
type=cz.master.is.tech.server.CreateServerAction
input=/server/showServers.do
forward name=success path=/server/editServer.jsp /
/action
the CreateServerAction i've attached last message.
the editServer.jsp uses:
jsp:useBean id=serverBean class=cz.master.is.tech.server.Server
scope=request /
Very strange is, that when I try to do in the Action-class this:
request.setAttribute(serverBean, new Server());
Server s = (Server)request.getAttribute(serverBean);
if (s == null) System.out.println(s.getWmId());
else System.out.println(null);
NULL always appears... :(
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 12:22
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
Please send some real code. I think you may have over simplfified
what you are showing us.
Paul
No no, this is realy all :)
look:
public final class CreateServerAction extends Action
{
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
{
request.setAttribute(serverBean, new Server());
return(mapping.findForward(success));
}
}
in apropriate jsp page is used:
jsp:useBean id=serverBean class=cz.master.is.tech.server.Server
scope=request /
but by my opinion the problem is in the Server class, since
it has about 125
attributes (each attribute has setter and getter method), so
this object is
realy huge...
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 12:09
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
Have something print out all of the request scope
attributes and see
what's there. I've attached a bit of jsp which I use to
diagnose this
sort of issue. Alternatively set a breakpoint in your code after
setting the attribute and have a look in the debugger.
bean:page id=this_request property=request /
%
java.util.Enumeration e2 =
this_request.getAttributeNames();
while (e2.hasMoreElements()) {
String element =
(String)e2.nextElement();
out.write(br + element + : +
this_request.getAttribute(element).getClass().getName());
out.write(brbr +
this_request.getAttribute(element).toString() + br);
}
%
The MyObject is there, but always I want it download from
request, I get
null object.
Why?
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 11:59
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
It still isn't correct. You staore it as myObejct and try and
retrieve it
as myObject
OK OK, that is only overwrite, sorry... but this is not
copied from code,
this is written to make easy view of the problem... In code I
have correct
values, realy.
so:
MyObject o = new MyObject();
o.setObjectName(name);
request.setAttribute(myObject, o);
MyObject o2 = (MyObject)request.getAttribute(myObject);
if (o2 == null) System.out.println(NULL);
else System.out.println(o.getObjectName());
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 11:51
To: Struts Users Mailing List; Honza Spurn
Subject: Re: request.setAttribute
Corrected version:
MyObject o = new MyObject();
o.setObjectName(name);
request.setAttribute(myObejct, o);
MyObject o2 = (MyObject)request.getAttribute(myObject);
if (o2 == null) System.out.println(NULL);
else System.out.println(o.getObjectName());
The problem still occures. I'm not able to download from
request such
MyObject as I have stored in. Can it be caused by the huge
size of object?
Sporak
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
**
Axios Email Confidentiality Footer
Privileged/Confidential Information may be contained in
this message.
If you are not the addressee indicated in this message (or
responsible for delivery of the message to such person),
you may not
copy or deliver this message to anyone. In such case, you should
destroy this message, and notify us immediately. If you or your
employer does not consent to Internet email messages of
this kind,
please advise us immediately. Opinions, conclusions and other
RE: request.setAttribute
I'd concentrate on the bit of code in your action:
request.setAttribute(serverBean, new Server());
Server s = (Server)request.getAttribute(serverBean);
if (s == null) System.out.println(s.getWmId());
else System.out.println(null);
If this returns null then nothing else is going to work. Try using different
classes instead of Server - I'd start with String.
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 12:33
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
The request attributes are all in a standard HashMap so I very much
doubt there is any intrinsic size limit.
What shows in your page if you paste in the fragment of jsp I put in
one of my messages?
...
serverBean : cz.master.is.tech.server.Server
[EMAIL PROTECTED]
...
Are you sure that you aren't doing a redirect to the jsp?
I don't understand well how do you mean it...
the fragmnet of struts-config is:
action path=/server/createServer
type=cz.master.is.tech.server.CreateServerAction
input=/server/showServers.do
forward name=success path=/server/editServer.jsp /
/action
the CreateServerAction i've attached last message.
the editServer.jsp uses:
jsp:useBean id=serverBean class=cz.master.is.tech.server.Server
scope=request /
Very strange is, that when I try to do in the Action-class this:
request.setAttribute(serverBean, new Server());
Server s = (Server)request.getAttribute(serverBean);
if (s == null) System.out.println(s.getWmId());
else System.out.println(null);
NULL always appears... :(
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 12:22
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
Please send some real code. I think you may have over simplfified
what you are showing us.
Paul
No no, this is realy all :)
look:
public final class CreateServerAction extends Action
{
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request, HttpServletResponse response)
{
request.setAttribute(serverBean, new Server());
return(mapping.findForward(success));
}
}
in apropriate jsp page is used:
jsp:useBean id=serverBean
class=cz.master.is.tech.server.Server
scope=request /
but by my opinion the problem is in the Server class, since
it has about 125
attributes (each attribute has setter and getter method), so
this object is
realy huge...
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 12:09
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
Have something print out all of the request scope
attributes and see
what's there. I've attached a bit of jsp which I use to
diagnose this
sort of issue. Alternatively set a breakpoint in your code after
setting the attribute and have a look in the debugger.
bean:page id=this_request property=request /
%
java.util.Enumeration e2 =
this_request.getAttributeNames();
while (e2.hasMoreElements()) {
String element =
(String)e2.nextElement();
out.write(br + element + : +
this_request.getAttribute(element).getClass().getName());
out.write(brbr +
this_request.getAttribute(element).toString() + br);
}
%
The MyObject is there, but always I want it download from
request, I get
null object.
Why?
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 11:59
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
It still isn't correct. You staore it as myObejct
and try and
retrieve it
as myObject
OK OK, that is only overwrite, sorry... but this is not
copied from code,
this is written to make easy view of the problem... In code I
have correct
values, realy.
so:
MyObject o = new MyObject();
o.setObjectName(name);
request.setAttribute(myObject, o);
MyObject o2 = (MyObject)request.getAttribute(myObject);
if (o2 == null) System.out.println(NULL);
else System.out.println(o.getObjectName());
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 11:51
To: Struts Users Mailing List; Honza Spurn
Subject: Re: request.setAttribute
Corrected version:
MyObject o = new MyObject();
o.setObjectName(name);
request.setAttribute(myObejct, o);
MyObject o2 = (MyObject)request.getAttribute(myObject);
if (o2 == null) System.out.println(NULL);
else System.out.println(o.getObjectName());
The problem still occures. I'm not able to download from
request such
MyObject as I have stored in. Can it be caused by the huge
size
Re: request.setAttribute
Is this a typo?
if (s == null) System.out.println(s.getWmId());
else System.out.println(null);
This will print null if the object is NOT null...
- Original Message -
From: Paul McCulloch [EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
Sent: Friday, November 28, 2003 10:38 AM
Subject: RE: request.setAttribute
I'd concentrate on the bit of code in your action:
request.setAttribute(serverBean, new Server());
Server s = (Server)request.getAttribute(serverBean);
if (s == null) System.out.println(s.getWmId());
else System.out.println(null);
If this returns null then nothing else is going to work. Try using
different
classes instead of Server - I'd start with String.
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 12:33
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
The request attributes are all in a standard HashMap so I very much
doubt there is any intrinsic size limit.
What shows in your page if you paste in the fragment of jsp I put in
one of my messages?
...
serverBean : cz.master.is.tech.server.Server
[EMAIL PROTECTED]
...
Are you sure that you aren't doing a redirect to the jsp?
I don't understand well how do you mean it...
the fragmnet of struts-config is:
action path=/server/createServer
type=cz.master.is.tech.server.CreateServerAction
input=/server/showServers.do
forward name=success path=/server/editServer.jsp /
/action
the CreateServerAction i've attached last message.
the editServer.jsp uses:
jsp:useBean id=serverBean class=cz.master.is.tech.server.Server
scope=request /
Very strange is, that when I try to do in the Action-class this:
request.setAttribute(serverBean, new Server());
Server s = (Server)request.getAttribute(serverBean);
if (s == null) System.out.println(s.getWmId());
else System.out.println(null);
NULL always appears... :(
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 12:22
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
Please send some real code. I think you may have over simplfified
what you are showing us.
Paul
No no, this is realy all :)
look:
public final class CreateServerAction extends Action
{
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request, HttpServletResponse response)
{
request.setAttribute(serverBean, new Server());
return(mapping.findForward(success));
}
}
in apropriate jsp page is used:
jsp:useBean id=serverBean
class=cz.master.is.tech.server.Server
scope=request /
but by my opinion the problem is in the Server class, since
it has about 125
attributes (each attribute has setter and getter method), so
this object is
realy huge...
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 12:09
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
Have something print out all of the request scope
attributes and see
what's there. I've attached a bit of jsp which I use to
diagnose this
sort of issue. Alternatively set a breakpoint in your code after
setting the attribute and have a look in the debugger.
bean:page id=this_request property=request /
%
java.util.Enumeration e2 =
this_request.getAttributeNames();
while (e2.hasMoreElements()) {
String element =
(String)e2.nextElement();
out.write(br + element + : +
this_request.getAttribute(element).getClass().getName());
out.write(brbr +
this_request.getAttribute(element).toString() + br);
}
%
The MyObject is there, but always I want it download from
request, I get
null object.
Why?
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 11:59
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
It still isn't correct. You staore it as myObejct
and try and
retrieve it
as myObject
OK OK, that is only overwrite, sorry... but this is not
copied from code,
this is written to make easy view of the problem... In code I
have correct
values, realy.
so:
MyObject o = new MyObject();
o.setObjectName(name);
request.setAttribute(myObject, o);
MyObject o2 = (MyObject)request.getAttribute(myObject);
if (o2 == null) System.out.println(NULL);
else System.out.println(o.getObjectName());
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November
Re: request.setAttribute
Jos Ventura wrote:
Is this a typo?
if (s == null) System.out.println(s.getWmId());
else System.out.println(null);
This will print null if the object is NOT null...
THANX! I'm sorry for this flame, this was really stupid. I'm sorry. I'm
sorry.
This was the problem in Action Class.
In JSP file was problem in somethingcompletelly different.
The result is:
You can store into request also HUGE objects... :)
One's more sorry.
- Original Message -
From: Paul McCulloch [EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
Sent: Friday, November 28, 2003 10:38 AM
Subject: RE: request.setAttribute
I'd concentrate on the bit of code in your action:
request.setAttribute(serverBean, new Server());
Server s = (Server)request.getAttribute(serverBean);
if (s == null) System.out.println(s.getWmId());
else System.out.println(null);
If this returns null then nothing else is going to work. Try using
different classes instead of Server - I'd start with String.
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 12:33
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
The request attributes are all in a standard HashMap so I very much
doubt there is any intrinsic size limit.
What shows in your page if you paste in the fragment of jsp I put
in one of my messages?
...
serverBean : cz.master.is.tech.server.Server
[EMAIL PROTECTED]
...
Are you sure that you aren't doing a redirect to the jsp?
I don't understand well how do you mean it...
the fragmnet of struts-config is:
action path=/server/createServer
type=cz.master.is.tech.server.CreateServerAction
input=/server/showServers.do
forward name=success path=/server/editServer.jsp /
/action
the CreateServerAction i've attached last message.
the editServer.jsp uses:
jsp:useBean id=serverBean
class=cz.master.is.tech.server.Server scope=request /
Very strange is, that when I try to do in the Action-class this:
request.setAttribute(serverBean, new Server());
Server s = (Server)request.getAttribute(serverBean);
if (s == null) System.out.println(s.getWmId());
else System.out.println(null);
NULL always appears... :(
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 12:22
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
Please send some real code. I think you may have over simplfified
what you are showing us.
Paul
No no, this is realy all :)
look:
public final class CreateServerAction extends Action
{
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request, HttpServletResponse response)
{
request.setAttribute(serverBean, new Server());
return(mapping.findForward(success));
}
}
in apropriate jsp page is used:
jsp:useBean id=serverBean
class=cz.master.is.tech.server.Server
scope=request /
but by my opinion the problem is in the Server class, since
it has about 125
attributes (each attribute has setter and getter method), so
this object is
realy huge...
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 12:09
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
Have something print out all of the request scope
attributes and see
what's there. I've attached a bit of jsp which I use to
diagnose this
sort of issue. Alternatively set a breakpoint in your code
after setting the attribute and have a look in the debugger.
bean:page id=this_request property=request /
%
java.util.Enumeration e2 =
this_request.getAttributeNames();
while (e2.hasMoreElements()) {
String element =
(String)e2.nextElement();
out.write(br + element + : +
this_request.getAttribute(element).getClass().getName());
out.write(brbr +
this_request.getAttribute(element).toString() + br);
}
%
The MyObject is there, but always I want it download from
request, I get
null object.
Why?
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 11:59
To: Struts Users Mailing List
Subject: Re: request.setAttribute
Paul McCulloch wrote:
It still isn't correct. You staore it as myObejct
and try and
retrieve it
as myObject
OK OK, that is only overwrite, sorry... but this is not
copied from code,
this is written to make easy view of the problem... In code I
have correct
values, realy.
so:
MyObject o = new MyObject();
o.setObjectName(name);
request.setAttribute(myObject, o);
MyObject o2 = (MyObject)request.getAttribute(myObject);
if (o2 == null) System.out.println(NULL);
else System.out.println(o.getObjectName());
Paul
-Original Message-
From: Honza Spurn [mailto:[EMAIL PROTECTED]
Sent: 28 November 2003 11:51
RE: request.setAttribute
Have you read other posts You are storing and retrieving by different names. /Ashwani -Original Message- From: Honza Spurný [mailto:[EMAIL PROTECTED] Sent: Friday, November 28, 2003 5:15 PM To: Struts Users Mailing List Subject: Re: request.setAttribute Shyam Krishnan wrote: Why you are putting it into the request yaar?? U can put it into the session.. I don't want it in session, I need this object just for a request... Regards, Shyam Honza Spurný [EMAIL PROTECTED] 11/28/03 05:10 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject request.setAttribute Hi there, I have small problem with adding some objects to the request. I need to store quite huge object into request variable MyObject o = new MyObject(); o.setObjectName(name); request.setAttribute(myObejct, o); These are correct steps how to make it, aren't they? But the object MyObject is really huge. Is it possible, tak the huge objects are not store into request variable? Because when I store there object that surely exists, and then I call MyObject o2 = (MyObject)request.getAttribute(o); if (o2 == null) System.out.println(NULL); else System.out.println(o.getObjectName()); I always get NULL on output. Can be there problem with the size of such object? Thanks Sporak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Cap Gemini Ernst Young Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorised to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SIDEBAR] Form population (Was RE: request.setAttribute() for mconfusion)
Martin Cooper wrote: -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 2:46 PM To: Struts Users Mailing List Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) Sri, pardon me, but I don't see how what you've said has anything to do with the point I was making. My sole point is that the actual creation (instantiation) of the form bean itself is a very mechanical act that Struts can perform on your behalf. There is no need to ever bother with creating a bean and placing it into some scope - just configure things properly and let it be done for you. Yes, you may very well need to initialize it's values in an action - but that is a seperate act from instantiation. I think you missed the point here, Eddie (or perhaps I missed that you didn't miss the point :). Think about it this way. Struts will create your form bean automagically in a couple of cases: when it needs to populate one from an incoming request, and when it needs to render a form but can't find the corresponding form bean. Now consider the case where you need to populate the form with some values that the Action came up with somehow. You'd do that by having the values in the form bean properties, right? That way, the Struts HTML tags will do the work for you. But now consider the case where you haven't yet invoked anything in the app that would cause the appropriate form bean to be instantiated. The action that came up with the values might have been invoked with a different form bean, or perhaps no form bean at all. So Struts hasn't instantiated the bean yet. Struts *will* instantiate the bean when it the html:form tag is processed, but by then, it's too late for the Action to populate the form bean. Yes, but at this point it's not terribly important - assuming the submit of this form is the first time the form is really needed (for capturing values). I was just trying to empasize why a person wanted to trust Struts to do this for them - not cover all bases of usage ;-) So the only way for the action to pre-populate the form bean, so that those values are picked up by the Struts HTML tags to populate the form is for the action to instantiate the form bean itself. Huh? Ok I think I missed something here. I've always had my form available to me if I told Struts an action used it. If you're not pre-populating (for display) it's really not important to have it created ahead of time. You're guaranteed the form will be there to capture any submit as we process the associated form (read: we check for an existing form and instantiate one if it does not exist) before we populate. One of us is confused. My bet is that you misinterpreted what I was getting at. Again, my sole point was that Struts will create forms for a person if they simply connect the dots between the form and the action so that Struts is aware that it needs to be done. One way of creating the form bean is RequestUtils.createActionForm(). -- Martin Cooper -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: [SIDEBAR] Form population (Was RE: request.setAttribute() for mconfusion)
Struts can't divine it! HEH - it's good, but it's not that good. You have to tell it. If I said something that got misunderstood as what you're saying I apologize. You are exactly correct - the business logic is the only thing that can make the determination. Sri Sankaran wrote: Yes! Finally someone who sees what I am talking about! *That's* exactly the scenario I am talking about. I can't see how Struts can divine what values the form-bean property needs to be initialized. It is predicated by the preceding business logic. Sri -Original Message- From: Martin Cooper [mailto:martin.cooper;tumbleweed.com] Sent: Monday, November 11, 2002 9:40 PM To: 'Struts Users Mailing List' Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) I think you missed the point here, Eddie (or perhaps I missed that you didn't miss the point :). Think about it this way. Struts will create your form bean automagically in a couple of cases: when it needs to populate one from an incoming request, and when it needs to render a form but can't find the corresponding form bean. Now consider the case where you need to populate the form with some values that the Action came up with somehow. You'd do that by having the values in the form bean properties, right? That way, the Struts HTML tags will do the work for you. But now consider the case where you haven't yet invoked anything in the app that would cause the appropriate form bean to be instantiated. The action that came up with the values might have been invoked with a different form bean, or perhaps no form bean at all. So Struts hasn't instantiated the bean yet. Struts *will* instantiate the bean when it the html:form tag is processed, but by then, it's too late for the Action to populate the form bean. So the only way for the action to pre-populate the form bean, so that those values are picked up by the Struts HTML tags to populate the form is for the action to instantiate the form bean itself. One way of creating the form bean is RequestUtils.createActionForm(). -- Martin Cooper Why bother specifying a form-bean in your config file if you're going to create it yourself? Yeah there's some validation that can be done on it by Struts - but if you don't specify a form-bean for an action-mapping (you specify nothing for the action-mapping's name attribute) I don't believe that validation is done (why would it be? Struts doesn't know there's a form being used for this action!). Hrm - in fact you lose a great deal of the utility Struts provides if you don't make this association. Think about it: You have to tell Struts what type your form is of - so it can instantiate it. It needs this information for no other purpose. It could easily tell later on that the form is of the wrong type for validation etc. Also, you could specify by the attribute property the name of a form which you instantiated yourself. You *could* (if you wanted to) cut yourself off from the Struts form mechanism altogether. What I suggest in no way impacts your ability to use good design (delegates etc). It just takes one very mechanical thing out of your hands - and out of your concern - and just does it. It's solid. It works. If it ever fails you *please* file a bug! It also has no impact on where data comes from or where it goes to. You can pass data via a form from one action to another in about 2 ways that come to mind immediately: 1) session-scoped form 2) using hidden fields. I'm sorry, but I think you misunderstood my entire argument. My appologies for not having been clearer. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion)
No sweat. The reason this discussion got so off whack was because I tried to slam a square peg in a round hole by continuing with Kris' example (Edit Save actions) to make my point -- bad idea. So what *is* my scenario? Consider for example, a master-detail pair of pages. The master page display a list of employee names. The detail page -- which is displayed when a user selects an employee from the master page -- displays a collection of (possibly editable) fields that describe the selected employee. The form-bean associated with the detail page is your typical EmployeeBean object. Even if the struts-config is set up with the right action mapping like action path=/detail type=com.acme.DetailAction name=employeeBean/ how can Struts know that the user selected the user 'John Smith' on the master page? Ergo, the need to create the necessary form bean in the action for the master page. We cannot wait for/depend on Struts to create it. I don't like the fact that the MasterAction needs to have knowledge of the requirements for the detail page (the type of bean, the name under which it is accessed) -- or maybe that isn't so bad?? Are you telling me that I missed something fundamental to Struts?...'tis quite likely. Sri -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Tuesday, November 12, 2002 11:34 AM To: Struts Users Mailing List Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) Struts can't divine it! HEH - it's good, but it's not that good. You have to tell it. If I said something that got misunderstood as what you're saying I apologize. You are exactly correct - the business logic is the only thing that can make the determination. Sri Sankaran wrote: Yes! Finally someone who sees what I am talking about! *That's* exactly the scenario I am talking about. I can't see how Struts can divine what values the form-bean property needs to be initialized. It is predicated by the preceding business logic. Sri -Original Message- From: Martin Cooper [mailto:martin.cooper;tumbleweed.com] Sent: Monday, November 11, 2002 9:40 PM To: 'Struts Users Mailing List' Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) I think you missed the point here, Eddie (or perhaps I missed that you didn't miss the point :). Think about it this way. Struts will create your form bean automagically in a couple of cases: when it needs to populate one from an incoming request, and when it needs to render a form but can't find the corresponding form bean. Now consider the case where you need to populate the form with some values that the Action came up with somehow. You'd do that by having the values in the form bean properties, right? That way, the Struts HTML tags will do the work for you. But now consider the case where you haven't yet invoked anything in the app that would cause the appropriate form bean to be instantiated. The action that came up with the values might have been invoked with a different form bean, or perhaps no form bean at all. So Struts hasn't instantiated the bean yet. Struts *will* instantiate the bean when it the html:form tag is processed, but by then, it's too late for the Action to populate the form bean. So the only way for the action to pre-populate the form bean, so that those values are picked up by the Struts HTML tags to populate the form is for the action to instantiate the form bean itself. One way of creating the form bean is RequestUtils.createActionForm(). -- Martin Cooper Why bother specifying a form-bean in your config file if you're going to create it yourself? Yeah there's some validation that can be done on it by Struts - but if you don't specify a form-bean for an action-mapping (you specify nothing for the action-mapping's name attribute) I don't believe that validation is done (why would it be? Struts doesn't know there's a form being used for this action!). Hrm - in fact you lose a great deal of the utility Struts provides if you don't make this association. Think about it: You have to tell Struts what type your form is of - so it can instantiate it. It needs this information for no other purpose. It could easily tell later on that the form is of the wrong type for validation etc. Also, you could specify by the attribute property the name of a form which you instantiated yourself. You *could* (if you wanted to) cut yourself off from the Struts form mechanism altogether. What I suggest in no way impacts your ability to use good design (delegates etc). It just takes one very mechanical thing out of your hands - and out of your concern - and just does it. It's solid. It works. If it ever fails you *please* file a bug! It also has no impact on where data comes from or where it goes to. You can pass data via a form from one action to another in about 2 ways
RE: [SIDEBAR] Form population (Was RE: request.setAttribute()for m confusion)
-Original Message- From: Sri Sankaran [mailto:Sri.Sankaran;sas.com] Sent: Tuesday, November 12, 2002 7:56 AM To: Struts Users Mailing List Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) No sweat. The reason this discussion got so off whack was because I tried to slam a square peg in a round hole by continuing with Kris' example (Edit Save actions) to make my point -- bad idea. So what *is* my scenario? Consider for example, a master-detail pair of pages. The master page display a list of employee names. The detail page -- which is displayed when a user selects an employee from the master page -- displays a collection of (possibly editable) fields that describe the selected employee. The form-bean associated with the detail page is your typical EmployeeBean object. Even if the struts-config is set up with the right action mapping like action path=/detail type=com.acme.DetailAction name=employeeBean/ how can Struts know that the user selected the user 'John Smith' on the master page? Ergo, the need to create the necessary form bean in the action for the master page. We cannot wait for/depend on Struts to create it. I don't like the fact that the MasterAction needs to have knowledge of the requirements for the detail page (the type of bean, the name under which it is accessed) -- or maybe that isn't so bad?? Yes, it is bad. Actually, it's a bit of a mystery to me that this issue doesn't come up more often (or perhaps I just always miss it). One solution (which Craig would probably shoot me for mentioning :) is action chaining. That is, your master action chains (i.e. forwards) to a detail action that prepares the bean for the detail page. There are some problems with chaining actions, though, so it's not the best way to handle this. An alternative is to split your actions into two phases, and keep the logic of those two phases separate, using additional classes. This is what I'm doing now, and it's pretty clean. Unfortunately, at this point my employer owns the code, but I'll see if I can wrest it free at some point. ;-) -- Martin Cooper Are you telling me that I missed something fundamental to Struts?...'tis quite likely. Sri -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Tuesday, November 12, 2002 11:34 AM To: Struts Users Mailing List Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) Struts can't divine it! HEH - it's good, but it's not that good. You have to tell it. If I said something that got misunderstood as what you're saying I apologize. You are exactly correct - the business logic is the only thing that can make the determination. Sri Sankaran wrote: Yes! Finally someone who sees what I am talking about! *That's* exactly the scenario I am talking about. I can't see how Struts can divine what values the form-bean property needs to be initialized. It is predicated by the preceding business logic. Sri -Original Message- From: Martin Cooper [mailto:martin.cooper;tumbleweed.com] Sent: Monday, November 11, 2002 9:40 PM To: 'Struts Users Mailing List' Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) I think you missed the point here, Eddie (or perhaps I missed that you didn't miss the point :). Think about it this way. Struts will create your form bean automagically in a couple of cases: when it needs to populate one from an incoming request, and when it needs to render a form but can't find the corresponding form bean. Now consider the case where you need to populate the form with some values that the Action came up with somehow. You'd do that by having the values in the form bean properties, right? That way, the Struts HTML tags will do the work for you. But now consider the case where you haven't yet invoked anything in the app that would cause the appropriate form bean to be instantiated. The action that came up with the values might have been invoked with a different form bean, or perhaps no form bean at all. So Struts hasn't instantiated the bean yet. Struts *will* instantiate the bean when it the html:form tag is processed, but by then, it's too late for the Action to populate the form bean. So the only way for the action to pre-populate the form bean, so that those values are picked up by the Struts HTML tags to populate the form is for the action to instantiate the form bean itself. One way of creating the form bean is RequestUtils.createActionForm(). -- Martin Cooper Why bother specifying a form-bean in your config file if you're going to create it yourself? Yeah there's some validation that can be done on it by Struts - but if you don't specify a form-bean for an action-mapping
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion)
One possible solution is to use one form bean and in your action, if you see the form isn't populated, forward to the jsp action which either populates it or gives you enough information to populate it other ways. Edgar -Original Message- From: Sri Sankaran [mailto:Sri.Sankaran;sas.com] Sent: Tuesday, November 12, 2002 10:56 AM To: 'Struts Users Mailing List' Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) No sweat. The reason this discussion got so off whack was because I tried to slam a square peg in a round hole by continuing with Kris' example (Edit Save actions) to make my point -- bad idea. So what *is* my scenario? Consider for example, a master-detail pair of pages. The master page display a list of employee names. The detail page -- which is displayed when a user selects an employee from the master page -- displays a collection of (possibly editable) fields that describe the selected employee. The form-bean associated with the detail page is your typical EmployeeBean object. Even if the struts-config is set up with the right action mapping like action path=/detail type=com.acme.DetailAction name=employeeBean/ how can Struts know that the user selected the user 'John Smith' on the master page? Ergo, the need to create the necessary form bean in the action for the master page. We cannot wait for/depend on Struts to create it. I don't like the fact that the MasterAction needs to have knowledge of the requirements for the detail page (the type of bean, the name under which it is accessed) -- or maybe that isn't so bad?? Are you telling me that I missed something fundamental to Struts?...'tis quite likely. Sri -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Tuesday, November 12, 2002 11:34 AM To: Struts Users Mailing List Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) Struts can't divine it! HEH - it's good, but it's not that good. You have to tell it. If I said something that got misunderstood as what you're saying I apologize. You are exactly correct - the business logic is the only thing that can make the determination. Sri Sankaran wrote: Yes! Finally someone who sees what I am talking about! *That's* exactly the scenario I am talking about. I can't see how Struts can divine what values the form-bean property needs to be initialized. It is predicated by the preceding business logic. Sri -Original Message- From: Martin Cooper [mailto:martin.cooper;tumbleweed.com] Sent: Monday, November 11, 2002 9:40 PM To: 'Struts Users Mailing List' Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) I think you missed the point here, Eddie (or perhaps I missed that you didn't miss the point :). Think about it this way. Struts will create your form bean automagically in a couple of cases: when it needs to populate one from an incoming request, and when it needs to render a form but can't find the corresponding form bean. Now consider the case where you need to populate the form with some values that the Action came up with somehow. You'd do that by having the values in the form bean properties, right? That way, the Struts HTML tags will do the work for you. But now consider the case where you haven't yet invoked anything in the app that would cause the appropriate form bean to be instantiated. The action that came up with the values might have been invoked with a different form bean, or perhaps no form bean at all. So Struts hasn't instantiated the bean yet. Struts *will* instantiate the bean when it the html:form tag is processed, but by then, it's too late for the Action to populate the form bean. So the only way for the action to pre-populate the form bean, so that those values are picked up by the Struts HTML tags to populate the form is for the action to instantiate the form bean itself. One way of creating the form bean is RequestUtils.createActionForm(). -- Martin Cooper Why bother specifying a form-bean in your config file if you're going to create it yourself? Yeah there's some validation that can be done on it by Struts - but if you don't specify a form-bean for an action-mapping (you specify nothing for the action-mapping's name attribute) I don't believe that validation is done (why would it be? Struts doesn't know there's a form being used for this action!). Hrm - in fact you lose a great deal of the utility Struts provides if you don't make this association. Think about it: You have to tell Struts what type your form is of - so it can instantiate it. It needs this information for no other purpose. It could easily tell later on that the form is of the wrong type for validation etc. Also, you could specify by the attribute property the name of a form which you instantiated yourself. You *could* (if you wanted to) cut yourself off
Re: [SIDEBAR] Form population (Was RE: request.setAttribute() for mconfusion)
Martin Cooper wrote: Huh? What's not terribly important? If I don't have the form bean (which Struts has not yet created for me), how am I going to populate it with the values I want displayed in the form? It's irrelevant whether or not the form is created if you haven't drawn the association between the action and the form so that Struts knows you wish to have it populated, right? Huh? Ok I think I missed something here. I've always had my form available to me if I told Struts an action used it. If you're not pre-populating (for display) it's really not important to have it created ahead of time. You're guaranteed the form will be there to Um, this whole thread is about pre-populating for display... That's what Sri is trying to do. In his scenario, there is *no way* to have Struts create the form bean for him automagically. ... I think the thing that prompted us here was discussing how Struts would create a form if you drew the lines to tell it to ... and that drawing those lines enables other behavior - population being one of them. -- Martin Cooper -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: [SIDEBAR] Form population (Was RE: request.setAttribute() for mconfusion)
Sri Sankaran wrote: No sweat. The reason this discussion got so off whack was because I tried to slam a square peg in a round hole by continuing with Kris' example (Edit Save actions) to make my point -- bad idea. So what *is* my scenario? Consider for example, a master-detail pair of pages. The master page display a list of employee names. The detail page -- which is displayed when a user selects an employee from the master page -- displays a collection of (possibly editable) fields that describe the selected employee. The form-bean associated with the detail page is your typical EmployeeBean object. Even if the struts-config is set up with the right action mapping like action path=/detail type=com.acme.DetailAction name=employeeBean/ how can Struts know that the user selected the user 'John Smith' on the master page? Ergo, the need to create the necessary form bean in the action for the master page. We cannot wait for/depend on Struts to create it. John Smith has some unique identifying value, right? You're going to need to grab this value on submit and send it to your detail action so that it knows which one to load. Yes, yes, you could just create the form at that point and be done with it - but that is probably better left to your detail-loading-action - the one that populates the detail form and fowards to your JSP. I don't like the fact that the MasterAction needs to have knowledge of the requirements for the detail page (the type of bean, the name under which it is accessed) -- or maybe that isn't so bad?? It needs to know which field the detail will use to lookup the record so that it can send it the value of that field. Is that so bad? You can't expect it to just know. There has to be something to tell it what you want to do. They're obviously related - they're in a master-detail relationship - so why would such minimal coupling be bad? You've got to have something to indicate what you want to do. Right? Are you telling me that I missed something fundamental to Struts?...'tis quite likely. Sri -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion)
See intermixed. On Tue, 12 Nov 2002, Martin Cooper wrote: Date: Tue, 12 Nov 2002 08:36:13 -0800 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) -Original Message- From: Sri Sankaran [mailto:Sri.Sankaran;sas.com] Sent: Tuesday, November 12, 2002 7:56 AM To: Struts Users Mailing List Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) No sweat. The reason this discussion got so off whack was because I tried to slam a square peg in a round hole by continuing with Kris' example (Edit Save actions) to make my point -- bad idea. So what *is* my scenario? Consider for example, a master-detail pair of pages. The master page display a list of employee names. The detail page -- which is displayed when a user selects an employee from the master page -- displays a collection of (possibly editable) fields that describe the selected employee. The form-bean associated with the detail page is your typical EmployeeBean object. Even if the struts-config is set up with the right action mapping like action path=/detail type=com.acme.DetailAction name=employeeBean/ how can Struts know that the user selected the user 'John Smith' on the master page? Ergo, the need to create the necessary form bean in the action for the master page. We cannot wait for/depend on Struts to create it. I don't like the fact that the MasterAction needs to have knowledge of the requirements for the detail page (the type of bean, the name under which it is accessed) -- or maybe that isn't so bad?? Yes, it is bad. Actually, it's a bit of a mystery to me that this issue doesn't come up more often (or perhaps I just always miss it). One solution (which Craig would probably shoot me for mentioning :) Yep :-). For those who tuned in late, I am *not* a fan of this -- in part because it has some pretty unexpected semantics w.r.t. form beans. is action chaining. That is, your master action chains (i.e. forwards) to a detail action that prepares the bean for the detail page. There are some problems with chaining actions, though, so it's not the best way to handle this. An alternative is to split your actions into two phases, and keep the logic of those two phases separate, using additional classes. This is what I'm doing now, and it's pretty clean. Unfortunately, at this point my employer owns the code, but I'll see if I can wrest it free at some point. ;-) If you know what your destination action's path is, you actually *can* divine what form bean is needed pretty easily. Let's assume we're talking about the ultimate action at path /foo: ApplicationConfig appConfig = (ApplicationConfig) request.getAttribute(Globals.APPLICATION_KEY); ActionConfig actionConfig = appConfig.findActionConfig(/foo); String name = actionConfig.getName(); // Form bean name String attribute = actionConfig.getAttribute(); // Attribute to store under String scope = actionConfig.getScope(); // Scope to store in FormBeanConfig fbConfig = appConfig.findFormBeanConfig(name); Now you've got all the metadata you need to dynamically instantiate the appropriate form bean, and store it under the appropriate attribute in the appropriate scope, without hard coding any of this stuff. -- Martin Cooper Craig -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion)
Intermixed response... -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Tuesday, November 12, 2002 2:34 PM To: Struts Users Mailing List Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) Sri Sankaran wrote: No sweat. The reason this discussion got so off whack was because I tried to slam a square peg in a round hole by continuing with Kris' example (Edit Save actions) to make my point -- bad idea. So what *is* my scenario? Consider for example, a master-detail pair of pages. The master page display a list of employee names. The detail page -- which is displayed when a user selects an employee from the master page -- displays a collection of (possibly editable) fields that describe the selected employee. The form-bean associated with the detail page is your typical EmployeeBean object. Even if the struts-config is set up with the right action mapping like action path=/detail type=com.acme.DetailAction name=employeeBean/ how can Struts know that the user selected the user 'John Smith' on the master page? Ergo, the need to create the necessary form bean in the action for the master page. We cannot wait for/depend on Struts to create it. John Smith has some unique identifying value, right? You're going to need to grab this value on submit and send it to your detail action so that it knows which one to load. But when the master page is submitted, it is *MasterAction* that is being invoked and not DetailAction. DetailAction doesn't come into the picture until the detail page is submitted. Yes, yes, you could just create the form at that point and be done with it - but that is probably better left to your detail-loading-action - the one that populates the detail form and fowards to your JSP. I don't like the fact that the MasterAction needs to have knowledge of the requirements for the detail page (the type of bean, the name under which it is accessed) -- or maybe that isn't so bad?? It needs to know which field the detail will use to lookup the record so that it can send it the value of that field. Is that so bad? You can't expect it to just know. There has to be something to tell it what you want to do. They're obviously related - they're in a master-detail relationship - so why would such minimal coupling be bad? You've got to have something to indicate what you want to do. Right? Are you telling me that I missed something fundamental to Struts?...'tis quite likely. Sri -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion)
Intermixed response... -Original Message- From: Craig R. McClanahan [mailto:craigmcc;apache.org] Sent: Tuesday, November 12, 2002 1:54 PM To: Struts Users Mailing List Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) See intermixed. On Tue, 12 Nov 2002, Martin Cooper wrote: Date: Tue, 12 Nov 2002 08:36:13 -0800 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) -Original Message- From: Sri Sankaran [mailto:Sri.Sankaran;sas.com] Sent: Tuesday, November 12, 2002 7:56 AM To: Struts Users Mailing List Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) No sweat. The reason this discussion got so off whack was because I tried to slam a square peg in a round hole by continuing with Kris' example (Edit Save actions) to make my point -- bad idea. So what *is* my scenario? Consider for example, a master-detail pair of pages. The master page display a list of employee names. The detail page -- which is displayed when a user selects an employee from the master page -- displays a collection of (possibly editable) fields that describe the selected employee. The form-bean associated with the detail page is your typical EmployeeBean object. Even if the struts-config is set up with the right action mapping like action path=/detail type=com.acme.DetailAction name=employeeBean/ how can Struts know that the user selected the user 'John Smith' on the master page? Ergo, the need to create the necessary form bean in the action for the master page. We cannot wait for/depend on Struts to create it. I don't like the fact that the MasterAction needs to have knowledge of the requirements for the detail page (the type of bean, the name under which it is accessed) -- or maybe that isn't so bad?? Yes, it is bad. Actually, it's a bit of a mystery to me that this issue doesn't come up more often (or perhaps I just always miss it). One solution (which Craig would probably shoot me for mentioning :) Yep :-). For those who tuned in late, I am *not* a fan of this -- in part because it has some pretty unexpected semantics w.r.t. form beans. is action chaining. That is, your master action chains (i.e. forwards) to a detail action that prepares the bean for the detail page. There are some problems with chaining actions, though, so it's not the best way to handle this. An alternative is to split your actions into two phases, and keep the logic of those two phases separate, using additional classes. This is what I'm doing now, and it's pretty clean. Unfortunately, at this point my employer owns the code, but I'll see if I can wrest it free at some point. ;-) If you know what your destination action's path is, you actually *can* divine what form bean is needed pretty easily. Let's assume we're talking about the ultimate action at path /foo: ApplicationConfig appConfig = (ApplicationConfig) request.getAttribute(Globals.APPLICATION_KEY); ActionConfig actionConfig = appConfig.findActionConfig(/foo); String name = actionConfig.getName(); // Form bean name String attribute = actionConfig.getAttribute(); // Attribute to store under String scope = actionConfig.getScope(); // Scope to store in FormBeanConfig fbConfig = appConfig.findFormBeanConfig(name); Now you've got all the metadata you need to dynamically instantiate the appropriate form bean, and store it under the appropriate attribute in the appropriate scope, without hard coding any of this stuff. This goes from having to have information about the bean to having information about the action path. Six one way, half dozen the other? -- Martin Cooper Craig Sri -- To unsubscribe, e-mail: mailto:struts-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: [SIDEBAR] Form population (Was RE: request.setAttribute() for mconfusion)
(waaay down there ...) Sri Sankaran wrote: Intermixed response... -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) Sri Sankaran wrote: No sweat. The reason this discussion got so off whack was because I tried to slam a square peg in a round hole by continuing with Kris' example (Edit Save actions) to make my point -- bad idea. So what *is* my scenario? Consider for example, a master-detail pair of pages. The master page display a list of employee names. The detail page -- which is displayed when a user selects an employee from the master page -- displays a collection of (possibly editable) fields that describe the selected employee. The form-bean associated with the detail page is your typical EmployeeBean object. Even if the struts-config is set up with the right action mapping like action path=/detail type=com.acme.DetailAction name=employeeBean/ how can Struts know that the user selected the user 'John Smith' on the master page? Ergo, the need to create the necessary form bean in the action for the master page. We cannot wait for/depend on Struts to create it. John Smith has some unique identifying value, right? You're going to need to grab this value on submit and send it to your detail action so that it knows which one to load. But when the master page is submitted, it is *MasterAction* that is being invoked and not DetailAction. DetailAction doesn't come into the picture until the detail page is submitted. Yes, it is. That is why you retrieve whichever pertient value it is the detail will need and then send control to the detail action - and let it load the data relevant for the view and forward to it. If you're asking for a detail view for one row in the master, then you obviously have some unique value (or group of values - a key) by which you determine the relationship. This is the information you must somehow make available to the detail view - as request parameters or in some other way. Personally, I tend toward using OIDs, so ... since you're probably going to have the OID of the master as a field of the detail you can send that OID to the detail as some parameter - call it recordId or whatever you like. The information you use to load the detail doesn't differ with respect to where you retrieve it. That data will be just as happy it was retrieved from the master action as it will be if it is retrieved from the detail action. By placing the responsibility for that behavior upon the detail action you rid the master of caring about it - and you remove the need for your master to create the form for the detail. LoadAction - Form (JSP) - SubmitAction action loads data into form and forwards to view view is sent to action to determine next step ... you've got two of these back-to-back: MstrLdActn - MstrJsp - MstrSbmtActn - - DtlLdActn - DtlJsp - DtlSbmtActn a redirect passing mastid=54 ^ snip/ -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute()for m confusion)
Comments in here somewhere... -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Tuesday, November 12, 2002 12:22 PM To: Struts Users Mailing List Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) (waaay down there ...) Sri Sankaran wrote: Intermixed response... -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) Sri Sankaran wrote: No sweat. The reason this discussion got so off whack was because I tried to slam a square peg in a round hole by continuing with Kris' example (Edit Save actions) to make my point -- bad idea. So what *is* my scenario? Consider for example, a master-detail pair of pages. The master page display a list of employee names. The detail page -- which is displayed when a user selects an employee from the master page -- displays a collection of (possibly editable) fields that describe the selected employee. The form-bean associated with the detail page is your typical EmployeeBean object. Even if the struts-config is set up with the right action mapping like action path=/detail type=com.acme.DetailAction name=employeeBean/ how can Struts know that the user selected the user 'John Smith' on the master page? Ergo, the need to create the necessary form bean in the action for the master page. We cannot wait for/depend on Struts to create it. John Smith has some unique identifying value, right? You're going to need to grab this value on submit and send it to your detail action so that it knows which one to load. But when the master page is submitted, it is *MasterAction* that is being invoked and not DetailAction. DetailAction doesn't come into the picture until the detail page is submitted. Yes, it is. That is why you retrieve whichever pertient value it is the detail will need and then send control to the detail action - and let it load the data relevant for the view and forward to it. If you're asking for a detail view for one row in the master, then you obviously have some unique value (or group of values - a key) by which you determine the relationship. This is the information you must somehow make available to the detail view - as request parameters or in some other way. Personally, I tend toward using OIDs, so ... since you're probably going to have the OID of the master as a field of the detail you can send that OID to the detail as some parameter - call it recordId or whatever you like. Ahhh! The murky waters finally clear, and I understand where all the confusion is coming from. Sri and I are talking about one Action handling the request. You (Eddie) are talking about two Actions chained together. Better not let Craig catch you, Eddie! ;-) -- Martin Cooper The information you use to load the detail doesn't differ with respect to where you retrieve it. That data will be just as happy it was retrieved from the master action as it will be if it is retrieved from the detail action. By placing the responsibility for that behavior upon the detail action you rid the master of caring about it - and you remove the need for your master to create the form for the detail. LoadAction - Form (JSP) - SubmitAction action loads data into form and forwards to view view is sent to action to determine next step ... you've got two of these back-to-back: MstrLdActn - MstrJsp - MstrSbmtActn - - DtlLdActn - DtlJsp - DtlSbmtActn a redirect passing mastid=54 ^ snip/ -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: [SIDEBAR] Form population (Was RE: request.setAttribute() for mconfusion)
Martin Cooper wrote: Ahhh! The murky waters finally clear, and I understand where all the confusion is coming from. Sri and I are talking about one Action handling the request. Yes - but I've said before that if you had multiple forms involved you would have to make yourself responsible for the extras ;-) You (Eddie) are talking about two Actions chained together. Better not let Craig catch you, Eddie! ;-) -- Martin Cooper I always viewed chaining as actually fowarding from one action to another. Notice that I choose to redirect there. How could this possibly have any bad effects? It's a new request - fresh - and it will be populated by the detail form-bean etc and you'll grab the request parameter ... and load your data for display. I can certainly see where forwarding around could have adverse side-effects, but by redirecting? ... hrm - well it seves me well. runs-and-hides-from-craig/ :-) -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion)
mega-snip/ ... you've got two of these back-to-back: MstrLdActn - MstrJsp - MstrSbmtActn - - DtlLdActn - DtlJsp - DtlSbmtActn a redirect passing mastid=54 ^ Ah! Action chaining -- I realize that is an option. Just don't let Craig see you doing this... ;) snip/ -- Eddie Bush Sri -- To unsubscribe, e-mail: mailto:struts-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: request.setAttribute() form confusion
Nevermind, answering my own question ...
actions in the Struts examples don't use the second line of code, so the
answer is no, you don't need the two together.
Susan
On 11/11/2002 01:34:16 PM Susan Bradeen wrote:
If I have this code, which appears to be good practice, in the beginning
of my pre-action's execute() method:
if (form == null) {
form = new SomeForm();
if (request.equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), form);
}
else {
request.getSession().setAttribute(mapping.getAttribute(), form);
}
}
SomeForm myForm = (SomeForm)form;
/* populate form values ... */
Do I also need to use the following line at the end (after form
population), or is this basically accomplishing the same as the above?
request.setAttribute(mapping.getAttribute(), myForm);
Thanks,
Susan Bradeen
--
To unsubscribe, e-mail:
mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-user-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: request.setAttribute() form confusion
You shouldn't ever have to create the form yourself if you: - declare the form-bean in your config file - use the name of the form you declared in the action mapping's name attribute form-bean name=myForm ... / ... action path=/somePath name=myForm ... / That should suffice. What you should find is that the form is created for you. Doing things as I mention simplifies you actions so that they can just expect the form to be there. If the form is not there you will probably NPE. That would indicate that you didn't create the association (by setting name=myForm) or Struts wasn't able to create the form for some odd reason. Susan Bradeen wrote: Nevermind, answering my own question ... actions in the Struts examples don't use the second line of code, so the answer is no, you don't need the two together. Susan -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: request.setAttribute() form confusion
Susan,
Here's a response to a different thread with the same type of code block:
http://marc.theaimsgroup.com/?l=struts-userm=103669042429912w=2
I understand this type of approach is used in the example app, but I'd say it's
anything but good practice. In general, if you have an action that's going to
pre-populate a form, it's action mapping should include a name (or attribute)
attribute for the appropriate form. Struts will take care of finding or
creating the form, ensuring that it's stored in the proper scope, and passing
it to the execute/perform method. All you need to do then is cast it to the
appropriate type.
Quoting Susan Bradeen [EMAIL PROTECTED]:
If I have this code, which appears to be good practice, in the beginning
of my pre-action's execute() method:
if (form == null) {
form = new SomeForm();
if (request.equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), form);
}
else {
request.getSession().setAttribute(mapping.getAttribute(), form);
}
}
SomeForm myForm = (SomeForm)form;
/* populate form values ... */
Do I also need to use the following line at the end (after form
population), or is this basically accomplishing the same as the above?
request.setAttribute(mapping.getAttribute(), myForm);
Thanks,
Susan Bradeen
--
To unsubscribe, e-mail:
mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-user-help;jakarta.apache.org
--
Kris Schneider mailto:kris;dotech.com
D.O.Tech http://www.dotech.com/
--
To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
[SIDEBAR] Form population (Was RE: request.setAttribute() form confusion)
While that is true, other than in the case of blank forms, isn't it true that one rarely depends on Struts to auto-generate the form bean? If you are presenting data, the form is pre-populated with such data. This data is typically derived by an earlier action -- mediated by a business delegate. Say you have action-1 which is invoked when a page-1 is submitted. It does sundry business functions which includes getting the data necessary for the next page, page-2 say. In order for page-2 to pick up this data, action-1 must know the 'name' attribute for the action-mapping corresponding to page-2 and save the form-bean under this name in the appropriate scope. Is there a way around this issue? Sri -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 3:00 PM To: Struts Users Mailing List Subject: Re: request.setAttribute() form confusion You shouldn't ever have to create the form yourself if you: - declare the form-bean in your config file - use the name of the form you declared in the action mapping's name attribute form-bean name=myForm ... / ... action path=/somePath name=myForm ... / That should suffice. What you should find is that the form is created for you. Doing things as I mention simplifies you actions so that they can just expect the form to be there. If the form is not there you will probably NPE. That would indicate that you didn't create the association (by setting name=myForm) or Struts wasn't able to create the form for some odd reason. Susan Bradeen wrote: Nevermind, answering my own question ... actions in the Struts examples don't use the second line of code, so the answer is no, you don't need the two together. Susan -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion)
Doesn't doing things the way you are suggesting spread the business logic over the view and the controller? I have found that if you have a overall form which may or may not correspond to a db element but pulls in as nested forms the tables that it needs and controls the business logic to be a strong way of doing things. This means that Eddie's comment will still hold about letting struts manage the action form. Edgar -Original Message- From: Sri Sankaran [mailto:Sri.Sankaran;sas.com] Sent: Monday, November 11, 2002 2:51 PM To: 'Struts Users Mailing List' Subject: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) While that is true, other than in the case of blank forms, isn't it true that one rarely depends on Struts to auto-generate the form bean? If you are presenting data, the form is pre-populated with such data. This data is typically derived by an earlier action -- mediated by a business delegate. Say you have action-1 which is invoked when a page-1 is submitted. It does sundry business functions which includes getting the data necessary for the next page, page-2 say. In order for page-2 to pick up this data, action-1 must know the 'name' attribute for the action-mapping corresponding to page-2 and save the form-bean under this name in the appropriate scope. Is there a way around this issue? Sri -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 3:00 PM To: Struts Users Mailing List Subject: Re: request.setAttribute() form confusion You shouldn't ever have to create the form yourself if you: - declare the form-bean in your config file - use the name of the form you declared in the action mapping's name attribute form-bean name=myForm ... / ... action path=/somePath name=myForm ... / That should suffice. What you should find is that the form is created for you. Doing things as I mention simplifies you actions so that they can just expect the form to be there. If the form is not there you will probably NPE. That would indicate that you didn't create the association (by setting name=myForm) or Struts wasn't able to create the form for some odd reason. Susan Bradeen wrote: Nevermind, answering my own question ... actions in the Struts examples don't use the second line of code, so the answer is no, you don't need the two together. Susan -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: request.setAttribute() form confusion
Thank you for the help Eddie and Kris. I've already got my action mapping
set up just as you say to have them, so I'll go back to trusting Struts
with the form creation.
Susan
On 11/11/2002 02:00:55 PM Kris Schneider wrote:
Susan,
Here's a response to a different thread with the same type of code
block:
http://marc.theaimsgroup.com/?l=struts-userm=103669042429912w=2
I understand this type of approach is used in the example app, but I'd
say it's
anything but good practice. In general, if you have an action that's
going to
pre-populate a form, it's action mapping should include a name (or
attribute)
attribute for the appropriate form. Struts will take care of finding or
creating the form, ensuring that it's stored in the proper scope, and
passing
it to the execute/perform method. All you need to do then is cast it to
the
appropriate type.
Quoting Susan Bradeen [EMAIL PROTECTED]:
If I have this code, which appears to be good practice, in the
beginning
of my pre-action's execute() method:
if (form == null) {
form = new SomeForm();
if (request.equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), form);
}
else {
request.getSession().setAttribute(mapping.getAttribute(),
form);
}
}
SomeForm myForm = (SomeForm)form;
/* populate form values ... */
Do I also need to use the following line at the end (after form
population), or is this basically accomplishing the same as the above?
request.setAttribute(mapping.getAttribute(), myForm);
Thanks,
Susan Bradeen
--
To unsubscribe, e-mail:
mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-user-help;jakarta.apache.org
--
Kris Schneider mailto:kris;dotech.com
D.O.Tech http://www.dotech.com/
--
To unsubscribe, e-mail:
mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-user-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion)
Actually, the way I have tried to describe keeps business logic *entirely* out of the form-beans and uses them only as the medium of transporting data between the model and the view. I prefer not to put *any* business logic in the form beans (code re-use, lack of portability, model/controller separation -- take your pick). In other words, the form-bean is just a dumb holder of information; it doesn't know where the data came from or where it goes. Is that not the recommended purpose? Are you suggesting that the form-bean be responsible for loading/unloading the data? Sri -Original Message- From: edgar [mailto:edgar;blue-moose.net] Sent: Monday, November 11, 2002 3:04 PM To: 'Struts Users Mailing List' Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) Doesn't doing things the way you are suggesting spread the business logic over the view and the controller? I have found that if you have a overall form which may or may not correspond to a db element but pulls in as nested forms the tables that it needs and controls the business logic to be a strong way of doing things. This means that Eddie's comment will still hold about letting struts manage the action form. Edgar -Original Message- From: Sri Sankaran [mailto:Sri.Sankaran;sas.com] Sent: Monday, November 11, 2002 2:51 PM To: 'Struts Users Mailing List' Subject: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) While that is true, other than in the case of blank forms, isn't it true that one rarely depends on Struts to auto-generate the form bean? If you are presenting data, the form is pre-populated with such data. This data is typically derived by an earlier action -- mediated by a business delegate. Say you have action-1 which is invoked when a page-1 is submitted. It does sundry business functions which includes getting the data necessary for the next page, page-2 say. In order for page-2 to pick up this data, action-1 must know the 'name' attribute for the action-mapping corresponding to page-2 and save the form-bean under this name in the appropriate scope. Is there a way around this issue? Sri -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 3:00 PM To: Struts Users Mailing List Subject: Re: request.setAttribute() form confusion You shouldn't ever have to create the form yourself if you: - declare the form-bean in your config file - use the name of the form you declared in the action mapping's name attribute form-bean name=myForm ... / ... action path=/somePath name=myForm ... / That should suffice. What you should find is that the form is created for you. Doing things as I mention simplifies you actions so that they can just expect the form to be there. If the form is not there you will probably NPE. That would indicate that you didn't create the association (by setting name=myForm) or Struts wasn't able to create the form for some odd reason. Susan Bradeen wrote: Nevermind, answering my own question ... actions in the Struts examples don't use the second line of code, so the answer is no, you don't need the two together. Susan -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion)
...one rarely depends on Struts to auto-generate the form bean? If you changed rarely to almost always, I'd tend to agree with you ;-). I make a clear distinction between form creation/retrieval and population/modification. Take the typical: EditAction - JSP - SaveAction In general, the action mappings for both EditAction and SaveAction would use the same form bean. EditAction takes the form bean created/retrieved by Struts, populates/modifies it with data obtained from the business layer, and then forwards to the JSP for display. The user interacts with the page, submits to SaveAction which takes the form bean created/retrieved *and* populated/modified (from request params) by Struts and uses its data to interact with the business layer. So, I guess the key difference is that for EditAction the form bean is populated/modified with data from the business layer but for SaveAction it's done with data from request params. In both cases, Struts handles the form bean creation/retrieval. Quoting Sri Sankaran [EMAIL PROTECTED]: From: Sri Sankaran [mailto:Sri.Sankaran;sas.com] Sent: Monday, November 11, 2002 2:51 PM To: 'Struts Users Mailing List' Subject: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) While that is true, other than in the case of blank forms, isn't it true that one rarely depends on Struts to auto-generate the form bean? If you are presenting data, the form is pre-populated with such data. This data is typically derived by an earlier action -- mediated by a business delegate. Say you have action-1 which is invoked when a page-1 is submitted. It does sundry business functions which includes getting the data necessary for the next page, page-2 say. In order for page-2 to pick up this data, action-1 must know the 'name' attribute for the action-mapping corresponding to page-2 and save the form-bean under this name in the appropriate scope. Is there a way around this issue? Sri -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 3:00 PM To: Struts Users Mailing List Subject: Re: request.setAttribute() form confusion You shouldn't ever have to create the form yourself if you: - declare the form-bean in your config file - use the name of the form you declared in the action mapping's name attribute form-bean name=myForm ... / ... action path=/somePath name=myForm ... / That should suffice. What you should find is that the form is created for you. Doing things as I mention simplifies you actions so that they can just expect the form to be there. If the form is not there you will probably NPE. That would indicate that you didn't create the association (by setting name=myForm) or Struts wasn't able to create the form for some odd reason. Susan Bradeen wrote: Nevermind, answering my own question ... actions in the Struts examples don't use the second line of code, so the answer is no, you don't need the two together. Susan -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- Kris Schneider mailto:kris;dotech.com D.O.Tech http://www.dotech.com/ -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion)
...EditAction takes the form bean created/retrieved by Struts, populates/modifies it with... Wait a minute. What caused Struts to create the form bean? If that is form-bean associated with this action, the scenario I am describing is different. In my scenario, consecutive actions do not share the same form-bean. It's as if EditAction does its work and needs to prep *a*different*form* for the next screen. EditAction -- JSP -- SaveAction form-Aform-Bform-B Sri -Original Message- From: Kris Schneider [mailto:kris;dotech.com] Sent: Monday, November 11, 2002 4:17 PM To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) ...one rarely depends on Struts to auto-generate the form bean? If you changed rarely to almost always, I'd tend to agree with you ;-). I make a clear distinction between form creation/retrieval and population/modification. Take the typical: EditAction - JSP - SaveAction In general, the action mappings for both EditAction and SaveAction would use the same form bean. EditAction takes the form bean created/retrieved by Struts, populates/modifies it with data obtained from the business layer, and then forwards to the JSP for display. The user interacts with the page, submits to SaveAction which takes the form bean created/retrieved *and* populated/modified (from request params) by Struts and uses its data to interact with the business layer. So, I guess the key difference is that for EditAction the form bean is populated/modified with data from the business layer but for SaveAction it's done with data from request params. In both cases, Struts handles the form bean creation/retrieval. Quoting Sri Sankaran [EMAIL PROTECTED]: From: Sri Sankaran [mailto:Sri.Sankaran;sas.com] Sent: Monday, November 11, 2002 2:51 PM To: 'Struts Users Mailing List' Subject: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) While that is true, other than in the case of blank forms, isn't it true that one rarely depends on Struts to auto-generate the form bean? If you are presenting data, the form is pre-populated with such data. This data is typically derived by an earlier action -- mediated by a business delegate. Say you have action-1 which is invoked when a page-1 is submitted. It does sundry business functions which includes getting the data necessary for the next page, page-2 say. In order for page-2 to pick up this data, action-1 must know the 'name' attribute for the action-mapping corresponding to page-2 and save the form-bean under this name in the appropriate scope. Is there a way around this issue? Sri -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 3:00 PM To: Struts Users Mailing List Subject: Re: request.setAttribute() form confusion You shouldn't ever have to create the form yourself if you: - declare the form-bean in your config file - use the name of the form you declared in the action mapping's name attribute form-bean name=myForm ... / ... action path=/somePath name=myForm ... / That should suffice. What you should find is that the form is created for you. Doing things as I mention simplifies you actions so that they can just expect the form to be there. If the form is not there you will probably NPE. That would indicate that you didn't create the association (by setting name=myForm) or Struts wasn't able to create the form for some odd reason. Susan Bradeen wrote: Nevermind, answering my own question ... actions in the Struts examples don't use the second line of code, so the answer is no, you don't need the two together. Susan -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- Kris Schneider mailto:kris;dotech.com D.O.Tech http://www.dotech.com/ -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: [SIDEBAR] Form population (Was RE: request.setAttribute() formconfusion)
Sri, pardon me, but I don't see how what you've said has anything to do with the point I was making. My sole point is that the actual creation (instantiation) of the form bean itself is a very mechanical act that Struts can perform on your behalf. There is no need to ever bother with creating a bean and placing it into some scope - just configure things properly and let it be done for you. Yes, you may very well need to initialize it's values in an action - but that is a seperate act from instantiation. Why bother specifying a form-bean in your config file if you're going to create it yourself? Yeah there's some validation that can be done on it by Struts - but if you don't specify a form-bean for an action-mapping (you specify nothing for the action-mapping's name attribute) I don't believe that validation is done (why would it be? Struts doesn't know there's a form being used for this action!). Hrm - in fact you lose a great deal of the utility Struts provides if you don't make this association. Think about it: You have to tell Struts what type your form is of - so it can instantiate it. It needs this information for no other purpose. It could easily tell later on that the form is of the wrong type for validation etc. Also, you could specify by the attribute property the name of a form which you instantiated yourself. You *could* (if you wanted to) cut yourself off from the Struts form mechanism altogether. What I suggest in no way impacts your ability to use good design (delegates etc). It just takes one very mechanical thing out of your hands - and out of your concern - and just does it. It's solid. It works. If it ever fails you *please* file a bug! It also has no impact on where data comes from or where it goes to. You can pass data via a form from one action to another in about 2 ways that come to mind immediately: 1) session-scoped form 2) using hidden fields. I'm sorry, but I think you misunderstood my entire argument. My appologies for not having been clearer. Sri Sankaran wrote: While that is true, other than in the case of blank forms, isn't it true that one rarely depends on Struts to auto-generate the form bean? If you are presenting data, the form is pre-populated with such data. This data is typically derived by an earlier action -- mediated by a business delegate. Say you have action-1 which is invoked when a page-1 is submitted. It does sundry business functions which includes getting the data necessary for the next page, page-2 say. In order for page-2 to pick up this data, action-1 must know the 'name' attribute for the action-mapping corresponding to page-2 and save the form-bean under this name in the appropriate scope. Is there a way around this issue? Sri -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 3:00 PM To: Struts Users Mailing List Subject: Re: request.setAttribute() form confusion You shouldn't ever have to create the form yourself if you: - declare the form-bean in your config file - use the name of the form you declared in the action mapping's name attribute form-bean name=myForm ... / ... action path=/somePath name=myForm ... / That should suffice. What you should find is that the form is created for you. Doing things as I mention simplifies you actions so that they can just expect the form to be there. If the form is not there you will probably NPE. That would indicate that you didn't create the association (by setting name=myForm) or Struts wasn't able to create the form for some odd reason. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion)
I have interpreted that the form bean be the repository for the bulk of the business logic surrounding it's elements. Then I can use any number of JSP pages to display / modify / whatever with minimal knowledge of the basic business rule. I don't know if that is what was intended, it just appears natural to me. I also don't have a another tool which might control the business logic so that might be our difference. I don't like to put too much business logic in the database because that tends to force use of DB specific code. There is a program turbine which is reccomended to be used with struts which is designed to handle some of the database operations which might change my analysis, but I haven't had time to review it. What are you using to do the business model? Thanks. Edgar -Original Message- From: Sri Sankaran [mailto:Sri.Sankaran;sas.com] Sent: Monday, November 11, 2002 3:12 PM To: 'Struts Users Mailing List'; Edgar Dollin Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) Actually, the way I have tried to describe keeps business logic *entirely* out of the form-beans and uses them only as the medium of transporting data between the model and the view. I prefer not to put *any* business logic in the form beans (code re-use, lack of portability, model/controller separation -- take your pick). In other words, the form-bean is just a dumb holder of information; it doesn't know where the data came from or where it goes. Is that not the recommended purpose? Are you suggesting that the form-bean be responsible for loading/unloading the data? Sri -Original Message- From: edgar [mailto:edgar;blue-moose.net] Sent: Monday, November 11, 2002 3:04 PM To: 'Struts Users Mailing List' Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) Doesn't doing things the way you are suggesting spread the business logic over the view and the controller? I have found that if you have a overall form which may or may not correspond to a db element but pulls in as nested forms the tables that it needs and controls the business logic to be a strong way of doing things. This means that Eddie's comment will still hold about letting struts manage the action form. Edgar -Original Message- From: Sri Sankaran [mailto:Sri.Sankaran;sas.com] Sent: Monday, November 11, 2002 2:51 PM To: 'Struts Users Mailing List' Subject: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) While that is true, other than in the case of blank forms, isn't it true that one rarely depends on Struts to auto-generate the form bean? If you are presenting data, the form is pre-populated with such data. This data is typically derived by an earlier action -- mediated by a business delegate. Say you have action-1 which is invoked when a page-1 is submitted. It does sundry business functions which includes getting the data necessary for the next page, page-2 say. In order for page-2 to pick up this data, action-1 must know the 'name' attribute for the action-mapping corresponding to page-2 and save the form-bean under this name in the appropriate scope. Is there a way around this issue? Sri -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 3:00 PM To: Struts Users Mailing List Subject: Re: request.setAttribute() form confusion You shouldn't ever have to create the form yourself if you: - declare the form-bean in your config file - use the name of the form you declared in the action mapping's name attribute form-bean name=myForm ... / ... action path=/somePath name=myForm ... / That should suffice. What you should find is that the form is created for you. Doing things as I mention simplifies you actions so that they can just expect the form to be there. If the form is not there you will probably NPE. That would indicate that you didn't create the association (by setting name=myForm) or Struts wasn't able to create the form for some odd reason. Susan Bradeen wrote: Nevermind, answering my own question ... actions in the Struts examples don't use the second line of code, so the answer is no, you don't need the two together. Susan -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org
Re: [SIDEBAR] Form population (Was RE: request.setAttribute() formconfusion)
... why are you changing forms? Do you forward to the JSP or redirect? Unless you do something special in EditAction the form you are dealing with in JSP is form-A --- not form-B. That is irrelevant though - as the user will submit form-A and form-B will be created (if needed - assuming you've configured things right) and populated and fed to SaveAction. Why two different forms here? Why not set a property of the form that says what you're doing? ... or rely on the value of a field to tell you (field meaning something that is actually present in the bean [VO/DTO] represented by the form) - such as a null OID or some such. I don't see why you would have this arrangement ... but I do not know your circumstance. Sri Sankaran wrote: ...EditAction takes the form bean created/retrieved by Struts, populates/modifies it with... Wait a minute. What caused Struts to create the form bean? If that is form-bean associated with this action, the scenario I am describing is different. In my scenario, consecutive actions do not share the same form-bean. It's as if EditAction does its work and needs to prep *a*different*form* for the next screen. EditAction -- JSP -- SaveAction form-Aform-Bform-B Sri -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: [SIDEBAR] Form population (Was RE: request.setAttribute() formconfusion)
My apologies - you were going after edgar - and rightfully so :-) edgar: Listen to Sri the wise ;-) Eddie Bush wrote: Sri, pardon me, but I don't see how what you've said has anything to do with the point I was making. My sole point is that the actual creation (instantiation) of the form bean itself is a very mechanical act that Struts can perform on your behalf. There is no need to ever bother with creating a bean and placing it into some scope - just configure things properly and let it be done for you. Yes, you may very well need to initialize it's values in an action - but that is a seperate act from instantiation. Why bother specifying a form-bean in your config file if you're going to create it yourself? Yeah there's some validation that can be done on it by Struts - but if you don't specify a form-bean for an action-mapping (you specify nothing for the action-mapping's name attribute) I don't believe that validation is done (why would it be? Struts doesn't know there's a form being used for this action!). Hrm - in fact you lose a great deal of the utility Struts provides if you don't make this association. Think about it: You have to tell Struts what type your form is of - so it can instantiate it. It needs this information for no other purpose. It could easily tell later on that the form is of the wrong type for validation etc. Also, you could specify by the attribute property the name of a form which you instantiated yourself. You *could* (if you wanted to) cut yourself off from the Struts form mechanism altogether. What I suggest in no way impacts your ability to use good design (delegates etc). It just takes one very mechanical thing out of your hands - and out of your concern - and just does it. It's solid. It works. If it ever fails you *please* file a bug! It also has no impact on where data comes from or where it goes to. You can pass data via a form from one action to another in about 2 ways that come to mind immediately: 1) session-scoped form 2) using hidden fields. I'm sorry, but I think you misunderstood my entire argument. My appologies for not having been clearer. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion)
OK Eddie, what do you use to model the business logic? -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 6:16 PM To: 'Struts Users Mailing List' Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) My apologies - you were going after edgar - and rightfully so :-) edgar: Listen to Sri the wise ;-) Eddie Bush wrote: -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: [SIDEBAR] Form population (Was RE: request.setAttribute() formconfusion)
edgar wrote: OK Eddie, what do you use to model the business logic? Classes which aren't dependant on Struts ;-) Seriously. Most everyone is going to tell you to build things in layers - aiming for low cohesion between them. Data goes up (through he layers) and dependencies go down (through the layers). So it would be acceptable to have a business-domain layer built on top of your persistence layer - but not versa-vice (er vice-versa too). Encapsulate everything you can using good OO methodologies and make it all as stupid as you can. So you have ... something like ... ActionClasses make calls to Business logic beans (delegates, if you like to call them that) which make calls to DAOs (or other persistence mechanism) The action probably instantiates a VO/DTO and does a copy and passes things to the BLBs. That's how I tend to go about it. So you're just mapping from the view to your model in the action (or model to view if your outputting). Build the system to be UI-agnostic. Then, use the actions as an opportunity to retrofit for Struts being the view. Translate the HTTP request into whatever inputs your BLBs take (probably VOs or DTOs depending on the name you like to use) using BeanUtils or something else to do a copy and then shoot things off to your BLBs. Then, take the outputs and ... well everything in the action-class is UI-centric but you can probably acheive a better (more usable - easier-managed) design by taking advantage of encapsulating things and then just building on top of that - on the shoulders of giants as the phrase goes. That speaks volumes about OO IMHO. If your DAOs know how to do your data-access - and they work solid - you needn't bother reproducing that effort anywhere else. If your BLBs know how to run your business, provided your DAOs - and they work solid - you needn't bother reproducing that effort anywhere else. You may even choose to throw a layer on top of the BLBs - an API (facade, if you like) or ... well, there's a myriad of ways ... If you have your logic inside of form beans then you can't use that logic without importing org.apache.struts.* stuff - and your business logic should have zero dependencies on Struts. What's going to happen when you change and go to another framework (ok that's probably not going to happen, but ...) - or you build a SWING GUI to run the show for your tech support guys? If you have your logic encapsulated in UI-agnostic things (the BLBs) then it really doesn't matter - just write wrappers around your BLBs that adapt them to the SWING GUI. Clear as mud? Someone help me here - I suck at explaining the why and wherefore ... -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 6:16 PM To: 'Struts Users Mailing List' Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) My apologies - you were going after edgar - and rightfully so :-) edgar: Listen to Sri the wise ;-) -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: [SIDEBAR] Form population (Was RE: request.setAttribute() formconfusion)
Like Eddie Says use DAO pattern it makes life much easier, and gives you a very valuable abstraction layer. Mark - Original Message - From: Eddie Bush [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Tuesday, November 12, 2002 1:00 AM Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() formconfusion) edgar wrote: OK Eddie, what do you use to model the business logic? Classes which aren't dependant on Struts ;-) Seriously. Most everyone is going to tell you to build things in layers - aiming for low cohesion between them. Data goes up (through he layers) and dependencies go down (through the layers). So it would be acceptable to have a business-domain layer built on top of your persistence layer - but not versa-vice (er vice-versa too). Encapsulate everything you can using good OO methodologies and make it all as stupid as you can. So you have ... something like ... ActionClasses make calls to Business logic beans (delegates, if you like to call them that) which make calls to DAOs (or other persistence mechanism) The action probably instantiates a VO/DTO and does a copy and passes things to the BLBs. That's how I tend to go about it. So you're just mapping from the view to your model in the action (or model to view if your outputting). Build the system to be UI-agnostic. Then, use the actions as an opportunity to retrofit for Struts being the view. Translate the HTTP request into whatever inputs your BLBs take (probably VOs or DTOs depending on the name you like to use) using BeanUtils or something else to do a copy and then shoot things off to your BLBs. Then, take the outputs and ... well everything in the action-class is UI-centric but you can probably acheive a better (more usable - easier-managed) design by taking advantage of encapsulating things and then just building on top of that - on the shoulders of giants as the phrase goes. That speaks volumes about OO IMHO. If your DAOs know how to do your data-access - and they work solid - you needn't bother reproducing that effort anywhere else. If your BLBs know how to run your business, provided your DAOs - and they work solid - you needn't bother reproducing that effort anywhere else. You may even choose to throw a layer on top of the BLBs - an API (facade, if you like) or ... well, there's a myriad of ways ... If you have your logic inside of form beans then you can't use that logic without importing org.apache.struts.* stuff - and your business logic should have zero dependencies on Struts. What's going to happen when you change and go to another framework (ok that's probably not going to happen, but ...) - or you build a SWING GUI to run the show for your tech support guys? If you have your logic encapsulated in UI-agnostic things (the BLBs) then it really doesn't matter - just write wrappers around your BLBs that adapt them to the SWING GUI. Clear as mud? Someone help me here - I suck at explaining the why and wherefore ... -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 6:16 PM To: 'Struts Users Mailing List' Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) My apologies - you were going after edgar - and rightfully so :-) edgar: Listen to Sri the wise ;-) -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion)
OK. We don't disagree much, accept in semantics. I do subclass the struts ActionForm in an abstract class and subclass everything else from that, but all the other business logic is separate and stands by itself. If I had to go to a different framework, I would replace the connector class. I do appreciate your comments. Thanks -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 7:01 PM To: 'Struts Users Mailing List' Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) edgar wrote: OK Eddie, what do you use to model the business logic? Classes which aren't dependant on Struts ;-) -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute()for m confusion)
-Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 2:46 PM To: Struts Users Mailing List Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) Sri, pardon me, but I don't see how what you've said has anything to do with the point I was making. My sole point is that the actual creation (instantiation) of the form bean itself is a very mechanical act that Struts can perform on your behalf. There is no need to ever bother with creating a bean and placing it into some scope - just configure things properly and let it be done for you. Yes, you may very well need to initialize it's values in an action - but that is a seperate act from instantiation. I think you missed the point here, Eddie (or perhaps I missed that you didn't miss the point :). Think about it this way. Struts will create your form bean automagically in a couple of cases: when it needs to populate one from an incoming request, and when it needs to render a form but can't find the corresponding form bean. Now consider the case where you need to populate the form with some values that the Action came up with somehow. You'd do that by having the values in the form bean properties, right? That way, the Struts HTML tags will do the work for you. But now consider the case where you haven't yet invoked anything in the app that would cause the appropriate form bean to be instantiated. The action that came up with the values might have been invoked with a different form bean, or perhaps no form bean at all. So Struts hasn't instantiated the bean yet. Struts *will* instantiate the bean when it the html:form tag is processed, but by then, it's too late for the Action to populate the form bean. So the only way for the action to pre-populate the form bean, so that those values are picked up by the Struts HTML tags to populate the form is for the action to instantiate the form bean itself. One way of creating the form bean is RequestUtils.createActionForm(). -- Martin Cooper Why bother specifying a form-bean in your config file if you're going to create it yourself? Yeah there's some validation that can be done on it by Struts - but if you don't specify a form-bean for an action-mapping (you specify nothing for the action-mapping's name attribute) I don't believe that validation is done (why would it be? Struts doesn't know there's a form being used for this action!). Hrm - in fact you lose a great deal of the utility Struts provides if you don't make this association. Think about it: You have to tell Struts what type your form is of - so it can instantiate it. It needs this information for no other purpose. It could easily tell later on that the form is of the wrong type for validation etc. Also, you could specify by the attribute property the name of a form which you instantiated yourself. You *could* (if you wanted to) cut yourself off from the Struts form mechanism altogether. What I suggest in no way impacts your ability to use good design (delegates etc). It just takes one very mechanical thing out of your hands - and out of your concern - and just does it. It's solid. It works. If it ever fails you *please* file a bug! It also has no impact on where data comes from or where it goes to. You can pass data via a form from one action to another in about 2 ways that come to mind immediately: 1) session-scoped form 2) using hidden fields. I'm sorry, but I think you misunderstood my entire argument. My appologies for not having been clearer. Sri Sankaran wrote: While that is true, other than in the case of blank forms, isn't it true that one rarely depends on Struts to auto-generate the form bean? If you are presenting data, the form is pre-populated with such data. This data is typically derived by an earlier action -- mediated by a business delegate. Say you have action-1 which is invoked when a page-1 is submitted. It does sundry business functions which includes getting the data necessary for the next page, page-2 say. In order for page-2 to pick up this data, action-1 must know the 'name' attribute for the action-mapping corresponding to page-2 and save the form-bean under this name in the appropriate scope. Is there a way around this issue? Sri -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 3:00 PM To: Struts Users Mailing List Subject: Re: request.setAttribute() form confusion You shouldn't ever have to create the form yourself if you: - declare the form-bean in your config file - use the name of the form you declared in the action mapping's name attribute form-bean name=myForm ... / ... action path=/somePath name=myForm ... / That should suffice. What you should find is that the form is created for you
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion)
Yes! Finally someone who sees what I am talking about! *That's* exactly the scenario I am talking about. I can't see how Struts can divine what values the form-bean property needs to be initialized. It is predicated by the preceding business logic. Sri -Original Message- From: Martin Cooper [mailto:martin.cooper;tumbleweed.com] Sent: Monday, November 11, 2002 9:40 PM To: 'Struts Users Mailing List' Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 2:46 PM To: Struts Users Mailing List Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) Sri, pardon me, but I don't see how what you've said has anything to do with the point I was making. My sole point is that the actual creation (instantiation) of the form bean itself is a very mechanical act that Struts can perform on your behalf. There is no need to ever bother with creating a bean and placing it into some scope - just configure things properly and let it be done for you. Yes, you may very well need to initialize it's values in an action - but that is a seperate act from instantiation. I think you missed the point here, Eddie (or perhaps I missed that you didn't miss the point :). Think about it this way. Struts will create your form bean automagically in a couple of cases: when it needs to populate one from an incoming request, and when it needs to render a form but can't find the corresponding form bean. Now consider the case where you need to populate the form with some values that the Action came up with somehow. You'd do that by having the values in the form bean properties, right? That way, the Struts HTML tags will do the work for you. But now consider the case where you haven't yet invoked anything in the app that would cause the appropriate form bean to be instantiated. The action that came up with the values might have been invoked with a different form bean, or perhaps no form bean at all. So Struts hasn't instantiated the bean yet. Struts *will* instantiate the bean when it the html:form tag is processed, but by then, it's too late for the Action to populate the form bean. So the only way for the action to pre-populate the form bean, so that those values are picked up by the Struts HTML tags to populate the form is for the action to instantiate the form bean itself. One way of creating the form bean is RequestUtils.createActionForm(). -- Martin Cooper Why bother specifying a form-bean in your config file if you're going to create it yourself? Yeah there's some validation that can be done on it by Struts - but if you don't specify a form-bean for an action-mapping (you specify nothing for the action-mapping's name attribute) I don't believe that validation is done (why would it be? Struts doesn't know there's a form being used for this action!). Hrm - in fact you lose a great deal of the utility Struts provides if you don't make this association. Think about it: You have to tell Struts what type your form is of - so it can instantiate it. It needs this information for no other purpose. It could easily tell later on that the form is of the wrong type for validation etc. Also, you could specify by the attribute property the name of a form which you instantiated yourself. You *could* (if you wanted to) cut yourself off from the Struts form mechanism altogether. What I suggest in no way impacts your ability to use good design (delegates etc). It just takes one very mechanical thing out of your hands - and out of your concern - and just does it. It's solid. It works. If it ever fails you *please* file a bug! It also has no impact on where data comes from or where it goes to. You can pass data via a form from one action to another in about 2 ways that come to mind immediately: 1) session-scoped form 2) using hidden fields. I'm sorry, but I think you misunderstood my entire argument. My appologies for not having been clearer. Sri Sankaran wrote: While that is true, other than in the case of blank forms, isn't it true that one rarely depends on Struts to auto-generate the form bean? If you are presenting data, the form is pre-populated with such data. This data is typically derived by an earlier action -- mediated by a business delegate. Say you have action-1 which is invoked when a page-1 is submitted. It does sundry business functions which includes getting the data necessary for the next page, page-2 say. In order for page-2 to pick up this data, action-1 must know the 'name' attribute for the action-mapping corresponding to page-2 and save the form-bean under this name in the appropriate scope. Is there a way around this issue? Sri -Original Message- From: Eddie Bush
Re: Request.setAttribute() and jsp
Check if in the forwards of your action you do not write a thing like this forward path=*** redirect=true/ Mohammed [EMAIL PROTECTED] wrote: Hello, in my action class I am setting in my request an object as follow: SourceBean sourcebean= new SourceBean(); sourcebean.setSource( Longon); request.setAttribute(source ,sourcebean); And in my jsp file try to get a refererence % SourceBean sourcebean = (SourceBean)request.getAttribute(source); if(sourcebean = = null)System.out.println( the source bean object is null); else( System.out.println( sourcebean.getSource()); my Problem is that I am getting null for the sourcebean object. I think the jsp servlet is getting always a new session but I don't know why? Thanks for any hint Mohammed = -- KeV -- = -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Request.setAttribute() and jsp
No I am not setting the redirect attribute in the forward. Should I set this attribute to false or true? (I set it to true but it didn't work either). Mohammed - Original Message - From: Viet Kevin [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Friday, November 23, 2001 3:24 PM Subject: Re: Request.setAttribute() and jsp Check if in the forwards of your action you do not write a thing like this forward path=*** redirect=true/ Mohammed [EMAIL PROTECTED] wrote: Hello, in my action class I am setting in my request an object as follow: SourceBean sourcebean= new SourceBean(); sourcebean.setSource( Longon); request.setAttribute(source ,sourcebean); And in my jsp file try to get a refererence % SourceBean sourcebean = (SourceBean)request.getAttribute(source); if(sourcebean = = null)System.out.println( the source bean object is null); else( System.out.println( sourcebean.getSource()); my Problem is that I am getting null for the sourcebean object. I think the jsp servlet is getting always a new session but I don't know why? Thanks for any hint Mohammed = -- KeV -- = -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Request.setAttribute() and jsp
Thanks kevin . now it is working Mohammed - Original Message - From: Viet Kevin [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Friday, November 23, 2001 3:24 PM Subject: Re: Request.setAttribute() and jsp Check if in the forwards of your action you do not write a thing like this forward path=*** redirect=true/ Mohammed [EMAIL PROTECTED] wrote: Hello, in my action class I am setting in my request an object as follow: SourceBean sourcebean= new SourceBean(); sourcebean.setSource( Longon); request.setAttribute(source ,sourcebean); And in my jsp file try to get a refererence % SourceBean sourcebean = (SourceBean)request.getAttribute(source); if(sourcebean = = null)System.out.println( the source bean object is null); else( System.out.println( sourcebean.getSource()); my Problem is that I am getting null for the sourcebean object. I think the jsp servlet is getting always a new session but I don't know why? Thanks for any hint Mohammed = -- KeV -- = -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: request.setAttribute(variable, value) bug
Sounds like a logic problem, are you sure that the logic in the action class isn't branching around the part where it adds the questions? Maybe if you send your code... -Original Message- From: Christophe Rikelynck [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 25, 2001 6:19 AM To: struts-user Subject: request.setAttribute(variable, value) bug I have an action class BeforeSelectQuestionAction.java where I get all questions from the database and put them to the request with request.setAttribute(questions, questions). When i surf to BeforeSelectQuestion.do there is no problem and in the jsp page that follows I see all questions in the select box. In the select box, i added an option Select question that is default selected, so that the user just doesn't click the submit button. When this option is selected and submitted to the SelectQuestionAction.java action class, this one will forward again to BeforeSelectQuestion.do, where again all questions are put to the request. But in the jsp page that follows BeforeSelectQuestionAction.java (the one where I select a question), the bean questions is null. When i surf directly to the action class, there is no problem, but when I select the default option Select question I receive an error that tells that the bean questions is null. What is the problem? Everything works fine when i use HttpSession, but I want to use request.getParameter and request.setParameter. Can anyone help me? Thanks.
