struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <mr...@twdata.org>
Subject Re: [action2] Leveraging known constructs (was Public API first draft)
Date Fri, 05 May 2006 14:57:40 GMT
Joe Germuska wrote:
> 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 

Try 
http://people.apache.org/~mrdon/action2-api-don/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.

That may be and if true, would be a good reason not to try this, since 
ease of use in JSTL is one of the key drivers.

Don

> 
> 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 <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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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