Re: XML stuff (was: UKHA Classified update - SQL Hel p!)

[graham@xxxxxxx]

BUTLER, Tony, FM writes:

> This is how it works:
> Client clicks URL
> Web Server retrieves XML data set from App Server which retrieves from
SQL
> Server
> (Traditionally, WS retrieves ADO data set from App server.....)
> Web Server does the XSLT Transformation & passes a web page back
to the
> client.
> If you can guarantee the version of the browser the client is using
(ie in
> an intranet - except ours :() then
> Web Server passes XML & XSLT back to client and client does the
work.
> This means client _could_ do lots of different xforms to data without
going
> back to any server.

I can see this would be very useful, but it is a big IF on the browser
version.

> where the web server does the xform, it could cache the xml data set
and
> reduce round trips to the app server etc....

Useful, though of course potnetial for out of date data in a rapidly
changing environment.

> It allows you to separate the data access stuff from the display
stuff.
> The ASP page basically consists of:
> create Business Object
> Call method to retrieve XML
> Xform it and write out the results.
>
> Means you don't do things like:
> while not rs.eof
> 	response.write "<option>" & rs("desc")
& "</option>"
> 	rs.movenext
> wend
>
> ie mixing display and data access.
> What if you don't want a drop down list, you want a table instead?
> The display code is all mixed in with the data access & you have
to rewrite.
>
> it's 'cleaner' with XML/XSLT

OK this is now starting to make things clearer (sorry for being a little
slow on the uptake). Within a page I tend to load a recordset into an array
and processes it from there (allows easy re-use of data within the page and
earlier release of the connection) but I think what you are describing is
more useful. I suppose it really comes down to when the data is retrieved
>from
data every time a page is requested, and I load that data into an array as
soon as the recordset is retrieved, and I then use different subroutines to
display that data according to current requirements, then I see no benefit
of XML (other than ease of coding and maintenance which I can't judge at
the moment). However, as soon as we start talking about re-using the same
data across multiple pages, then XML does provide real benefits in the
reduction of calls to the database. This would include the 'recursive' type
of data we are discussing here, where the data is reasonably static but it
needs to be continuously sliced in different ways. There is one other
option that I have used and that can be better than either approach in
certain circumstances, that is to use client side scripting. So for example
the whole hierarchy structure would be delivered to the client and
expanding and contracting would be performed with DHTML and client side
script. Of course this falls down where client scripting or DHTML is not
enabled and it can be a real performance nightmare with a big hierarchy! I
gave up on this approach when the hierarchy got to 13000 rows on a previous
project, it was great to be able to expand and collapse the tree without
returning to the server, but it was not so good when it took 2 minutes for
the tree to appear in the first place :)

> rules of thumb:
> If it's recursive, XML it.
> If you want to display the same data set in different ways, XML it.
>
> Oh, and move to .net - it's even easier to do it then!
>
aaarrrrghhh! This is another thing I haven't even scratched the surface of.
The only comment I have picked up on this so far is that SQL Server stored
procedures can be written in any language, so I guess this is (part of)
what .NET is about, using any language for any purpose? Problem is, I am
not a programmer, never have been, I am just a self-taught scripter, I can
do vbscript, javascript, stored procedures, macros etc but have never done
any VB, C++ etc etc. So will .NET really help me?


Graham