Here is what I'm talking about:
http://people.apache.org/~mrdon/action2-api-don/org/apache/struts/action2/Messages.html
This approach has the advantages of closely following the familiar Log
interface, and by leveraging the List and Map interfaces, makes it easy
to manipulate and access data from any tag or expression language that
supports collections. On the other hand, it doesn't support arbitrary
message types, and would require a number of methods in an
implementation class. This is what I meant when I said this approach
favors end user convenience over framework developer maintenance. I'm
not saying the List and Map interfaces are better designed than what we
could come up with here, but they are what developers know and feel
confortable with, so perhaps we should leverage that.
Personally, I've never had a need for any other types of messages other
than info, warn, and error, but I could be in the minority here.
Don
Bob Lee 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]
