You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Cyriaque Dupoirieux <Cy...@pcotech.fr> on 2007/03/21 10:01:52 UTC

Re: svn commit: r520650 - in /forrest/trunk/whiteboard/plugins: org.apache.forrest.plugin.input.doap/ org.apache.forrest.plugin.internal.dispatcher/ org.apache.forrest.plugin.output.solr/ org.apache.forrest.themes.core/themes/common/fo/ org.apache.forrest....

le 21/03/2007 00:17 rgardler@apache.org a écrit :
> Author: rgardler
> Date: Tue Mar 20 16:17:47 2007
> New Revision: 520650
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=520650
> Log:
> Enable *.vt.xml files to be located in the correct directory within themes.
>   
[...SNIP...]

> Modified: forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
> URL: http://svn.apache.org/viewvc/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/locationmap.xml?view=diff&rev=520650&r1=520649&r2=520650
> ==============================================================================
> --- forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/locationmap.xml (original)
> +++ forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/locationmap.xml Tue Mar 20 16:17:47 2007
> @@ -247,21 +247,21 @@
>              </select>
>          </match>
>          <!-- Structurer tiles - You can group elements to a template and call it from any view. -->
> -        <match pattern="resolve.tiles.**">
> +        <match pattern="resolve.tiles.**-*">
>              <select type="exists">
>                  <location 
> -                    src="{properties:resources}/themes/{properties:dispatcher.theme}/html/{1}.vt.xml" 
> +                    src="{properties:resources}/themes/{properties:dispatcher.theme}/{2}/{1}-{2}.vt.xml" 
>                      />
>                  <location 
> -                    src="{properties:resources}/themes/{properties:dispatcher.fallback.theme}/html/{1}.vt.xml" 
> +                    src="{properties:resources}/themes/{properties:dispatcher.fallback.theme}/{2}/{1}-{2}.vt.xml" 
>                      />
>                  <!--  plugin provided tiles -->
> -                <location src="{lm:resolvePluginTiles.{1}}" />
> +                <location src="{lm:resolvePluginTiles.{1}-{2}}" />
>                  <location 
> -                    src="{lm:dispatcher.themer}/themes/{properties:dispatcher.theme}/html/{1}.vt.xml" 
> +                    src="{lm:dispatcher.themer}/themes/{properties:dispatcher.theme}/{2}/{1}-{2}.vt.xml" 
>                      />
>                  <location 
> -                    src="{lm:dispatcher.themer}/themes/{properties:dispatcher.fallback.theme}/html/{1}.vt.xml" 
> +                    src="{lm:dispatcher.themer}/themes/{properties:dispatcher.fallback.theme}/{2}/{1}-{2}.vt.xml" 
>                      />
>              </select>
>          </match>
>   
Ok, that's nice,
Don't you think a pattern like :

<match pattern="resolve.*.tiles.*">
	<location src="{properties:resources}/themes/{properties:dispatcher.theme}/{1}/{2}.vt.xml"/>

...
Would be clearer ?

Or at least a pattern like the following to avoid to have the format in 
the tiles filename :

<match pattern="resolve.tiles.**-*">
  <select type="exists">
    <location src="{properties:resources}/themes/{properties:dispatcher.theme}/{2}/{1}.vt.xml" 


WDOT ?


Salutations,
Cyriaque

> Modified: forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.solr/locationmap.xml
> URL: http://svn.apache.org/viewvc/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.solr/locationmap.xml?view=diff&rev=520650&r1=520649&r2=520650
> ==============================================================================
> --- forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.solr/locationmap.xml (original)
> +++ forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.solr/locationmap.xml Tue Mar 20 16:17:47 2007
> @@ -42,10 +42,10 @@
>          <location src="{forrest:forrest.plugins}/org.apache.forrest.plugin.output.solr/resources/themes/{properties:dispatcher.fallback.theme}/{1}/{2}.{1}" />
>        </select>
>      </match>
> -    <match pattern="resolvePluginTiles.**">
> +    <match pattern="resolvePluginTiles.**-*">
>        <select type="exists">
> -        <location src="{forrest:forrest.plugins}/org.apache.forrest.plugin.output.solr/resources/themes/{properties:dispatcher.theme}/html/{1}.vt.xml" />
> -        <location src="{forrest:forrest.plugins}/org.apache.forrest.plugin.output.solr/resources/themes/{properties:dispatcher.fallback.theme}/html/{1}.vt.xml" />
> +        <location src="{forrest:forrest.plugins}/org.apache.forrest.plugin.output.solr/resources/themes/{properties:dispatcher.theme}/{2}/{1}-{2}.vt.xml" />
> +        <location src="{forrest:forrest.plugins}/org.apache.forrest.plugin.output.solr/resources/themes/{properties:dispatcher.fallback.theme}/{2}/{1-{2}}.vt.xml" />
>        </select>
>      </match>
>    </locator>
>
>
>
>   

Re: svn commit: r520650 - in /forrest/trunk/whiteboard/plugins: org.apache.forrest.plugin.input.doap/ org.apache.forrest.plugin.internal.dispatcher/ org.apache.forrest.plugin.output.solr/ org.apache.forrest.themes.core/themes/common/fo/ org.apache.forrest....

Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
> Cyriaque Dupoirieux wrote:
> 
>>> Having said that, building the doap docs should be a sufficient test, 
>>> as is the case with all plugins.
>> I think a specific target build.sh validation which will make a 
>> build.sh test + the generation of every plugins would be great to 
>> improve the test phase.
> 
> Some time ago I started along this line, but then got sidetracked an 
> never came back to it. In build.xml you will find the target below 
> (notice everything is commented out so it does nothing).

errr.... it did work once, honest. I don't commit stuf that is commented 
out ;-)

Ross

Re: svn commit: r520650 - in /forrest/trunk/whiteboard/plugins: org.apache.forrest.plugin.input.doap/ org.apache.forrest.plugin.internal.dispatcher/ org.apache.forrest.plugin.output.solr/ org.apache.forrest.themes.core/themes/common/fo/ org.apache.forrest....

Posted by Ross Gardler <rg...@apache.org>.
Cyriaque Dupoirieux wrote:

>> Having said that, building the doap docs should be a sufficient test, 
>> as is the case with all plugins.
> I think a specific target build.sh validation which will make a build.sh 
> test + the generation of every plugins would be great to improve the 
> test phase.

Some time ago I started along this line, but then got sidetracked an 
never came back to it. In build.xml you will find the target below 
(notice everything is commented out so it does nothing).

What we really need to do is use the plugins.xml files to define the 
list of plugins to be tested.

Ross

<target name="testPlugins"
           depends="cleanPlugins"
           description="Test each type of the plugin">
     <!--
       FIXME: these don't work as the compile stage executes since 
$java.dir = FORREST_HOME/main/java
       instead of PLUGIN_HOME/java
     <echo>=============================</echo>
     <echo>Testing using an input plugin</echo>
     <echo>=============================</echo>
     <ant 
antfile="${forrest.home}/plugins/org.apache.forrest.plugin.excel/build.xml" 
target="test">
       <property name="basedir" 
location="${forrest.home}/plugins/org.apache.forrest.plugin.excel"/>
     </ant>

     <echo>=============================</echo>
     <echo>Testing using an ouptut plugin</echo>
     <echo>=============================</echo>
     <ant 
antfile="${forrest.home}/plugins/org.apache.forrest.plugin.output.pdf/build.xml" 
target="test">
       <property name="basedir" 
location="${forrest.home}/plugins/org.apache.forrest.plugin.output.pdf"/>
     </ant>

     <echo>=============================</echo>
     <echo>Testing using an internal plugin</echo>
     <echo>=============================</echo>
     <ant antfile="${forrest.home}/plugins/IMSManifest/build.xml" 
target="test">
       <property name="basedir" 
location="${forrest.home}/plugins/IMSManifest"/>
     </ant>
     -->
   </target>



Re: svn commit: r520650 - in /forrest/trunk/whiteboard/plugins: org.apache.forrest.plugin.input.doap/ org.apache.forrest.plugin.internal.dispatcher/ org.apache.forrest.plugin.output.solr/ org.apache.forrest.themes.core/themes/common/fo/ org.apache.forrest....

Posted by Cyriaque Dupoirieux <Cy...@pcotech.fr>.
le 21/03/2007 11:45 Ross Gardler a écrit :
> Cyriaque Dupoirieux wrote:
>> le 21/03/2007 10:31 Ross Gardler a écrit :
>>> Cyriaque Dupoirieux wrote:
>>>> le 21/03/2007 00:17 rgardler@apache.org a écrit :
>>>>> Author: rgardler
>>>>> Date: Tue Mar 20 16:17:47 2007
>>>>> New Revision: 520650
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?view=rev&rev=520650
>>>>> Log:
>>>>> Enable *.vt.xml files to be located in the correct directory 
>>>>> within themes.
>>>>>   
>>>> [...SNIP...]
>>>>
>>>
>>> Also a good solution.
>>>
>>> I didn't want to mess with the structure of the pattern as I'm not 
>>> familiar enough with dispatcher to know what side effects this may 
>>> have. If you think it is safe to do this, then I agree bother are 
>>> better than the current implementation.
>>>
>>> I prefer the first option.
>> So do I.
>> I will make the update, may you check for the doap plugin please, I 
>> am not sure to be able to test it...
>
> See Thorstens response before making the changes. But, yes, I will 
> test the DOAP stuff. I'm active on a project using that at present so 
> I'll keep it up to date.
Too late, I have made the changes, but I will not commit.
>
> Having said that, building the doap docs should be a sufficient test, 
> as is the case with all plugins.
I think a specific target build.sh validation which will make a build.sh 
test + the generation of every plugins would be great to improve the 
test phase.

Cyriaque,
>
> Ross
>
>

Re: svn commit: r520650 - in /forrest/trunk/whiteboard/plugins: org.apache.forrest.plugin.input.doap/ org.apache.forrest.plugin.internal.dispatcher/ org.apache.forrest.plugin.output.solr/ org.apache.forrest.themes.core/themes/common/fo/ org.apache.forrest....

Posted by Ross Gardler <rg...@apache.org>.
Cyriaque Dupoirieux wrote:
> le 21/03/2007 10:31 Ross Gardler a écrit :
>> Cyriaque Dupoirieux wrote:
>>> le 21/03/2007 00:17 rgardler@apache.org a écrit :
>>>> Author: rgardler
>>>> Date: Tue Mar 20 16:17:47 2007
>>>> New Revision: 520650
>>>>
>>>> URL: http://svn.apache.org/viewvc?view=rev&rev=520650
>>>> Log:
>>>> Enable *.vt.xml files to be located in the correct directory within 
>>>> themes.
>>>>   
>>> [...SNIP...]
>>>
>>
>> Also a good solution.
>>
>> I didn't want to mess with the structure of the pattern as I'm not 
>> familiar enough with dispatcher to know what side effects this may 
>> have. If you think it is safe to do this, then I agree bother are 
>> better than the current implementation.
>>
>> I prefer the first option.
> So do I.
> I will make the update, may you check for the doap plugin please, I am 
> not sure to be able to test it...

See Thorstens response before making the changes. But, yes, I will test 
the DOAP stuff. I'm active on a project using that at present so I'll 
keep it up to date.

Having said that, building the doap docs should be a sufficient test, as 
is the case with all plugins.

Ross

Re: svn commit: r520650 - in /forrest/trunk/whiteboard/plugins: org.apache.forrest.plugin.input.doap/ org.apache.forrest.plugin.internal.dispatcher/ org.apache.forrest.plugin.output.solr/ org.apache.forrest.themes.core/themes/common/fo/ org.apache.forrest....

Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> Hmm, since we decided to change the name of tiles to panels (see the
> thread on dev) I did expect that this commit would have addressed this
> issue as well.
> 
> Let me explain why the commit is not really how we want it.
> 
> On Tue, 2007-03-20 at 15:50 +0000, Ross Gardler wrote: 
>> Why is common-fo.vt.xml in html directory rather than the fo directory?
> 
> This should go into the "panels" directory of the theme directory since
> it is an "old" tiles.
> 
> Panels do not care which contracts they contain. Meaning that for
> internal processing in the dispatcher pelt-css.vt.xml will not be
> treated different then common-fo.vt.xml. 
> 
> The fo/css in the naming only shows which aggregation of contract and
> hook (in short panel) are addressed.
> 
> Panels do not belong in the html nor in the fo nor in css nor in ....
> directory but in a directory on its on like e.g.
> themes/pelt/panels
> themes/common/panels
> 


That makes sense.

Ross

Re: svn commit: r520650 - in /forrest/trunk/whiteboard/plugins: org.apache.forrest.plugin.input.doap/ org.apache.forrest.plugin.internal.dispatcher/ org.apache.forrest.plugin.output.solr/ org.apache.forrest.themes.core/themes/common/fo/ org.apache.forrest....

Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2007-03-21 at 12:07 +0100, Cyriaque Dupoirieux wrote:
> le 21/03/2007 11:09 Thorsten Scherler a écrit :
> > Hmm, since we decided to change the name of tiles to panels (see the
> > thread on dev) I did expect that this commit would have addressed this
> > issue as well.
> >
> > Let me explain why the commit is not really how we want it.
> >
> > On Tue, 2007-03-20 at 15:50 +0000, Ross Gardler wrote: 
> >   
> >> Why is common-fo.vt.xml in html directory rather than the fo directory?
> >>     
> >
> > This should go into the "panels" directory of the theme directory since
> > it is an "old" tiles.
> >
> > Panels do not care which contracts they contain. Meaning that for
> > internal processing in the dispatcher pelt-css.vt.xml will not be
> > treated different then common-fo.vt.xml. 
> >
> > The fo/css in the naming only shows which aggregation of contract and
> > hook (in short panel) are addressed.
> >
> > Panels do not belong in the html nor in the fo nor in css nor in ....
> > directory but in a directory on its on like e.g.
> > themes/pelt/panels
> > themes/common/panels
> >   
> Humm, I agree with the definition of panels and with the fact that vt 
> should be changed.
> I don't see the benefit to store them in a specific directory, because I 
> have no example where a panel can be used for two different formats.

One can think of one, but you have a point that panels are likely to be
format dependent in their usage (not by definition).

> Why don't we name them with the .panel extension and store them in the 
> format directory ?

Imagine you have a bigger side and have heaps of panels, don't you think
that keeping them in the root folder of a theme (e.g. theme/common) can
become pretty messy?

> If we look at the css common directory we have a mix of different kind 
> of files :
> theme/common/css
>   |-- basic.css                           (a real source file to be used 
> as it is)
>   |-- branding-generic-css.ft      (a contract...)
>   |-- ...
>   |-- profiling.css.xslt                 (a stylesheet - which I'm not 
> sure is very useful...)
>   |-- ...
> 
> It doesn't strike me to have panels in there :
>   |-- common.panel
> 

That mean we would introduce another extension that we need to add to
the svn configs. I would rather use *.panel.xml.

wdyt?

salu2

-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java & XML                consulting, training and solutions


Re: svn commit: r520650 - in /forrest/trunk/whiteboard/plugins: org.apache.forrest.plugin.input.doap/ org.apache.forrest.plugin.internal.dispatcher/ org.apache.forrest.plugin.output.solr/ org.apache.forrest.themes.core/themes/common/fo/ org.apache.forrest....

Posted by Cyriaque Dupoirieux <Cy...@pcotech.fr>.
le 21/03/2007 11:09 Thorsten Scherler a écrit :
> Hmm, since we decided to change the name of tiles to panels (see the
> thread on dev) I did expect that this commit would have addressed this
> issue as well.
>
> Let me explain why the commit is not really how we want it.
>
> On Tue, 2007-03-20 at 15:50 +0000, Ross Gardler wrote: 
>   
>> Why is common-fo.vt.xml in html directory rather than the fo directory?
>>     
>
> This should go into the "panels" directory of the theme directory since
> it is an "old" tiles.
>
> Panels do not care which contracts they contain. Meaning that for
> internal processing in the dispatcher pelt-css.vt.xml will not be
> treated different then common-fo.vt.xml. 
>
> The fo/css in the naming only shows which aggregation of contract and
> hook (in short panel) are addressed.
>
> Panels do not belong in the html nor in the fo nor in css nor in ....
> directory but in a directory on its on like e.g.
> themes/pelt/panels
> themes/common/panels
>   
Humm, I agree with the definition of panels and with the fact that vt 
should be changed.
I don't see the benefit to store them in a specific directory, because I 
have no example where a panel can be used for two different formats.
Why don't we name them with the .panel extension and store them in the 
format directory ?
If we look at the css common directory we have a mix of different kind 
of files :
theme/common/css
  |-- basic.css                           (a real source file to be used 
as it is)
  |-- branding-generic-css.ft      (a contract...)
  |-- ...
  |-- profiling.css.xslt                 (a stylesheet - which I'm not 
sure is very useful...)
  |-- ...

It doesn't strike me to have panels in there :
  |-- common.panel

Salutations,
Cyriaque,

> salu2
>
> On Wed, 2007-03-21 at 10:49 +0100, Cyriaque Dupoirieux wrote:
>   
>> le 21/03/2007 10:31 Ross Gardler a écrit :
>>     
>>> Cyriaque Dupoirieux wrote:
>>>       
>>>> le 21/03/2007 00:17 rgardler@apache.org a écrit :
>>>>         
>>>>> Author: rgardler
>>>>> Date: Tue Mar 20 16:17:47 2007
>>>>> New Revision: 520650
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?view=rev&rev=520650
>>>>> Log:
>>>>> Enable *.vt.xml files to be located in the correct directory within 
>>>>> themes.
>>>>>   
>>>>>           
>>>> [...SNIP...]
>>>>
>>>>         
>>> Also a good solution.
>>>
>>> I didn't want to mess with the structure of the pattern as I'm not 
>>> familiar enough with dispatcher to know what side effects this may 
>>> have. If you think it is safe to do this, then I agree bother are 
>>> better than the current implementation.
>>>
>>> I prefer the first option.
>>>       
>> So do I.
>> I will make the update, may you check for the doap plugin please, I am 
>> not sure to be able to test it...
>>
>> Salutations,
>> Cyriaque,
>>
>>     
>>> Ross
>>>
>>>
>>>       

Re: svn commit: r520650 - in /forrest/trunk/whiteboard/plugins: org.apache.forrest.plugin.input.doap/ org.apache.forrest.plugin.internal.dispatcher/ org.apache.forrest.plugin.output.solr/ org.apache.forrest.themes.core/themes/common/fo/ org.apache.forrest....

Posted by Thorsten Scherler <th...@apache.org>.
Hmm, since we decided to change the name of tiles to panels (see the
thread on dev) I did expect that this commit would have addressed this
issue as well.

Let me explain why the commit is not really how we want it.

On Tue, 2007-03-20 at 15:50 +0000, Ross Gardler wrote: 
> Why is common-fo.vt.xml in html directory rather than the fo directory?

This should go into the "panels" directory of the theme directory since
it is an "old" tiles.

Panels do not care which contracts they contain. Meaning that for
internal processing in the dispatcher pelt-css.vt.xml will not be
treated different then common-fo.vt.xml. 

The fo/css in the naming only shows which aggregation of contract and
hook (in short panel) are addressed.

Panels do not belong in the html nor in the fo nor in css nor in ....
directory but in a directory on its on like e.g.
themes/pelt/panels
themes/common/panels

salu2

On Wed, 2007-03-21 at 10:49 +0100, Cyriaque Dupoirieux wrote:
> le 21/03/2007 10:31 Ross Gardler a écrit :
> > Cyriaque Dupoirieux wrote:
> >> le 21/03/2007 00:17 rgardler@apache.org a écrit :
> >>> Author: rgardler
> >>> Date: Tue Mar 20 16:17:47 2007
> >>> New Revision: 520650
> >>>
> >>> URL: http://svn.apache.org/viewvc?view=rev&rev=520650
> >>> Log:
> >>> Enable *.vt.xml files to be located in the correct directory within 
> >>> themes.
> >>>   
> >> [...SNIP...]
> >>
> >
> > Also a good solution.
> >
> > I didn't want to mess with the structure of the pattern as I'm not 
> > familiar enough with dispatcher to know what side effects this may 
> > have. If you think it is safe to do this, then I agree bother are 
> > better than the current implementation.
> >
> > I prefer the first option.
> So do I.
> I will make the update, may you check for the doap plugin please, I am 
> not sure to be able to test it...
> 
> Salutations,
> Cyriaque,
> 
> >
> > Ross
> >
> >
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java & XML                consulting, training and solutions


Re: svn commit: r520650 - in /forrest/trunk/whiteboard/plugins: org.apache.forrest.plugin.input.doap/ org.apache.forrest.plugin.internal.dispatcher/ org.apache.forrest.plugin.output.solr/ org.apache.forrest.themes.core/themes/common/fo/ org.apache.forrest....

Posted by Cyriaque Dupoirieux <Cy...@pcotech.fr>.
le 21/03/2007 10:31 Ross Gardler a écrit :
> Cyriaque Dupoirieux wrote:
>> le 21/03/2007 00:17 rgardler@apache.org a écrit :
>>> Author: rgardler
>>> Date: Tue Mar 20 16:17:47 2007
>>> New Revision: 520650
>>>
>>> URL: http://svn.apache.org/viewvc?view=rev&rev=520650
>>> Log:
>>> Enable *.vt.xml files to be located in the correct directory within 
>>> themes.
>>>   
>> [...SNIP...]
>>
>
> Also a good solution.
>
> I didn't want to mess with the structure of the pattern as I'm not 
> familiar enough with dispatcher to know what side effects this may 
> have. If you think it is safe to do this, then I agree bother are 
> better than the current implementation.
>
> I prefer the first option.
So do I.
I will make the update, may you check for the doap plugin please, I am 
not sure to be able to test it...

Salutations,
Cyriaque,

>
> Ross
>
>

Re: svn commit: r520650 - in /forrest/trunk/whiteboard/plugins: org.apache.forrest.plugin.input.doap/ org.apache.forrest.plugin.internal.dispatcher/ org.apache.forrest.plugin.output.solr/ org.apache.forrest.themes.core/themes/common/fo/ org.apache.forrest....

Posted by Ross Gardler <rg...@apache.org>.
Cyriaque Dupoirieux wrote:
> le 21/03/2007 00:17 rgardler@apache.org a écrit :
>> Author: rgardler
>> Date: Tue Mar 20 16:17:47 2007
>> New Revision: 520650
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=520650
>> Log:
>> Enable *.vt.xml files to be located in the correct directory within 
>> themes.
>>   
> [...SNIP...]
> 
>> Modified: 
>> forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/locationmap.xml 
>>
>> URL: 
>> http://svn.apache.org/viewvc/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/locationmap.xml?view=diff&rev=520650&r1=520649&r2=520650 
>>
>> ============================================================================== 
>>
>> --- 
>> forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/locationmap.xml 
>> (original)
>> +++ 
>> forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/locationmap.xml 
>> Tue Mar 20 16:17:47 2007
>> @@ -247,21 +247,21 @@
>>              </select>
>>          </match>
>>          <!-- Structurer tiles - You can group elements to a template 
>> and call it from any view. -->
>> -        <match pattern="resolve.tiles.**">
>> +        <match pattern="resolve.tiles.**-*">

...

>>   
> Ok, that's nice,
> Don't you think a pattern like :
> 
> <match pattern="resolve.*.tiles.*">
>     <location 
> src="{properties:resources}/themes/{properties:dispatcher.theme}/{1}/{2}.vt.xml"/> 
> 
> 
> ...
> Would be clearer ?

Agreed.

> Or at least a pattern like the following to avoid to have the format in 
> the tiles filename :
> 
> <match pattern="resolve.tiles.**-*">
>  <select type="exists">
>    <location 
> src="{properties:resources}/themes/{properties:dispatcher.theme}/{2}/{1}.vt.xml" 
> 
> 
> WDOT ?

Also a good solution.

I didn't want to mess with the structure of the pattern as I'm not 
familiar enough with dispatcher to know what side effects this may have. 
If you think it is safe to do this, then I agree bother are better than 
the current implementation.

I prefer the first option.

Ross