Subject: Re: Complex XSL Application (I think) From: "Wendy Cameron" <wendy.cameron@xxxxxxxxx> Date: Wed, 3 Mar 1999 09:02:39 +1000 |
Apologies all about the last two emails the email system here is very archaic and I my control key was stuck so when I pressed enter it sent. [Mark] > 1. Split the 1.6Gb file into a file for each person. If you can generate > it again this way from the legacy system then that would be quicker, > otherwise run XSL on the file to get the smaller files. [Wendy] Ok this is fine i need to do this anyway. But how? -First step How do I have a server side XML and XSL processor given Microsoft has withdrawn MSXSL and MSXML Is there something currently that I can load on the server and use to do this type of work. -Second Step Within the XSL how do I create new persistant files. [Mark] > 2. Run XSL on the file again to create a much smaller file that > 'indexes' into these new files. Each node would have the security ID, > person's name and the file-name of the employee XML file. [Wendy] Again this is good I need to do this But I would prefer to create the index from all the smaller files because if the data was processed from the system into 160,000 seperate files I dont have one large file to produce an index from. So I guess im asking how do I do load SOMEDRIVE:\*.xml In an XSL stylesheet [Mark] > 4. If not possible, then you could search it server-side with XSL, > although it is still going to be a fair size. (Even better, index this > file with an indexing server.) [Wendy] Like this idea of Index server however there is a problem with what if the files are on a tape? [Mark] > I think this last point is quite important, and I agree with James's > comments on this. It is still proof of concept to do this, because you > have generated thousands of pages very easily. However, if that was all > you did, it wouldn't look that different to what you could do with ASP > or some such. But ... if you add to the stylesheet clever processing of > other bits of an employee's XML file, such as a pointer to their manager > (I assume it's in there if you have 10k on each person!), or their > department, or something. That really does show the advantage of XSL. > Creating HTML links to other data from what is a data connection is > impressive stuff, and makes for a very easy to maintain system; all you > do is add a little rule to work on a database object, rather than > hacking into an ASP file and embedding script inside a load of HTML. [Wendy] Id like to see examples of what your discussing here Will need to do this i think for general ledger. The employee data is of employees that have been with QR for 10 years or more and have all of their leave records in it etc [Mark] > Another little feature to add would be a couple of icons on the HTML > version of the employee page for things like 'view printable version of > this employee's details', and 'email these details'. This neatly shows > the advantages of using different stylesheets. [Wendy] Yes we want to do this but we are looking for an elegant way to distinguish the printing format to the screen format without writing two separate templates for the two veiws. Examples are good if you have any XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Complex XSL Application (I thin, Wendy Cameron | Thread | RE: Complex XSL Application (I thin, Kay Michael |
Re: Complex XSL Application (I thin, Wendy Cameron | Date | contents-alignment, Elliotte Rusty Harol |
Month |