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