On 23/03/2004 23:39, "Joe Germuska" <[EMAIL PROTECTED]> wrote:
> At 12:06 PM +0000 3/23/04, Pedro Salgado wrote:
>> <html:messages id="error">
>>
>> ...
>>
>> </html:messages>
>>
>> Does anyone know how do I fill the ${???} to have a JSTL equivalent for
>> the previous html tag?
>>
>> <c:forEach items='${???}' var='error'>
>>
>> ...
>>
>> </c:forEach>
>
> The keys are defined in org.apache.struts.Globals:
>
>
> org.apache.struts.Globals.ERROR_KEY = "org.apache.struts.action.ERROR"
> org.apache.struts.Globals. MESSAGE_KEY =
> "org.apache.struts.action.ACTION_MESSAGE"
>
>
> Until recently, the messages were always stored in request scope, so
>
> ${requestScope['org.apache.struts.action.ERROR']}
>
This was what I was looking for :)
> In recent nightly builds, the ability to store the messages in the
> session instead was added.
If something changes in the future (it seems like so) then it would only
need a test to check if the messages were on the session or request scope.
Please correct me if I am wrong.
>
> I'm not sure I believe that this is a case where using the JSTL is
> better than using the Struts tags. It seems to me that leaving the
> coordination inside Struts classes is the way to go. Also, there is
> no JSTL solution as clean as using the "property" attribute of
> html:messages to filter to only include messages associated with a
> specific property.
>
> I'm all for people using the JSTL wherever its better, but I'm not
> sure its better here...
>
You're right but it is easier for someone to start playing with JSTL
(specially if you had experience in JSP), learn the basics and start
producing code and, in parallel, making a step-by-step understanding of how
Struts works. In a team, I think this will work better (at least I hope so).
To learn Struts tags right away it requires a double effort: understanding
Struts and taglibs (I have seen this happen and it didn't turn out very
well).
Thank you for your help,
Pedro Salgado
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
