On Jan 11, 2004, at 11:40 AM, Geoff Howard wrote:
Conal Tuohy wrote:
Mark, for one technique, see my message from about 12 hours ago ("sitemap
logic depending on pipeline content").
Whoa... yeah, I checked my mail folder for this list to look for replies to my question, but before I saw these, I saw this new thread "sitemap logic depending on pipeline content", which is exactly what I was asking. Freaky.
Aside from the technique in Conal's message, this is generally not possible.
I haven't read Conal's message yet, but that's next :-)
I thought of a way, which I haven't tried yet (or even actually written out until now). The idea is to have a stylesheet whose job is to return the contents of the stylesheet selected by the source tree. Assume that the source tree contains this element as a child of the root: "<style>foo.xsl</style>". Then in the sitemap:
<map:pipeline internal-only="true">
<map:match pattern="style-select/*.xsl">
<map:generate type="file" src="{1}.xml" />
<map:transform type="xslt" src="select-stylesheet.xsl" />
<map:serialize type="xml" />
</map:match>
...And, in select-stylesheet.xsl:
<xsl:template match="/">
<xsl:copy-of select="document(style)" />
</xsl:template>And, back in the sitemap:
<map:match pattern="*">
<map:generate type="file" src="{0}" />
<map:transform type="xslt" src="cocoon:/style-select/{0}.xsl" />
<map:serialize type="xml">
</map>My real problem is not as crude as having the source XML actually name its own stylesheet, but it's an equivalent problem— I need to figure out what XSL to transform with, based on information in the source tree.
You made a comment about design decisions regarding the sitemap and how those decisions are meant to serve "separation of concerns" (SoC is something I'm thoroughly in agreement with, BTW)... but your comment makes me wonder if I'm really going at this all wrong...
The same material that might be considered "styling" at one level might, of course, be considered "content" at another level or from a different reference point. The distinction is relative and extrinsic (based on function), not intrinsic (based on properties of the material itself). For instance, when looking at HTML+CSS, we regard the HTML as "the content", and the CSS as expressing the "styling". But when we're generating HTML from XML, we may think of the XML source as the true "content", which gets "styled" by transforming it through a "stylesheet". So for instance, when I generate an HTML <table> with rows and cells to display some stuff, that's not "content" at this level of looking it it — it's "style".
In the application I'm working on now, one of the things I need to be able to do is to send some customized email. So we have a template with some fixed content (text and imagery), and a few bits of content that are specific to the instance of the email. I have been thinking of the customization data as the real "content" — to me, all the rest of the email is just a template, and I don't give a hoot what it contains. So, I've been thinking that the email template would be a stylesheet that would be applied to my "content" (the customization data).
But another way to do it would be to consider the email template to be "content" as well, aggregating it together with the customization data and then transforming that through a stylesheet that combines them in the correct way.
I saw no reason why either of these approaches would be considered more "right" or idiomatic for Cocoon (remember, I'm pretty new to Cocoon), so I started pursuing the former approach because the nuts and bolts of the stylesheet are obvious (but then I'm left with this problem of how to select the stylesheet, which led to my original question).
But maybe I was wrong, and the latter approach is really more the "right way" to do it.
So at this point, I'd appreciate any feedback from those who have been around this block a time or two! :-)
You can "peek" into the intended source file with an action or flow,
The thought of writing an action for this had occurred to me. I haven't learned flow yet (though that is right around the corner).
or even possibly one of the xml-based input sources
Not sure what you mean... can you elaborate?
It's not that I'm trying to overwork the solution to my specific problem that prompted my request... it's more that I'm just trying to learn as much about Cocoon as I possibly can... :-)
In this whole Web world, Cocoon seems to me to be one of the (relatively) few things that's genuinely Worth Learning. Stuff like PHP, Perl, JSP don't have the same vibe for me. With those things, I just put in the minimum effort to get by and solve my immediate problem, but I have no desire to try and invest the time to "master" them. It just feels like... They Are Not Worthy :-). I don't get that feeling with Cocoon. Cocoon actually brings something to the table. It leaves you better than you were before. It has content that is rewarding to think about, for its own sake.
Well, I've mused long enough... back to work :-) ~ML
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
