> -----Original Message-----
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 09, 2002 3:27 PM
> To: Struts Developers List
> Subject: Re: commons.resources.messages
>
>
> I want to use it with my business classes so they can pass
> messages back
> to the presentation tier. I started by passing back flat
> messages, but
> found I also wanted a category. In this case, the category relates to
> the name of a field that failed a business tier validation.
> In a Struts
> environment, the field is represented by a property on a
> bean. But from
> the business classes perspective, it is a field.
>
> Besides fields, you might also use it to group other types of
> information together. Each property could be a question on a
> questionnaire, and each message a response to the question.
> And so forth.
>
> In general, I would cast it as a flavor of data transfer object. You
> could use it custom tags and JavaBeans. But someone else
> could also use
> it with Velocity or XLS or whatever.
>
> The underlying idea is the messages often need to be grouped
> together or
> targeted in some way, and the Messages container gives you
> a way to do
> that.
OK. I'm sold on calling it a 'category' or 'group'.
The GLOBAL_MESSAGE constant should probably become something like
NO_CATEGORY or UNCATEGORIZED.
Actually, it might be nice if the use of this constant could be made
invisible to the client - that is, the client uses 'null' to mean "no
specific category/group". Internally, Messages would still have to use a
constant, since that's needed for a key into the Map. An additional add()
method would be required:
public void add(Message message)
but I think that would be useful in any case. Currently, I find it mildly
annoying to have to say:
add(ActionMessages.GLOBAL_MESSAGE, message);
instead of just:
add(message);
and have the implementation "do the right thing".
>
> Another point is that it also provides functionality that a
> simple Hash
> Map does not, since you can have multiple messages related to
> a specific
> [property,topic,subject,category]. So, it we were to place it
> someplace
> else, I'd suggest Collections. I believe add could just as
> well take an
> Object.
I think it would be a tough sell to the Collections crew ;-} so maybe we
should put it into Resources for now and maybe come back to the location
question later.
--
Martin Cooper
>
> Basically, it's a container that let's you "pigeon hole"
> entries using
> arbitrary categories.
>
> -T.
>
>
> Martin Cooper wrote:
>
> >
> >>-----Original Message-----
> >>From: Ted Husted [mailto:[EMAIL PROTECTED]]
> >>Sent: Monday, September 09, 2002 2:01 PM
> >>To: Struts Developers List
> >>Subject: Re: commons.resources.messages
> >>
> >>
> >>The JavaDocs talk about "beans" and "properties", but that
> >>seems to be
> >>just nomenclature. The ActionMessages container doesn't seem
> >>linked to
> >>JavaBeans in any specific way. The Strut's framework associates the
> >>message categories with bean properties, but that's just one
> >>potential use.
> >>
> >
> > I kind of agree, but for one thing. In my own mind, I can't
> come up with a
> > good explanation (excepting beans) of why I would want to
> have a collection
> > of messages in which each message could be associate with a
> particular
> > property name, or with some non-specific name. In other
> words, I can't
> > imagine what the Javadoc for this class is going to say
> regarding why I
> > would ever want to use it.
> >
> > That seems to suggest, to me at least, that either the
> class really does
> > need to be associated with beans, or what we have now is
> not sufficiently
> > generic to be useful elsewhere. Or that I have a poor
> imagination. ;-}
> >
> > --
> > Martin Cooper
> >
> >
> >
> >>The cleanest thing might be to update the JavaDocs and
> >>statics to remove
> >>the Struts references, import it to Commons resources, and do any
> >>additional refactoring there. Then, post 1.1, we can bring
> >>the Commons
> >>version back in again (which now seems to be SOP).
> >>
> >>-Ted
> >>
> >>Martin Cooper wrote:
> >>
> >>
> >>>I don't see a reason that ActionMessage needs to be in
> >>>
> >>Struts, since it's
> >>
> >>>really just a way to group the key with the intended
> >>>
> >>placeholder values.
> >>
> >>>Moving it to Resources seems like a minimal extension of
> >>>
> >>that component's
> >>
> >>>scope.
> >>>
> >>>I'm a little less sure about ActionMessages. I don't think
> >>>
> >>it necessarily
> >>
> >>>needs to stay in Struts, but it does have a clear linkage
> >>>
> >>to beans, since
> >>
> >>>the 'property' of an ActionMessages entry refers to a bean
> >>>
> >>property. As a
> >>
> >>>result, it's not so clear to me that it's a good fit for Resources.
> >>>
> >>>I'd almost be tempted to put (Action)Message in Resources and
> >>>(Action)Messages (perhaps as PropertyMessages) in BeanUtils.
> >>>
> >>>While we're on the subject, another point was brought up
> >>>
> >>recently regarding
> >>
> >>>ActionMessage(s) (and ActionError(s)), which I have also
> >>>
> >>run afoul of. The
> >>
> >>>issue is that these classes do not allow the association of
> >>>
> >>a bundle with
> >>
> >>>the message key. This is most commonly a problem with the
> >>>
> >>collections of
> >>
> >>>messages, since there is no way to build up a collection of
> >>>
> >>messages which
> >>
> >>>contain keys which refer to different bundles.
> >>>
> >>>There are several ways that this could be addressed, and
> >>>
> >>not all of them
> >>
> >>>require changes to these classes. However, it's an issue
> >>>
> >>worth considering
> >>
> >>>if we're also considering moving these classes elsewhere.
> >>>
> >>>--
> >>>Martin Cooper
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Ted Husted [mailto:[EMAIL PROTECTED]]
> >>>>Sent: Monday, September 09, 2002 8:45 AM
> >>>>To: [EMAIL PROTECTED]
> >>>>Subject: commons.resources.messages
> >>>>
> >>>>
> >>>>Would there be any objections to contributing the ActionMessage/s
> >>>>classes to the Commons Resources package (as Message and
> >>>>
> >>Messages, or
> >>
> >>>>equivalent).
> >>>>
> >>>>I'm starting to use the properties field on the message more
> >>>>often, and
> >>>>would like to pass this back from the business tier. I'd
> rather not
> >>>>import the Struts class or replicate the class structure, for
> >>>>the usual
> >>>>reasons.
> >>>>
> >>>>It seems like it would be a good fit for the Commons Resource
> >>>>package,
> >>>>and I'd be happy to bring it over.
> >>>>
> >>>>I brought it up here first in case there was any reason for
> >>>>keeping it
> >>>>only the Struts codebase. Of course, I am not suggesting we
> >>>>
> >>move any
> >>
> >>>>Struts dependencies at this time.
> >>>>
> >>>>-Ted.
> >>>>
> >>>>
> >>>>--
> >>>>To unsubscribe, e-mail:
> >>>><mailto:[EMAIL PROTECTED]>
> >>>>For additional commands, e-mail:
> >>>><mailto:[EMAIL PROTECTED]>
> >>>>
> >>>>
> >>>
> >>>--
> >>>To unsubscribe, e-mail:
> >>>
> >><mailto:[EMAIL PROTECTED]>
> >>
> >>>For additional commands, e-mail:
> >>>
> >><mailto:[EMAIL PROTECTED]>
> >>
> >>>
> >>
> >>--
> >>Ted Husted, Husted dot Com, Fairport NY US
> >>co-author, Java Web Development with Struts
> >>Order it today:
> >><http://husted.com/struts/book.html>
> >>
> >>
> >>--
> >>To unsubscribe, e-mail:
> >><mailto:[EMAIL PROTECTED]>
> >>For additional commands, e-mail:
> >><mailto:[EMAIL PROTECTED]>
> >>
> >>
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
> >
>
>
> --
> Ted Husted, Husted dot Com, Fairport NY US
> co-author, Java Web Development with Struts
> Order it today:
> <http://husted.com/struts/book.html>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
