Re: [xsl] Abstracting XSLT to generate multiple forms for the same

[António Mota <amsmota@xxxxxxxxx>]

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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx</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@xxxxxxxxxxxxxxxxxxxxxx
> > From: cknell@xxxxxxxxxx
> > Subject: RE: [xsl] Abstracting XSLT to generate multiple forms for the
> > same
> > data schema
> > Message-ID: <B0050176025@xxxxxxxxxxxxxxxxxxxxx>
> >
> > 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@xxxxxxxxxx - email