XSLT: Newbie needs help please.

[Frank O'Hara]

Hello, I'm very new to XML/XSLT but from what I've seen I really like
it.
I've decided to give XML/XSLT a try for some new development work to
see if it will simply things going forward.

I'm building a 'report generation wizard' for an in-house
application. There isn't much to is but it's meant to help users
walk
through the process a little. I'd like to represent the report
generation data (and C# object) using XML so we can use the model for
our other implementations and just modify the XSLT each time.


The page basically has a few drop down lists, some report filters and
an execute button. The drop down lists are dependent on one another
to an extent. The selection from the first, Report Category (RC),
drives the data from the second, Report Type (RT), which ultimately
determines which filters (FTR) are available and also drives a 3rd
drop down list, Output Format (OF).


The code in the page manages the population of this data dynamically
using XMLHTTP and users have the option to save their report
generation templates for future use. These templates can be edited
at
a later time and herein lies my problem,.


I'm going to have a ReportTemplate class that is going to be
represented by XML. The idea is that when a user wants to edit their
template the XML will just be loaded and transformed into the wizard.
Only the values for RC,RT,FTR,OF are going to be contained in the XML
document.


So my question is, how do I populate my drop down lists? I was
thinking about putting all the options from the drop down lists in
the
XML document and having the ones that belong to the ReportTemplate
class have an attribute "Selected=true" but I don't like that idea
because then the XML document contains information about the
implementation. The other idea was to populate the drop down lists
before transforming the XML and just using the XML data to determine
which value to 'select' in the drop down lists.


Is there a 'standard' method for doing this? The idea is to make the
solution as generic as possible so that this XML/XSLT can be used for
other implementations where things may be slightly different.


Thanks,
Frank

 

[Joseph Kesselman]

thinking about putting all the options from the drop down lists in
the
XML document and having the ones that belong to the ReportTemplate
class have an attribute "Selected=true" but I don't like that idea

If code/stylesheet can recognize the relevant elements in order to
toggle that attribute, it could also recognize them in order to copy
only those into the page as shown to the user, right?

 

[Frank O'Hara]

True but I guess what I'm asking is should my XML file contain ALL the
values for a given drop down list and have the 'Selected' attribute
for the one that has been selected or should the XML file ONLY contain
the data that is relevant to what the data is describing (say for
example, ReportType) and then have the stylesheet manage the
'selection' process given that all the options of the drop down list
are already populated?

So basically I'm asking if my XML should be structured as;

1) Containing all the values for the drop down list:
....
<ReportType Selected="true">Periodic</ReportType>
<ReportType>Status</ReportType>
<ReportType>General</ReportType>
....

or

2) Containing only the value that represents the object I'm trying to
represent.
....
<ReportType>Periodic</ReportType>
....

Again, I'm trying to determine this in terms of marking up an XML
document using XSLT. Normally I would only use the values that
describe the data for my XML but given that this is going to be marked
up I was wondering what the accepted/normal practice was.

Thanks,
Frank

 

[Simon Brooke]

True but I guess what I'm asking is should my XML file contain ALL the
values for a given drop down list and have the 'Selected' attribute
for the one that has been selected or should the XML file ONLY contain
the data that is relevant to what the data is describing (say for
example, ReportType) and then have the stylesheet manage the
'selection' process given that all the options of the drop down list
are already populated?

Does the thing that's doing the generating know what the current value is?
My guess (from doing similar things myself) is that it does. If so,
pragmatically it may as well generate it, because it's certainly simpler
to do it there. Providing, of course, your XML is not supposed to conform
to some schema which would outlaw it.

It's pretty difficult for the transform to know which value should be
selected if the XML being transformed doesn't say.

 

[Frank O'Hara]

Simon,

The generator will 'know' which the current value is.

My preference is that I'd like to get my XML to be generic and
represent only the object itself (without all the possible values) so
that it can be used in other applications/implementations. I feel
that having all the possible values for a given drop down box ties the
XML to the implementation.

As for the transform knowing which value to select, the XML file will
have the value of the item from the list that is meant to be selected,
it just won't have all the items for the drop down list, so what I'm
wondering is can the drop down list be populated first and then the
transform will read the 'selected' value from the XML?

Thanks,
Frank

 

[Simon Brooke]

Simon,

The generator will 'know' which the current value is.

My preference is that I'd like to get my XML to be generic and
represent only the object itself (without all the possible values) so
that it can be used in other applications/implementations. I feel
that having all the possible values for a given drop down box ties the
XML to the implementation.

As for the transform knowing which value to select, the XML file will
have the value of the item from the list that is meant to be selected,
it just won't have all the items for the drop down list, so what I'm
wondering is can the drop down list be populated first and then the
transform will read the 'selected' value from the XML?

Yes, it can. XSL is wonderful for manipulating documents. It's not the
easiest or most perspicuous language...

There's an alternative you might consider, though. Since the generator
knows the current value, have the generator generate a 'dirty' XML, and
have a separate XSL transform which generates 'clean' XML from the 'dirty'
XML. The 'dirty' XML is then never seen outside your system - any foreign
system which requests your XML sees the 'clean' version.

There are two reasons for doing it this way:

(i) it's often easier
(ii) XSL - particularly if you have to parse each document before
transforming it - can be compute-heavy.

If you are generating and transforming, a pattern I would commend to you is
to do your transform on the DOM object you've created in memory, not write
it out to file and then parse it in again - that is /hugely/ expensive.


--
(e-mail address removed) (Simon Brooke) http://www.jasmine.org.uk/~simon/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GP/CS s++: a++ C+++ ULBVCS*++++$ L+++ P--- E+>++ W+++ N++ K w--(---)
M- !d- PS++ PE-- Y+ PGP !t 5? X+ !R b++ !DI D G- e++ h*(-) r++ y+++
------END GEEK CODE BLOCK------

 

[Timothy Murphy]

Simon Brooke wrote:

If you are generating and transforming, a pattern I would commend to you
is to do your transform on the DOM object you've created in memory, not
write it out to file and then parse it in again - that is /hugely/
expensive.

I'm not sure how you do this.
Do you have any code to show the idea in action?

 

[Joe Kesselman]

I'm not sure how you do this.
Do you have any code to show the idea in action?

If you're using the Java TRaX/JAXP APIs to invoke the XSLT processor,
just feed the processor a DOMSource wrapped around your DOM, rather than
a StreamSource. Caveat: Make sure you are using a proper
Level-2-or-later namespace-aware DOM, as processors may not handle
non-namespace-aware nodes correctly.

(I fought for making old nodes forward-compatable when we were working
on DOM Level 2, but the formal definitions played a trump card...
Standard reminder to *NEVER* use the old createElement/createAttribute
methods, ALWAYS use createElementNS/createAttributeNS, even for nodes
that are being left in the no-namespace namespace.)