subject:"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

2003-11-28 Thread Lopez, Felix

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:
> 
> request.setAttribute("myObejct", o);
> ...
> MyObject o2 = (MyObject)request.getAttribute("o");
> 
>
> 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

2003-11-28 Thread Claire Wall

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.


<%
java.util.Enumeration e2 =
this_request.getAttributeNames();
while (e2.hasMoreElements()) {
String element =
(String)e2.nextElement();
out.write("" + element + " : " +
this_request.getAttribute(element).getClass().getName());
out.write("" +
this_request.getAttribute(element).toString() + "");

}


%>


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.
>
> 
> <%
> java.util.Enumeration e2 =
> this_request.getAttributeNames();
> while (e2.hasMoreElements()) {
> String element =
> (String)e2.nextElement();
> out.write("" + element + " : " +
> this_request.getAttribute(element).getClass().getName());
> out.write("" +
> this_request.getAttribute(element).toString() + "");
>
> }
>
>
> %>


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.
> >
> > 
> > <%
> > java.util.Enumeration e2 =
> > this_request.getAttributeNames();
> > while (e2.hasMoreElements()) {
> > String element =
> > (String)e2.nextElement();
> > out.write("" + element + " : " +
> > this_request.getAttribute(element).getClass().getName());
> > out.write("" +
> > this_request.getAttribute(element).toString() + "");
> >
> > }
> >
> >
> > %>
> 
> 
> 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
> >>>

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:


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.
>>>
>>> 
>>> <%
>>> java.util.Enumeration e2 =
>>> this_request.getAttributeNames();
>>> while (e2.hasMoreElements()) {
>>> String element =
>>> (String)e2.nextElement();
>>> out.write("" + element + " : " +
>>> this_request.getAttribute(element).getClass().getName());
>>> out.write("" +
>>> this_request.getAttribute(element).toString() + "");
>>>
>>> }
>>>
>>>
>>> %>
>>
>>
>> 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:
>>&

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:
>  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.
> >>>
> >>> 
> >>> <%
> >>> java.util.Enumeration e2 =
> >>> this_request.getAttributeNames();
> >>> while (e2.hasMoreElements()) {
> >>> String element =
> >>> (String)e2.nextElement();
> >>> out.write("" + element + " : " +
> >>> this_request.getAttribute(element).getClass().getName());
> >>> out.write("" +
> >>> this_request.getAttribute(element).toString() + "");
> >>>
> >>> }
> >>>
> >>>
> >>> %>
> >>
> >>
> >> 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 MyObj

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:


   
  

the CreateServerAction i've attached last message.

the editServer.jsp uses:
 

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:
>> > 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.
>>>>>
>>>>> 
>>>>> <%
>>>>> java.util.Enumeration e2 =
>>>>> this_request.getAttributeNames();
>>>>> while (e2.hasMoreElements()) {
>>>>> String element =
>>>>> (String)e2.nextElement();
>>>>> out.write("" + element + " : " +
>>>>> this_request.getAttribute(element).getClass().getName());
>>>>> out.write("" +
>>>>> this_request.getAttribute(element).toString() + "");
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> %>
>>>>
>>>>
>>>> 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");
>>>>>> req

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:
> 
>  type="cz.master.is.tech.server.CreateServerAction"
> input="/server/showServers.do">
>
>   
> 
> the CreateServerAction i've attached last message.
> 
> the editServer.jsp uses:
>   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:
> >>  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.
> >>>>>
> >>>>> 
> >>>>> <%
> >>>>> java.util.Enumeration e2 =
> >>>>> this_request.getAttributeNames();
> >>>>> while (e2.hasMoreElements()) {
> >>>>> String element =
> >>>>> (String)e2.nextElement();
> >>>>> out.write("" + element + " : " +
> >>>>> this_request.getAttribute(element).getClass().getName());
> >>>>> out.write("" +
> >>>>> this_request.getAttribute(element).toString() + "");
> >>>>>
> >>>>> }
> >>>>>
> >>>>>
> >>>

Re: request.setAttribute

2003-11-28 Thread José Ventura

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:
> >
> >  > type="cz.master.is.tech.server.CreateServerAction"
> > input="/server/showServers.do">
> >
> >   
> >
> > the CreateServerAction i've attached last message.
> >
> > the editServer.jsp uses:
> >   > 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:
> > >>  > 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
>

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:
>>>
>>> >> type="cz.master.is.tech.server.CreateServerAction"
>>> input="/server/showServers.do">
>>>
>>>   
>>>
>>> the CreateServerAction i've attached last message.
>>>
>>> the editServer.jsp uses:
>>>  >> 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:
>>>>> >> 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...
>>>

RE: request.setAttribute

2003-11-28 Thread Kalra, Ashwani

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: request.setAttribute() form confusion

2002-11-11 Thread Susan Bradeen

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: 

> For additional commands, e-mail: 

> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

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



...



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:   
For additional commands, e-mail:

Re: request.setAttribute() form confusion

2002-11-11 Thread Kris Schneider

Susan,

Here's a response to a different thread with the same type of code block:

http://marc.theaimsgroup.com/?l=struts-user&m=103669042429912&w=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:  
> 
> For additional commands, e-mail:
> 
> 


-- 
Kris Schneider 
D.O.Tech   

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: request.setAttribute() form confusion

2002-11-11 Thread Susan Bradeen

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-user&m=103669042429912&w=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:
> > 
> > For additional commands, e-mail:
> > 
> >
> 
> 
> --
> Kris Schneider 
> D.O.Tech   
> 
> --
> To unsubscribe, e-mail: 

> For additional commands, e-mail: 

> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: Request.setAttribute() and jsp

2001-11-23 Thread Viet Kevin



Check if in the forwards of your action you do not write a thing like this 



"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:   
For additional commands, e-mail:

Re: Request.setAttribute() and jsp

2001-11-23 Thread Mohammed


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
> 
>
>
> "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

2001-11-23 Thread Mohammed


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
> 
>
>
> "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

2001-09-25 Thread Hans Gilde


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:

[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

...

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() 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



...



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() 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:   
For additional commands, e-mail:

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:   
For additional commands, e-mail:

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)

2002-11-11 Thread Mark Ayad

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)

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

...

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: [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

...

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)

2002-11-11 Thread Kris Schneider

"...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
> 
> 
> 
> ...
> 
> 
> 
> 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
> 
> 
> 
> ...
> 
> 
> 
> 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() 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

...

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&

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() 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 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  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  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 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:   
For additional commands, e-mail:

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

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:
For additional commands, e-mail:

RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion)

2002-11-12 Thread Craig R. McClanahan

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
> >
> >  > 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 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


  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 ^



--
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)

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. 
 :-)

--
Eddie Bush




--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: [SIDEBAR] Form population (Was RE: request.setAttribute()for m confusion)

2002-11-11 Thread Martin Cooper



> -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  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: Mond

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  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
> su

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

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  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 altogeth

RE: [SIDEBAR] Form population (Was RE: request.setAttribute()for m confusion)

2002-11-12 Thread Martin Cooper



> -Original Message-
> From: Eddie Bush [mailto:ekbush@;swbell.net]
> Sent: Tuesday, November 12, 2002 8:31 AM
> To: Struts Users Mailing List
> Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute()
> for m confusion)
> 
> 
> 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 
>  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 ;-)

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?

> 
> >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 

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.

--
Martin Cooper


> 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>
> 
> 


--
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)

2002-11-12 Thread Martin Cooper



> -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
> 
>  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. St

RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion)

2002-11-12 Thread edgar

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

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  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

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
> >
> > >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
> > >
> > >  > > 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 m confusion)

2002-11-12 Thread Martin Cooper

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
> >>>
> >>> >>>   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 ^
> 
> 
> 
> -- 
> 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 m confusion)