Johan Compagner wrote:
yes, all those classes would be renamed. they really are not a resource abstraction, but a raw resource stream that can be used to build any resource abstraction.Ok that seems also fine to me.
So StringResource is now StringResourceStream?
Why is AbstractResource directly a IStringResource?
so that any resource can be turned into a string. this does look a little odd, but i think it maybe works... i wanted to be able to turn a FileResource, for example, into a string easily.
And we also have a AbstractStringResource that extends AbstractResource.
yeah, so this subclass is for abstract resources that /are/ strings (as opposed to resource that can be turned into strings).
And i find it strange that you can say asString() on a File or Url resource
Because that are mostly not strings but pure binair data.
sometimes they are binary. sometimes they are text. you should be able to asString() any resource if you want to.
i'm open to
the asString() should be overridden by the StringBufferResource and the StringResource
Becaue how it is done now is a bit overkill..
String->bytes->inputstream->StringReader->String....
yeah, that is pretty darn silly, isn't it. fixed. ;-)
johan
Jonathan Locke wrote:
i agree there is potential for some confusion here and would like to fix this.
the problem stems from the fact that IResource is completely generic (it's in util and could be used outside wicket) and Resource is a wicket core class designed for end-users of the framework. the intent of Resources is NOT to be a resource listener or locator. it is to be a resource and i really think that name should stick. i'd rather rename/hide IResource and AbstractResource than Resource/SharedResource/etc.
so how about this?
we move the methods from IResourceStream into IResource and then rename IResource to IResourceStream so that is all one big happy interface called IResourceStream. this interface makes pretty good sense since an IResource without a content type is not all that useful. if no content type is available for the IResourceStream, it could just return null. i think this is a LOT better than renaming Resource/WebResource/SharedResource, because these really are wicket framework resources and a different name will only confuse end-users about their intent. so IResourceStream would be about raw resource streams with a content type. given this, we simply rename AbstractResource to AbstractResourceStream.
sound good?
Johan Compagner wrote:
Hi,
I find the resources classes we have here in wicket very confusing..
Because we have a IResource interface. and a AbstractResource class which implement the interface
But we also have an abstract class Resource but that isn't a IResource but a IResourceListener.
This is a bit confusing naming.
I think the Resource class that has a method getResource() (that returns a IResource) is a ResourceLocator
So i think that the Resource class should be renamed to ResourceLocator and all subclasses like WebResource
and SharedResource should also be called: WebResourceLocator and SharedResourceLocator..
The problem is that we already have a ResourceLocator class... that also returns IResource objects..
So maybe Resource->ResourceHolder?
johan
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
