On 9/4/05, Ross Gardler <[EMAIL PROTECTED]> wrote: > Tim Williams wrote: > > On 9/4/05, Thorsten Scherler <[EMAIL PROTECTED]> 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
