I just read the first part of your post (the simple one )... ;)
<xsl:template match="/">
<xsl:apply-templates select="field_definition"/>
</xsl:template>
<xsl:template match="field_definition">
<xsl:value-of select="/data/*[name()=current()/name]/>
</xsl:template>
On 01/02/06, Johnathon Wright <jw(_at_)llfitness(_dot_)com> wrote:
OK Here's my summary:
I want get the name of a field from the XML then test to see if that field
exists elsewhere in the XML and output the referenced field's data. In the
example below, I show the input XML and the output of the XML / XSLT merger.
XML:
<field_definition>
<name>username</name>
<type>text</type>
</field_definition>
<data>
<username>eattabasco</username>
<full_name>Johnathon Wright</full_name>
</data>
DESIRED OUTPUT:
username: johnathonwright
---------------------------------------------------------------
ALTERNATE SITUATION:
Changing the value of field_definition/name in the XML to "full_name", with
no change in the XSLT, should result in the following output:
full_name: Johnathon Wright
----------------------------------------------------------------
If that isn't clear, here is a more detailed explanation of what I'm trying
to do. I'm essentially asking the same question, just with more words and
examples:
To create and maintain our websites, we have a vast variety of data
(categories, products, features, etc.) Each type of data has an associated
XML generating file. Most XML is automatically generated as the direct
result of an SQL query. The same XML that is used with several different
XSLT templates. For instance, the XML behind the category page seen by the
public is the same XML behind the form that can edit the title, description,
or add subcategories for administrators. But I had to code all those
administrative forms individually and it was a pain.
In my new version, the XML includes information about the makeup of the data
(field name, max_length, field_type, etc.) This could mean a lot less XSLT
coding for me. I have actually gotten XSLT to create a blank form for adding
new users with this idea. If I change the data definition, the form would
change automatically. Now I want to use the same data to create the edit
screen. It's the same form as the add screen, but the fields are populated
(and of course primary keys are not editable.)
Because it would almost be a bigger pain, the XML to describe the form can
not contain the data that should populate the form. This schema isn't
finalized but as an example:
<define_form>
<form_name>Modify Users</form>
<data_type>user</data_type>
<instructions>blah</instructions>
...
<define_form>
<!-- now comes the list of fields -- many fields removed for brevity -->
<define_field>
<field_name>first_name</field_name>
<field_name_formatted>First Name</field_name_formatted>
<field_type>text</field_type>
<max_length>100</max_length>
</define_field>
<define_field>
<field_name>user_type</field_name>
<field_name_formatted>User Level</field_name_formatted>
<field_type>select</field_type>
<options>
<option>
<name>Customer</name>
<value>8</value>
</option>
<option>
<name>Seller</name>
<value>16</value>
</option>
<option>
<name>Administrator</name>
<value>32</value>
</option>
</options>
</define_field>
<!-- and the data to populate it. -->
<user>
<username>jw(_at_)llfitness(_dot_)com</username>
<first_name>Johnathon</first_name>
<last_name>Wright</last_name>
<user_type>032</user_type>
<last_login>2006-01-31 10:43:32</last_login>
<opt_in>0</opt_in>
</user>
So, to create the EDIT USER screen, I want the same form as the one I'm
using to add users. I need to run through (I'm not looping... I'm running
through :) ) each field. Then, I need to look to see if the data, which
would be in {define_form\data_type}\{field_name} exists. For first name, the
data would be in user\first_name. If it exists, display that field and set
the value. If not, don't display that field. (Maybe it's primary or this
user may not have permissions... )
If I can accomplish that, what I want to do next is to create a
"spreadsheet" display (I'm assuming not editable) given the form definition
above and a list of all relevant users... with an "edit" button next to
each, to link to the user edit form. Then I want to apply this to every type
of data I have. So if the fields changed I wouldn't have to re-code either
the add or the edit or the manage screens (for the admin site... the public
site would still be hand-coded.) That would be truly awesome. And
time-saving.
Can it be done?
My biggest concern is testing whether a field exists in the XML whose name
is determined by the XML... "This field uses the name "username", and it's
"user" data. Is there a "user"/"username" field in the XML? If so, what is
the value?"
Is this more clear? Is it a good idea?
Thanks,
Johnathon
Date: Tue, 31 Jan 2006 14:38:19 -0500
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
From: cknell(_at_)onebox(_dot_)com
Subject: RE: [xsl] Abstracting XSLT to generate multiple forms for the
same
data schema
Message-ID: <B0050176025(_at_)securemail(_dot_)onebox(_dot_)com>
The good news is that you most likely won't have to have "loops running
through seperate nodes" (an elementary school teacher once told me to
remember that there is "a rat" in separate).
The bad news is that your message isn't clear in regard to what you want.
If what you want is to revisit a node or set of nodes in your XML document
more than once with different output on each visit, investigate the "mode"
attribute on <xsl:template> and <xsl:apply-templates>.
"invariables" actually make things simpler in that they eliminate a group
of potential bugs caused by "side effects". All you have to do is un-learn
loops and learn apply-templates instead.
Give us a chance to help by being clear in what you need.
--
Charles Knell
cknell(_at_)onebox(_dot_)com - email
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--