forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@apache.org>
Subject Re: dependency on project symbols file (Was: svn commit: r632740)
Date Tue, 04 Mar 2008 00:17:57 GMT
Thorsten Scherler wrote:
> Thorsten Scherler wrote:
> > David Crossley wrote:
> ...
> > > Drat, i spent so much effort and thought that i had
> > > a robust solution whereby they didn't need one.
> > > 
> > > Obviously my tests were not thorough.
> > > 
> > > I revert ASAP.
> > 
> > Is there not a way to have:
> > > > We need to find a way that if that file is not in the project the
> > > > default is used and no error is caused. 
> 
> As far as I understand it (no time to test ATM) the following is causing
> it:
> 
> > Modified:
> > forrest/trunk/main/webapp/resources/schema/catalog.forrest.xcat
> > URL:
> > http://svn.apache.org/viewvc/forrest/trunk/main/webapp/resources/schema/catalog.forrest.xcat?rev=632740&r1=632739&r2=632740&view=diff
> > ==============================================================================
> > --- forrest/trunk/main/webapp/resources/schema/catalog.forrest.xcat
> > (original)
> > +++ forrest/trunk/main/webapp/resources/schema/catalog.forrest.xcat
> > Sun Mar 2 03:22:23 2008
> > @@ -52,6 +52,8 @@
> > <!-- Sets of symbols. e.g. for string replacements -->
> > <public publicId="-//Apache Forrest//ENTITIES Symbols Core v1.0//EN"
> > uri="entity/symbols-core-v10.ent"/>
> > + <public publicId="-//Apache Forrest//ENTITIES Symbols Project
> > v1.0//EN"
> > + uri="entity/symbols-project-v10.ent"/>
> > <!-- Various other resources -->
> > <public publicId="-//Apache Forrest//ENTITIES Skin Configuration
> > common plugins V0.7-1//EN"
> > uri="entity/skinconf-common-plugins-07-1.xml"/>
> 
> Where the entity/symbols-project-v10.ent will always be resolved
> relative to the project (and not to the above file).

No. What the above means is that i configured the core
to have a project symbols file. If they over-ride that in
their project's xml catalog they can supply their own file.

> Makes me think
> whether "cocoon://entity/symbols-project-v10.ent" would not work?

The catalog system above should work properly. Not sure if our
entity resolver would understand the "cocoon:" protocol.
Also the xml catalogs could not then be used in other tools
such as xml editors.

Your idea might work instead of using the resolver to locate
those entities in the declaration of the main sitemaps:
main/webapp/sitemap.xmap
whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/internal.xmap

Another solution would be to put an empty symbols-project-v10.ent file directly
at the "main/webapp" directory. When the catalog resolver cannot find
a particular resource, then the default place to look is alongside
the file that tried to include this resource, e.g. main/webapp/sitemap.xmap
However that is not an elegant solution.

Anyway, i will revert now and investigate this FOR-1071.

> > Your solution is a very nice demonstration how to use entities for this
> > common problem. It would be a shame to not find the last piece of the
> > puzzle.
> > 
> > I need to have a look again on your commits.

Yes it is nice. We should have made more use of the
xml framework ages ago.

-David

Mime
View raw message