-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How about event-driven templates à la XSLT? #1
Comments
When I first started this, it was to marry XSLT with Tiddlywiki, but I abandoned that, because between <$xpath> and all of tiddlywiki's powers, there wasn't much more needed for xslt. I think you can implement something like xsl:apply-template using a simple design paradigm. I'll describe how I'd implement it, and you let me know whether it works for you, doesn't work, or how tw5-xml should better address it. I'll count on your input, because for me, if I get around to using <xsl: apply-template> when using XSLT, I've already descended into insanity, and my memory of the events will be hazy at best. Let's say we've got a D&D schema which has a block like this: <character>
<name>Higgins</name>
<class>Rogue</class>
...
</character> This block can show up all over your schema, either under Now I'm rendering this xml document in a tiddler. ! <$xpath value-of="@title" />
!!! Players
<$xpath for-each="/DnD/players">
<$xpath for-each="character">
<!-- Render my character -->
</$xpath>
</$xpath>
!!! Places
<$xpath for-each="/DnD/location">
!!!! People leaving in <$xpath value-of="@name" />
<$xpath for-each="character">
<!-- Render my character... again -->
</$xpath>
</$xpath> It's wasteful, so I'd make a template tiddler for character:
Then,
We're partway there, but what if we have other schema blocks, like
...all over my code. So I define a tag and a field. Here is my new Templates/Character:
Then I define a global macro:
Now let's look at my main tiddler again:
Voila! apply-templates is emulated through tags. I can add new templates using the [[XSLT Template]] tag, or another one, and manage other blocks of schema. I've attached an XML tiddlybundle which includes the sample tiddlers I made to make sure this works. Just drag it onto the tw5-xml demo site, and you'll see. I added another template and an example XML just to show it off. (Github wouldn't let me upload an XML for some reason. So you need to change its extension to XML before you can drag it) Does this work for you? tw5-xml could be expanded to include the macro perhaps, but there are so many subtle ways to implement this design pattern that I felt it was better to leave it up to the user. Your thoughts? |
Hi @flibbles, thank you! I tested your solution: it does work wonderfully and I think you should include it as an example of advanced use of the widget. Still, with |
Are you saying the problem with it is with a situation like this?
You can't process those internal elements in the order they appear. You can only process all the items first, then skills, or vice versa? Is that what you're saying? Also, in the future, I recommend you feel free to create a new comment after you've finished testing. I was not notified when you edited your existing comment, which is why I've ignored you all month. |
Exactly that. It is more obvious with a typical XML document (as opposed to XML data):
If one says:
(S)he can't make the macro apply to the sections in the expected order, and then to the paras in the expected order.
Oops, apologies! I didn't think of that :-( |
Hi Flibbles,
As you know, I'm a big fan of this plugin already. The one thing that I'm missing as of 1.0.1 is the ability for the
<$xpath>
widget to choose a template based on the current path, as would XSLT do with<xsl:apply-templates>
.It is currently quite difficult to process an XML chunk whose schema allows several distinct subpaths at a given XML node: revealing nested
<$xpath>
s based on a subpath value doesn't seem impossible with the help of a few variables and some TW5 core widgets, but it would be suboptimal to say the least.I suggest that in a future version, a mecanism is added to allow the registration of templates based on an xpath string (like
<xsl:template>
in XSLT), so that<$xpath>
can choose one of these templates based on the current node it is in.Thanks again!
Xavier.
The text was updated successfully, but these errors were encountered: