At 7:34 AM -0700 5/5/06, Don Brown wrote:
But since this class implements List and Map, it is very obvious how
to retrieve messages:
<c:forEach var="msg" items="${msgs}">
<li>${msg}</li>
</c:forEach>
or
<c:forEach var="msg" items="${msgs['fooField']">
<li>${msg}</li>
</c:forEach>
Which class implements List and Map? org.apache.struts.action2.Messages
http://people.apache.org/~mrdon/action2-api/org/apache/struts/action2/Messages.html
That doesn't reference either of those interfaces -- but I think the
JSTL behaves very unpredictably given objects that implement both
interfaces. I can't remember the specifics, but since the syntax for
indexing list elements as well as map keys is the same, it just
breaks down.
If I missed something, excuse me...
Joe
And of course we'd also provide the simpler JSP messages tags to
make that even easier. In fact, users of the UI tags won't ever
have to display messages, as they are generally handled by the
component templates.
Therefore, what we are doing here is optimizing for the most common
case, user sets messages and probably uses JSP components so they
are automatically displayed.
Don
Ian Roughley wrote:
I think this is ambiguous. In logging, you are always setting the
message. User farmiliar with log4j might think the methods below
are for setting error/messages/warnings and not obtaining them. I
think the getters and setters make more sense here.
/Ian
Eric Molitor wrote:
The new Messages API could easily be mapped onto an implementation
similar to that of Log4J. Why not embrace that idea and utilize
familiar methods to provide access.
such as...
msgs.info("some.key");
msgs.warn("some.warn.key");
msgs.error("some.error.key");
It does increase the number of methods but the argument is that the
familiarity outweighs the effort of adding those methods. By default
it only provides a small set of fixed levels, however custom levels
should be easy to implement. I would even argue having a limited set
of built in levels actually makes things easier for new developers.
There are a few APIs that are known to almost all developers. By
embracing a similar API a sense of familiarity is provided that should
ease adoption and understanding. That's my rational at least and it
usually serves me well.
Cheers,
Eric
On 5/4/06, Bob Lee <[EMAIL PROTECTED]> wrote:
I don't think it's a question of making things easier for the user or not
vs. our effort.
Are you saying you want arbitrary levels for messages (a la JSF)?
Bob
On 5/4/06, Don Brown <[EMAIL PROTECTED]> wrote:
Don Brown wrote:
> re-education of developers. I want Struts Action Framework 2
to be seen
> as easy and powerful, not just from a feature standpoint, but also
> migration, education, and "conceptual space" one.
I was talking to Eric on the ww dev chat, and he brought up a good point
that
resonated with me: we should be leveraging more known, common constructs
in
developing this API.
For example, the Messages object, rather than leverage the familiar Log
interface we all use every day. Messages are collected, much
like logging
messages and their levels are similar. Therefore, we'd have:
msgs.info("some.key");
msgs.warn("some.warn.key");
msgs.error("some.error.key");
We'd still keep the four different versions of the add function to handle
field
errors and parameters. Furthermore, Messages could implement Collection
and
Map, allowing it to be treated easily by existing tags and code built to
handle
these common constructs.
Yes, this adds more methods but the value to the developer, I think, is
worth
it. I'd rather error on the side of making our job harder than require
more
work and learning on the part of the end developer. Martin Fowler calls
it a
Humane Interface pattern [1], and while I don't completely
agree with that
pattern (78 methods for a List?!), I do think we should be designing from
the
standpoint of the end developer, not from the framework developer. Let's
make
Struts Action 2 powerful, easy, and even _intuitive_.
Don
[1] http://www.martinfowler.com/bliki/HumaneInterface.html
---------------------------------------------------------------------
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]
--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
