Followup:
I did not read ALL the documentation.... the API has an
extended example showing how to do this:
Add the following parameters:
<map:parameter name="nsmapping" value="mapping.proeprties"/>
<map:parameter name="nsmapping-reload" value="false"/>
And in the "mapping.proeprties" file (which you create, for example,
in the same location as the sitemap), simple add a line:
xy=http://www.mynamespace.com
and change the xpath to:
<map:parameter name="xpath" value="/xy:article/title"/>
And voila!
Derek
PS My only complaint (!?) is that the above example should
be in the main docs, not just (only) in the API.
PPS we really need a "best practice guide" page for how to work
with XML files - e.g. extract & load data - along with many other
such guides, I guess. Sigh. Cocoon and the sad state of its
documentation seems like its always going to be an ongoing issue!
>>> [EMAIL PROTECTED] 2005/05/11 08:57:40 AM >>>
Marc
Thanks for the heads-up! This seems to work... sort of.
For files like this:
<article>
<title>My first article!</title>
</article>
the extraction:
<map:parameter name="xpath" value="/article/title"/>
works just fine.
But, in my case, I have files with namespaces:
<xy:article xmlns:xy="http://www.mynamespace.com"/>
<title>My first article!</title>
</xy:article>
and then the above xpath does not work .. neither does:
<map:parameter name="xpath" value="/xy:article/title"/>
I could not see anything in the docs that refers to this
http://cocoon.apache.org/2.1/userdocs/generators/xpathdirectory-generator.html
Any ideas?
Thanks
Derek
>>> [EMAIL PROTECTED] 2005/05/10 05:12:40 PM >>>
Hello,
i had pretty much the same problem, a large number of small files to
aggregate, and i finally found the xpathdirectorygenerator, which is
pretty straightforward to use, doesn't have the caching issues of
document() function, and is faster than the technique of xinclude and
cinclude on a large number of files.
Hope this help,
Marc
Derek Hohls a �crit :
>Chris
>
>Yes... the CInclude transformer output isn't cached, and I have
>found that the approach you suggested is only marginally faster
>than using the xinclude approach I had adopted originally.
>
>I guess that working with information from numerous XML files
>on disc is not really a viable operation using Cocoon... which is,
>I think, a pity.
>
>In my case its impossible to predict when content can be changed...
>could be a whole lot of changes in a few minutes, and then
>nothing for a few months. This makes it very hard to simply set
>a time parameter as suggested in the documents. There needs to
>be something a little more straightforward than that to make it
>usable/useful.
>
>Any more thoughts?
>
>Derek
>
>
>
>>>>[EMAIL PROTECTED] 2005/05/07 04:17:27 AM >>>
>>>>
>>>>
>I misspoke in my last email (actually, mis-wrote :)
>The CInclude transformer output isn't, by default, cached, but the
>input
>to it, "cocoon:/101.meta.xml", below, would be. In your case, where
>you
>have fifty or so inputs of that form, that's what you'd want. However,
>
>you can also get the CInclude transformer to cache its output, as
>described here:
>http://cocoon.apache.org/2.1/userdocs/transformers/cinclude-transformer.html#Caching
>
>
>
>I agree when you said "surely its Cocoon's "job" to check ....", but
>I've gotten myself into a bit of a mess, with lots of these cached
>pipeline fragments daisy-chained. I've also implemented "preemptive
>caching" on some of them, and now I just haven't spent the time to dig
>
>in and see where the cache isn't getting properly invalidated.
>
>Cheers!
>
>Derek Hohls wrote:
>
>
>
>>Chris(?)
>>
>>Thanks - I will give this a try (cannot be slower than what I have
>>now and looks pretty straightforward). It had not occurred to me
>>because it seemed this would require 50+ calls to the same
>>pipeline.. instead of just one pass through one... but I'll check.
>>
>>Re the caching - surely its Cocoon's "job" to check the files
>>being used (if they are static, as in this case) and send through
>>the latest version... but I will run some tests and see what occurs.
>>
>>Thanks
>>Derek
>>
>>
>>
>>
>>
>>>>>[EMAIL PROTECTED] 2005/05/06 02:44:53 PM >>>
>>>>>
>>>>>
>>>>>
>>>>>
>>Is the XPath expression the same in every case ("//inml:ind/meta")?
>>If so, then it would be easy to switch to using CInclude, which is
>>cached:
>>
>> <file name='101.xml'>
>> <ci:include src='cocoon:/101.meta.xml'/>
>> </file>
>>
>>And then define a new pipeline to produce 101.meta.xml:
>>
>> <map:match pattern='*.meta.xml'>
>> <map:generator src='{1}.xml'/>
>> <map:transform src='pull-out-ind-meta.xslt'/>
>> <map:serialize>
>> </map:match>
>>
>>I'm pretty new to Cocoon, actually, and I've been using this
>>
>>
>technique
>
>
>>a
>>lot,
>>for example, to generate my nav bar. I'm not altogether happy with
>>
>>
>it,
>
>
>>though,
>>mainly because I can't figure out how to control the cache -- i.e. to
>>
>>
>
>
>
>>make sure
>>that it gets invalidated whenever {1}.xml changes. But, it's pretty
>>fast.
>>
>>
>>Derek Hohls wrote:
>>
>>
>>
>>
>>
>>>I am looking to find a way to speed up a key step in a pipeline:
>>>
>>>The one in question has the following steps:
>>>
>>><map:match pattern="ind-list">
>>><map:parameter name="handler" value="myindhandler"/>
>>><map:generate src="inds" type="directory" include="*.xml"/>
>>><map:transform src="stylesheets/ind/ind-xincludes.xsl" >
>>> <map:parameter name="ind-dir" value="inds"/>
>>></map:transform>
>>><!-- *NOW SLOW* -->
>>><map:transform type="xinclude"/>
>>><map:serialize type="xml"/>
>>></map:match>
>>>
>>>The pipeline is fast up to the end of the first transform,
>>>resulting in XML which contains a number of tags of
>>>the form:
>>>
>>><file name="101.xml">
>>><xi:include
>>>href="inds/101.xml#xmlns(inml=http://www.myschema.com)xpointer(//inml:ind/meta)"/>
>>></file>
>>>
>>>The number of tags varies by directory, but is typically about 50.
>>>The files themselves are small - about 50k - and the "meta"
>>>tags have only a few bytes of text.
>>>
>>>However, this last step takes over a minute! on a fast server
>>>(2Gb memory, 3Ghz processor)...
>>>
>>>What can I do to ensure that this is speeded up significantly...?
>>>ie at least a factor of 10!
>>>
>>>Thanks
>>>Derek
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>>
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
