Avoiding fixed uri spaces (Re: [jira] Commented: (FOR-662) content-source-xml-link contract breaks 'forrest site')

[Ross Gardler <rg...@apache.org>]

Tim Williams wrote:
 > On 9/4/05, Thorsten Scherler <th...@apache.org> wrote:
 >
 >>On Sun, 2005-09-04 at 04:51 +0200, Tim Williams (JIRA) wrote:
 >>
 >>>    [ 
http://issues.apache.org/jira/browse/FOR-662?page=comments#action_12322601 ]
 >>>
 >>>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 
http://marc.theaimsgroup.com/?l=forrest-dev&m=112550194621801&w=2 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.

 >   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 ;-)

Ross

Re: Avoiding fixed uri spaces (Re: [jira] Commented: (FOR-662) content-source-xml-link contract breaks 'forrest site')

[Ross Gardler <rg...@apache.org>]

Tim Williams wrote:
> On 9/4/05, Ross Gardler <rg...@apache.org> wrote:
> 

...

>>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.  

Yes, I thought so. This is caused by the fixing of the path part, 
imagine that if there was no special matcher for the 
"pluginDocs/index.xml" file in the sitemap. In this case there would be 
no need for the new matcher for "pluginDocs/index.source.xml" since it 
would have been matched by the catch-all "**.source.xml".

If we remove the need to fix the path (using the locationmap?) then the 
problem does not exist and the hints in the URL are OK (at least I think 
so).

> Anyway, don't worry, the status qou
> works.

For now...

>> >   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 see. OK, we know what to consider if this raises its ugly head again.

> 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.

:-))

I think we ought to focus on removing the fixed paths first, maybe that 
itch will never arrive.

Ross

Re: Avoiding fixed uri spaces (Re: [jira] Commented: (FOR-662) content-source-xml-link contract breaks 'forrest site')

[Tim Williams <wi...@gmail.com>]

On 9/4/05, Ross Gardler <rg...@apache.org> wrote:
> Tim Williams wrote:
>  > On 9/4/05, Thorsten Scherler <th...@apache.org> wrote:
>  >
>  >>On Sun, 2005-09-04 at 04:51 +0200, Tim Williams (JIRA) wrote:
>  >>
>  >>>    [
> http://issues.apache.org/jira/browse/FOR-662?page=comments#action_12322601 ]
>  >>>
>  >>>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
> http://marc.theaimsgroup.com/?l=forrest-dev&m=112550194621801&w=2 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
works.
 
>  >   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.
--tim