[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Let's face it: side effects are sometimes necessary!

Subject: Let's face it: side effects are sometimes necessary!
From: Gunther Schadow <gunther@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 02 Dec 2002 16:37:46 -0500
face from side
Hi,

sorry to bother you with this. We can make it short or long
(easy or painful ;-)

Short form:

I used to use <xsl:variable ...> elements on the toplevel of an
XSLT transform for their side-effects. The xsl:variable/@select
would call into some extension function, that would set up
some static data (initializations) of some gizmo.

I know side-effects are evil, but the real world sometimes needs
those (refer to the Long form of my question :-).

With Saxon 6 this worked well. Saxon 7 is somewhat optimized
as to evaluate global variables on demand rather than statically.
I appreciate the value of what Michael was doing here. And I
am happy to use some other mechanism for static initializations
at start up of a template -- if there is any means left.

I could only think of one: use the document root template. However,
I'd like to NOT do that because it would cause my transforms to
no longer be mixable & matchable as they would now rely on some
explicit flow as to which root node template is actually visited
when. This is IMHO worse than some special form on the toplevel
that one could use to cause immediate evaluation of variables.

I am thinking of:

<xsl:variable name="gizmo" saxon:eval-immediately="yes"
   xmlns:g="java:my.package.Gizmo"
   select="g:new($gizmoInitializationParameter)"/>


Long form:


I spare you this :-) Suffice it to say that I need to use these
side-effects because of an anomaly that you XSLT designers have
introduced, i.e, you don't allow variables inside template
match patterns. I don't blame you, but if you take out these
anomalies for you, you must be prepared to allow for people's
work-arounds to work :-).

I am very well aware of the fact that these things may cause
pain and suffering in non-sequential (parallel, threaded)
templates processing. So far this isn't an issue for me because
I don't have multi-threaded templates processors (and I would
hope that those would take advice in the form of what may
or may not be parallelized.) Also, I suppose that variables in
match patterns would solve most of my needs for my hacks,
so, I want to be a pure and good guy if you let me :-).


thanks, -Gunther


PS: I'm trying to figure out if the lazy-evaluation can be turned off in Saxon 7 and if I do, I'll make myself a little extension attribute to do that (and will ask Michael to add that switch into his code ... let's see if it's doable.)

--
Gunther Schadow, M.D., Ph.D.                    gschadow@xxxxxxxxxxxxxxx
Medical Information Scientist      Regenstrief Institute for Health Care
Adjunct Assistant Professor        Indiana University School of Medicine
tel:1(317)630-7960                         http://aurora.regenstrief.org



XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.