forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: url based structurer from plugins
Date Fri, 19 Jan 2007 00:31:18 GMT
On Thu, 2007-01-18 at 11:39 +0100, Thorsten Scherler wrote:
> On Thu, 2007-01-18 at 09:19 +0000, Ross Gardler wrote:
> > Thorsten Scherler wrote:
> > > The ultimate changes in the dispatcher have been mainly allowing plugins
> > > to provide dispatcher based resources by ad.
> > > 
> > > We now support:
> > > - contracts
> > > - x (tiles)
> > > - resources
> > > 
> > > I think we should allow url related structurer as well. 
> > > 
> > > Meaning e.g. the solr plugin could provide via
> > > resources/structurer/url/solr-search-adv.fv 
> > > an advanced search form. 
> > > 
> > > One could then use it in the project like
> > > http://localhost:8888/solr-search-adv.html and it would match the
> > > default implementation if no project one can be found.
> > > 
> > > wdyt?
> > 
> > There is precedent for this in various plugins (including projectInfo).
> > 
> > If possible, I'd recommend making the URL configurable from the 
> > locationmap just in case there is ever a clash with a users urlspace.
> 
> Yeah, about the url space:
> What I recommend is:
> Index: org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
> ===================================================================
> --- org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
> (revision 497342)
> +++ org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
> (working copy)
> @@ -228,6 +228,8 @@
>              project-based theme-based = directory-based /
> parent-directory based (recursively) -->
>                      <location src="{uri}" />
>                  </act>
> +                <!--  plugin provided Structurer -->
> +                <location src="{lm:resolvePluginStructurer.{1}}" />
>                  <!-- themes-dir: project-application-based
> theme-dir-based -->
>                  <location
> src="{lm:themer.project.dir}/{properties:dispatcher.theme}{properties:dispatcher.theme-ext}"
> 
> The downside is that an user would need to provide his own
> implementation on the used url structurer if he does not want to use the
> plugin structurer.
> 

Actually the major concern to above patch is that it will match to late.
The downside statement above would not happen. Only if we add the match
directly after the url-based matches.

Let me explain. It is coming after the project-based theme-based =
directory-based / parent-directory based (recursively) action. Meaning
as soon you have a structurer in either the structurer url dir or
[depreciated] xdocs dir. The url provided by the plugin would not work
anymore since the locationmap will return a match before it checks the
plugin location.

Current default matching (if not overridden by project implementations)
will search:

1) url-based -
{properties:resources}/structurer/url/{1}{properties:dispatcher.theme-ext}

e.g. structurer/url/index.fv will match server/index.*. 

Which leads me to a sharp corner of current implementation. The
structurer does not has to provide a definition for the requested
format. The natural thing would be to check whether this structurer can
handle the format and if not then the locationmap should keep on
checking. 

Right now the consequence is that I needed to do 
http://svn.apache.org/viewvc?view=rev&rev=496014 for the pelt.fv what
does not feel right.

2) project-based url-based (xdocs location)  [depreciated]
{properties:content.xdocs}{1}{properties:dispatcher.theme-ext}
same as above but in the xdocs dir. 

3) resourceType based - checks against a resource type structurer
implementation present. If you have a faq page and you want a different
design then you can implement a specific structurer for it. 

4) RecursiveDirectory - inherit theme specific structurer.
5) as 4) in [depreciated] location
6) <location src="{uri}" />
7) themes-dir: project-application-based theme-dir-based 
{lm:themer.project.dir}/{properties:dispatcher.theme}{properties:dispatcher.theme-ext}
Project based implementation of the core themes plugin
8) themes-dir: project-application-based default 
{lm:themer.project.dir}/{properties:dispatcher.fallback.theme}{properties:dispatcher.fallback.theme-ext}
as in 7) but for the default theme
9) themer: forrest-application-based theme-based 
{lm:dispatcher.themer}/themes/{properties:dispatcher.theme}{properties:dispatcher.theme-ext}
default themer plugin theme specific
10) themer: forrest-application-based default 
{lm:dispatcher.themer}/themes/{properties:dispatcher.fallback.theme}{properties:dispatcher.fallback.theme-ext}
as in 9) but for the default theme

Writing this list, should we reduce it and add documentation how to
implement the rest in project specific settings?

With the suggested patch the count goes to 11. Way to much IMO.

WDYT?

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)



Mime
View raw message