On 5/9/06, Mark Williams <mark(_at_)gwsmartmove(_dot_)co(_dot_)uk> wrote:
I've googled and searched the archives and from what I have understood
(which is little), it seems that what I want to do may not be possible.
Hopefully I have misunderstood and someone is able to help.
We're building an online form constructor. It constructs a web page of
edit controls based on a specification contained in an xml file. Once
the user has completed the required fields and clicked submit, it
constructs an xml file which is then passed for rendering together with
the necessary xsl.
Ok, so to keep it seperated in my head:
xml + xslt -server-side processing-> html page -generates xml file->
xml file + xsl-server side processsing-> pdf? There's still some very
vague spots in the whole process.
The online form constructor provides a number of checkbox options as to
what the user will require in their finished form. This could be a list
of a number of items.
I looked over your example and I've more or less given up. The whole
thing feels like a bad design decision, but so little is given of
actual examples of your code there isn't much I can do. It seems like
you are trying to do the following but I can't be sure.
Now, I'm going to give a quick summary of what your data might be
like..I don't care about the steps inbetween.
The first xml doc gives of options to choose from:
and there is a process by which a user chooses these options and
produces a new xml file...they get something like:
Now for some reason you want to refer back to the order of choices,
which doesn't make a lot of sense to me (wouldn't it be simplier to
display information about the choices choosen, what does order have to
do with it)?
Notice something here, I'm not talking about incrementing. Type "c"
only has an artifical relationship with the number 3. It's 3 in the
first list, but 2 in the second. But what it seems like you're really
asking for is, what is the position of this type of element in the
original list. To rephrase this, as mentioned in a couple of other
recent threads, you can say, what is the number of preceeding siblings
of the element. This would translate to something like... ( didn't
check it, wrote it in a hurry so be careful)
running this stylesheet like the following against the second xml:
<xsl:variable name="type" select="@type" />
<xsl:variable name="options" select="document('options.xml')/ops" />
<xsl:value-of select="count($options/op[(_at_)type=$type]/preceding::*) + 1"
The position of option of type a in the original set of ops, and the
position of option of type c in the original set of ops.
Notice I don't need a for loop or anything like that, just a reference
list. To tell the truth, there's many other approaches to the problem
you could have taken. Can't go into too much detail, but you could
create the styelsheet via another processes that takes into account
the options choosen. You can simply read in the first xml doc along
with the generated xml doc to get the information. You can change it
so there's a more logical mapping of options to the results.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>