Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: pass (herse.apache.org: domain of srinivasulaa@hcl.in designates
 203.105.186.19 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Subject: RE: [S2] decoding values of objects properties
Date: Wed, 6 Jun 2007 16:48:42 +0530
Message-ID: 
 <92593ECAE541F24C9D16295C76EB95404AB5EC@BLR-HCLT-EVS02.HCLT.CORP.HCL.IN>
Thread-Topic: [S2] decoding values of objects properties
Thread-Index: AceoK/WHJqXVwpyFT3+taiq3B8D0AwAAEcHQ
From: "Srinivasula Reddy A , Bangalore" <srinivasulaa@hcl.in>
To: "Struts Users Mailing List" <user@struts.apache.org>


BUT GURU WHEN I CLOSE THE IE SESSEIONDESTROYED METHOD IS NOT EXECUTING=20

IS THERE ANY CONFIGURATION PARAMETERS I HAVE TO SET IN WEB.XML OR
STRUTS-CONFIG.XML

-----Original Message-----
From: Dave Newton [mailto:newton.dave@yahoo.com]=20
Sent: Wednesday, June 06, 2007 4:45 PM
To: Struts Users Mailing List
Subject: Re: [S2] decoding values of objects properties

I'm still not entirely what you're decoding from and
to; it sounds like something is fundamentally broken,
but...

Remember that with OGNL you *can* call arbitrary
methods, including static utility methods, from with
the EL. So with either a static decoding class or
(preferably) a service object in your action if you're
iterating over a list you can call methods on items
from that list.

d.

--- Paolo Beccari <pbeccari@email.it> wrote:

>=20
> > --- Dave Newton  wrote:
> >
> > Why?
> >
>=20
> I'll try to explain. The main problem is, that i
> would not to expose a=20
> single getter-method in the action for each property
> I want to decode. I'm=20
> searching for a more generic method.
> I thought on some possibile solution, one was to
> return, in each action, the=20
> entire decode set (roughly speaking, a series of
> tuples name-value-decode).=20
> That way, I could handle it with <s:iterator and
> <s:if tag each time I need=20
> a decode. In addition, if the decoded value I'm
> searching is the last in the=20
> list, the list is entirely scrolled before finding
> result. So I tend to=20
> discard that.
>=20
> Maybe it is only a matter of wrong architectural
> design: we are returning to=20
> the views some objects mapped from the database
> layer "as they are". It is=20
> possible we need an additional level between, to
> provide decoded values for=20
> each property, but the temptation to use a scriplet
> <%=3DDecode(name, value)%>=20
> with a generic, singleton Decoder class is still
> strong :).
>=20
> >
> > I've never had to do that, but if I did, I'd be
> most
> > likely to do it in the action or, more likely, a
> > service object in the action.
> >
> > d.
> >
>=20
> Yes, I'd be most likely to do, too. But I have to
> find a way to NOT write=20
> hundreds of methods, one for each decode-set.
> Well, I'll continue thinking on it, BTW thanks for
> reply.
>=20
> P.
>=20
>=20
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> user-unsubscribe@struts.apache.org
> For additional commands, e-mail:
> user-help@struts.apache.org
>=20
>=20


      =20
________________________________________________________________________
____________
Get the free Yahoo! toolbar and rest assured with the added security of
spyware protection.
http://new.toolbar.yahoo.com/toolbar/features/norton/index.php

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

DISCLAIMER:
---------------------------------------------------------------------------=
--------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and=
 intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its=
 affiliates. Any views or opinions presented in=20
this email are solely those of the author and may not necessarily reflect=
 the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,=
 distribution and / or publication of=20
this message without the prior written consent of the author of this e-mail=
 is strictly prohibited. If you have
received this email in error please delete it and notify the sender=
 immediately. Before opening any mail and=20
attachments please check them for viruses and defect.

---------------------------------------------------------------------------=
--------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org