Vadim Gritsenko wrote:
URL interpretation
?
SourceResolver and company
It proved to be very valuable extension point
I'm not negating that, however the way it is currently implemented makes
it difficult to use at times. Again there are different ways of
skinning this particular cat that would be more efficient.
I do recall why we didn't try to use Java's own URL "component"
framework. It really wasn't due to complexity of getting the
URLStreamHandlers to communicate with Cocoon. It was due to the fact
that some web containers like BEA WebLogic and IBM WebSphere preset the
static instance of URLStreamHandlerFactory, making it impossible for us
to override it. I don't recall if we tested extending where the
URLStreamHandlers are located using the "|java.protocol.handler.pkgs"
system property.
The advantage of using Java's extension mechanism here is that we would
be able to use our cocoon:// URLs inside of FOP and any other library
that relies on URLs. If we don't rely on components for the core of
Cocoon, then we have more flexibility on improving this point.
|
It is very simplistic view of the world to declare that only P/G/T
deserve to be components. I'd even go as far as claim that P/G/T are
implemented by cocoon users the *least* often compared to other
interfaces.
Well, as da Vinci said, "Simplicity is the ultimate sophistication".
The key point of the decomponentization process is to reduce the
number of extension points to the absolute practical minimum.
By being brave about what we leave out, it forces us to think
differently about other aspects of the system. I'm thinking way
forward here.
Just don't throw out baby in the heat of fight for simplification :)
Right. Although just because something is an extension point does not
mean it has to necessarily be a component.
