struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Roughley <...@fdar.com>
Subject Re: [action2] Leveraging known constructs (was Public API first draft)
Date Fri, 05 May 2006 13:31:40 GMT
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 <crazybob@crazybob.org> 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 <mrdon@twdata.org> 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: dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>> >
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>

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


Mime
View raw message