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]