I have a patch cooking, that affects DynamicURI, RelativeDynamicURI and
ContentURI. I just wanted to ask feed back about it.
I arrived to this patch trying to solve the mess of different ways to
get internal URIs in Jetspeed.
While looking at Turbine's code, I noticed that DynamicURI,
RelativeDynamicURI and ContentURI had redundant code.
I also noticed that there are plans to use factories to deliver the
DynamicURI objects. This will make inconvenient inheriting from
DynamicURI, as it will be an interface and the factory code would be
messy again.
Thus, to simplify the code, I'm into:
- Add public methods toRelativeString(), toWebappRelativeString() and
getContentURI( path, absolute ) to DynamicURI
- Simplify and deprecate classes RelativeDynamicURI and ContentURI.
The idea is that once we have a DynamicURI, we can ask it to give us the
(absolute)URI string --> toString(), the (host)relative URI string -->
toRelativeString(), the (webapp)relative URI string -->
toWebappRelativeString(), or the translation of an argument path to an
absolute or webapp relative string (for images, static files, ...) -->
getContentURI( String path, boolean absolute).
When the new factory stuff in working, I think it is better to have a
simgle object to be produced by the factory than to have three of them.
Also, the internal workings of RelativeDynamicURI and ContentURI were
mostly redundant with code in DynamicURI.
I reorganized code internally in DynamicURI to have protected methods:
fillBase( StringBuffer ) --> scheme://host[:port]
fillRelative( StringBuffer ) --> /context/script/[screen...]
fillWebappRelative( StringBuffer ) --> /script/[screen...]
Those methods factor out the code, so that it only appears once in the
code base.
Problems, Ideas, things that do not fit?
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
