cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rice Yeh" <rice...@gmail.com>
Subject Re: [RT] Do we need URL/Source in SSF?
Date Sat, 29 Mar 2008 01:51:40 GMT
Hi,
  I have a guts feeling that Spring's Resource and ResourcePatternResolver
have similar functions as Source and SourceResolver, hence we could just
depend on Spring's Resource to achieve the same functionality in SSF.

Regards,
Rice

On Sat, Mar 29, 2008 at 5:48 AM, Grzegorz Kossakowski <grek@tuffmail.com>
wrote:

> Hi guys,
>
> The discussion initiated by rather *technical* question about JNet
> integration with SSF turned into
> heated discussion on whether standard URL API is capable enough to replace
> Excalibur's
> Source/SourceFactory interfaces. Actually, it was Rainer Pruy who gave a
> nice summary[1] of
> discussed aspects up to now.
>
>
> Even though, it's real fun to see interesting solutions like one proposed
> by Sylvain[2] I'm still
> rather interested in that particular COCOON-2176[3] problem at the moment
> as it blocks any out of
> Cocoon world SSF usage.
>
>
>                                              --- o0o ---
>
>
> Right from the beginning of my playings with JNet and URL replacement for
> SourceResolver I had
> constant feeling that something is stinky about the approach I taken.
> That's been reflected in bunch
> of dirty hacks in first, prototype implementation of JNet integration.
>
>
> I've taken a closer look at our current Source interface usage pattern.
> Obviously, started with
> blockcontext source that I'm mostly interested in at the moment and seen
> something like this in
> BlockContextSourceFactory:
>
>             String blockContext = (String) blockContexts.get(blockName);
> [...]
>
>             // construct the path relative the block context
>             String resolvedPath = blockContext + path;
>
> [...]
>
>             resolver = (SourceResolver) this.serviceManager.lookup(
> SourceResolver.ROLE);
>             return resolver.resolveURI(resolvedPath);
>
>
> Some comments explaining what's happening here. If you try to resolve
> blockcontext:/myBlock/path it
> will obtain blockContext from Map of contexts. This map contains base URLs
> for corresponding blocks.
> Current implementation allows file: and jar: protocols.
>
> As you see, BlockContextSourceFactory returns Source implementations of
> protocols that have
> _nothing_ to do with BlockContextSource. Let's have a look at how resolved
> source is used (in
> ServletFactoryBean):
>
>
>           source = resolver.resolveURI(contextPath);
>           contextPath = source.getURI();
>
> Where contextPath contains "blockcontext:/myBlock/path" at the beginning
> of processing. It's clear
> now, that ServletFactoryBean is interested only in String representation
> of base URL (Source) and
> nothing else.
>
>
> Don't you think that is little bit weird that following instructions:
>
>       contextPath = "blockcontext:/myBlock/path";
>       source = resolver.resolveURI(contextPath);
>       contextPath = source.getURI();
>
> Will result with "file://.../myBlock/path" stored in contextPath instead
> of original
> "blockcontext:/myBlock/path"?
> I think that contract of URL/SourceFactory should be to to act as identity
> transform when above code
> is being executed. I mean, returned URL/Source instance should always be
> implementing the protocol
> we asked for.
>
> Do you agree?
>
>
>                                              --- o0o ---
>
>
> My conclusion is that SSF exploits semantics of Source/SourceFactory
> interfaces for resolving
> *expressions*. My view on "blockcontext:/myBlock/path" is that we deal
> with an expression that
> should be resolved to real URL with real protocol implementation
> available.
>
>
> Having said all of this I would like to propose treating strings in
> contextPath attribute as
> expressions and using cocoon-expression-language-api module for resolving
> them. Then
> cocoon-servlet-service-components could provide implementation of
> blockcontext expression language
> that would use blockContext Map for resolving expressions to real base
> URLs.
>
>
> This way we can get rid of dependency on CocoonSourceResolver and
> Excalibur in one go. Moreover, it
> means that SSF won't mess with URL/Source handling anymore which was my
> intention right from the
> beginning. I think such functionality is far from SSF scope and should be
> implemented elsewhere,
> probably as a Spring AOP's /around advice/ so you could get more
> fine-grained control in which
> servlets you want to have extended URL support.
>
>
> WDYT?
>
> [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/77432
> [2] http://article.gmane.org/gmane.text.xml.cocoon.devel/77352
> [3] https://issues.apache.org/jira/browse/COCOON-2176
>
> --
> Grzegorz Kossakowski
>

Mime
View raw message