Subject: Re: Complex XSL Application (I think) From: "Wendy Cameron" <wendy.cameron@xxxxxxxxx> Date: Wed, 3 Mar 1999 08:43:29 +1000 |
Mark Wrote > There's nothing wrong with processing 1.6Gb files, it's just that you > don't want to do it every time someone wants to display a page! I > suggest you process it - but only in order to split it up! Wendy Wrote > Ultimately this problem has to be a database solution, but given your > comments on legacy systems, for now: > > 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. > > 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. > > 3. If possible place this data into a database for a nice fast search. > Sure, its not the full data, but it gives you a quick way in. > > 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.) > > 5. Generate HTML from the server to the user, for each employee, as > requested. > > 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. > > 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. > > Of course, in the future you could deliver that XML to the desktop, but > for now I think you - and those looking to you for their proof of > concept - need to be clear exactly where the real productivity gains are > going to come from, rather than saying 'here's a great technology, let's > put it on the desktop'. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Complex XSL Application (I thin, Alberto Gomez Corona | Thread | Re: Complex XSL Application (I thin, Wendy Cameron |
glyph-id, Elliotte Rusty Harol | Date | RE: CSS and XSL, Jelks Cabaniss |
Month |