Maurice Lanselle wrote: > Ross Gardler said the following: > >Maurice Lanselle wrote: > > > >>I am trying to integrate another content type, one based on a > >>published document schema from a standards association (hr-xml.org). > > > > > >It would be better to do this as a plugin as it would be useful to a > >wider community. Are you using 0.7? If not you cannot build it as a > >plugin. I would recomend changing to 0.7 (it is stable enough being > >very close to a release). > > > >Building a plugin is really easy, see > >http://forrest.apache.org/0.7/docs/howto/howto-buildPlugin.html > > > I've just now read the docs on plugins you pointed to, and I understand > why you recommend that route. For various personal reasons, I'm waiting > for 0.7 distribution, and am not in a position to build from sources > myself. But it seems like my resume2document.xsl stylesheet could be > reused in an input plugin later without making changes, just packaging > it. Is that not true? > > >>However, it is not being transformed to xdoc; I think that I am > >>having trouble with the "sitemap.xmap" interception and would > >>appreciate clues as to how to get it right. I have simply copied the > >>"download" example and changed "download" to "resume" : > >> > >>> <map:pipeline> > >>> <map:match pattern="**Resume.xml"> > >>> <map:generate src="{project:content.xdocs}{1}Resume.xml" /> > >>> <map:transform > >>>src="{project:resources.stylesheets}/resume2document.xsl" /> > >>> <map:serialize type="xml"/> > >>> </map:match> > >>> </map:pipeline> > >> > >>However, when I try to use my test stylesheet as "resume2document", > >>"ResumeExample2.html" has no content. When I pull > >>"ResumeExample2.xml" in my browser, I get the raw untransformed xml > >>file. So it looks like my stylesheet is not being applied, because > >>my document is not matching the pattern. How should I fix my > >><map:pipeline> match in sitemap.xml? > > > > > >The pipeline above matches "**Resume.xml", your file is called > >"ResumeExample2.xml" which will not be matched. You need a match of > >"Resume*.xml". > > Okay, I was presuming that the matching was done on the document type, > not the file name. Indeed, that is straightforward to patch, and I can > now get my transform output rendered. Thank you very much! I can start > to make some progress on developing my transformation. > > >However, you should avoid limiting the URL space of your application > >by requiring a given file type to have a given filename or path. This > >can result in false matches. You should use the SourceTypeResolver, > >for an example of how see > >http://svn.apache.org/viewcvs.cgi/forrest/trunk/plugins/org.apache.forrest.plugin.input.simplified-docbook/input.xmap?view=markup > > > >for an example of how to do this. > > I totally buy your point about not requiring a document type to have a > given file name or path. Since I'm trying to use or produce xml files > which have the ".xml" extension rather than something more distinctive, > I would like Forrest to choose the stylesheet on the basis of the > doctype, perhaps using a catalog (like for resolving DTDs...why not > catalogs for xsl?). ...
No, the "catalog entity resolver" addresses a separate part of the issue. It sounds like we need to enhance the documentation. Source Type Resolver, actually called "SourceTypeAction (content aware pipelines)" [2] is one of the key features of Forrest and so we need to explain it better. Lets first correct your comment about "catalog". Its use is to create an efficient system for xml documents that declare a DTD so that the xml parser gets a local copy rather than going across the network. Now back to Source Type Action ... It is a Cocoon sitemap component that peeks at the top-part of a document to look for hints about the type of the document. [1] http://forrest.apache.org/docs/your-project.html#sitemap.xmap [2] http://forrest.apache.org/docs/cap.html These are the available methods: document-declaration document-element and namespace processing-instruction w3c-xml-schema If you use the first technique, then the parser needs to go retrieve the DTD from across the network. Hence the need for Catalog Entity Resolver. I don't use "w3c-xml-schema" so i am not sure if the parser is forced to locate the actual schema. I gather that it doesn't. Therefore you don't need to mess about with catalogs. Now if there are Java people out there listening, then perhaps you would like to enhance the Source Type Action to enable other methods. It is in the Forrest source at main/java/org/apache/forrest/sourcetype --David > ... It looks like that is what happens in the > <map:resources> group in the example you pointed me to (below). My > first attempt to *bend* it to my purpose failed, however: "Type > 'sourcetype' does not exist for 'map:pipeline' at..." when I replaced > > <map:pipeline> > <map:match pattern="**Resume.xml"> > by > <map:pipeline type="sourcetype" src="{src}"> > <map:select type="parameter"> > <map:parameter name="parameter-selector-test" > value="{sourcetype}" /> > <map:when test="Resume"> > > But one thing at a time...xslt first, then plugin/resolving. > > Many thanks, > Maurice
