"Craig R. McClanahan" wrote:
>
> Is it reasonable to create a Resources abstraction as you suggest, and
> still keep MessageResources as a specialized implementation of it (after
> refactoring)? In other words, Resources would only have getData(), but
> MessageResources would extend Resources and add the getMessage() methods.
>
I was going to suggest making MessageResources a wrapper if orthogonal
to Resources, but I like yours better if Resources is compatible.
geir
> Besides supporting backwards compatibility for Struts users :-), the
> formatting stuff performed by MessageResources is pretty useful in its own
> right.
>
> Craig
>
> On Mon, 18 Jun 2001, SCHACHTER,MICHAEL (HP-NewJersey,ex2) wrote:
>
> > I would like to commit the following changes to MessageResources,
> > if accepted:
> >
> > 1) Change the name of the MessageResources class to "Resource",
> > signifying that the implementations have the potential to
> > return more than just a short message String. This would also
> > include changing the name of MessageResourcesFactory to just
> > ResourceFactory.
> >
> > 2) Change the getMessage(xxx) methods to getData(xxx), and add
> > matching getDataStream(xxx) methods that return an InputStream as
> > opposed to a String
> >
> > Of course I'd also change the rest of the Resource package classes
> > to match the changes above so everything builds.
> >
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
