forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <>
Subject Re: Avoiding fixed uri spaces (Re: [jira] Commented: (FOR-662) content-source-xml-link contract breaks 'forrest site')
Date Mon, 05 Sep 2005 00:56:43 GMT
On 9/4/05, Ross Gardler <> wrote:
> Tim Williams wrote:
>  > On 9/4/05, Thorsten Scherler <> wrote:
>  >
>  >>On Sun, 2005-09-04 at 04:51 +0200, Tim Williams (JIRA) wrote:
>  >>
>  >>>    [
> ]
>  >>>
>  >>>Tim Williams commented on FOR-662:
>  >>>----------------------------------
>  >>>
>  >>>A small portion of this remains unfortunately.  The current solution
> doesn't work for the plugin docs.  I think this source stuff needs some
> re-thinking unforunately.
>  >>
>  >>"The current solution doesn't work for the plugin docs."
>  >>
>  >>What do mean with that? Maybe the source should be resolved with the
>  >>mounting capability of the lm?
>  >
>  >
>  > Actually, you had just closed the issue and I commented that it's not
>  > totally resolved because our combined patches didn't work for
>  > pluginDocs since there is a separate sitemap entry for them.  I've
>  > since patched that too.  I don't immediately see how the locationmap
>  > stuff will fit here,  my comment about it needing some re-thinking is
>  > that these requests have to be modified per match and don't "grow"
>  > very well -- all unique matches need to account for these different
>  > formats (e.g. pluginDocs).
> Which part are you saying needs rethinking, I'm confused. There are two
> parts of the URI that we are fixing, the first is the "extensions" the
> second is the path to the file.
> The extensions (i.e. *.source.xml) is in line with the proopsal we
> discussed a long time ago and recently resurfaced in
> Do you
> see a problem with that proposal?
> The part about fixed paths in URI's (i.e. "pluginDocs/**") is a
> recognised problem that needs addressing.
> I believe the issue that arose because of the addition of the
> *.source.xml matchers is a result of the fixing og the path part of the
> URL, rather than a problem of the "extension" part.

It's the implementation of the extension (adding a new matcher or
ensuring that all matchers account for all the different "hints" that
I thought needed re-thinking.  Anyway, don't worry, the status qou
>  >   I still think there might be room for an
>  > enhanced Cocoon View in here - reacting to the "hint" in
>  > fname.hint.xml instead of the current request parameter.  I don't know
>  > though...
> If you can make Cocoon views work without the request parameter then
> this would work. Otherwise, it will be impossible to create a static
> site beause request parameters add an '?' to the URL which is not legal
> in a filename on disk. Unless you solve that problem you are on to a
> loser (I've tried it). 'm not saying it won't work, I'm saying there is
> a problem that needs to be addressed, I hope identifying the problem
> will save you some time in experimentation ;-)

I'm not constraining my thinking by the current Cocoon->View
implementation.  At the bottom of their own docs, they suggest that a
future possible view accessor might be to react on a URI exstension --
so why not our "hint" in fname.hint.xml? I don't have an itch to fix
this at the moment and I suppose that the in vogue thing is not to
have design debate on-list so I'll hush up until I have such an itch
-- with the latest patch it's working fine.

View raw message