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

["BUTLER, Tony, FM" <tony.butler@xxxxxxx>]

> > 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.

That's why I do it on the server :)

> > 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.

Yeah, obviously horses for courses etc.  It would work in my environment
(if
I could be arsed) though even in a changing one, if the query would
normally
take a long time, you could implement a cached solution that checks the
database for changes before deciding to go with the cached version, or
re-query the DB.
You'd do something like have a 'last updated' field in a table somewhere,
which is updated by a trigger on the table of interest.
the web server then checks if the last updated date/time is different to
the
one it is caching and takes appropriate action.

> > Means you don't do things like:
> > while not rs.eof
> > 	response.write "<option>" &
rs("desc") & "</option>"
> > 	rs.movenext
> > wend
>
> 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

If you use disconnected recordsets then you will release the DB connection
straight away anyway.

> describing is
> more useful. I suppose it really comes down to when the data
> is retrieved
> from the database and how often it is used after that. If I
> want the latest
> 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

It depends what you're doing.  I think you really need to try it before you
can say if it's worthwhile or not.
MS have underpinned everything in .NET with XML and now you can retrieve a
recordset as you normally do, but query it as if it were an XML document.
Or open an XML document and treat it like a regular recordset.  This is
because they now 'natively' store data in recordsets (or rather, datasets
as
they are called these days) in XML format.

It's more useful certainly if it's client side - eg sorting a results set
on
any column without returning to the server to re-query & sort the data
- but
it is also worthwhile on the server.
As I said before, you really need to look at XSLT too in order to get a
better idea.  XML is, after all, just another way to represent data.  It is
XSLT that  gives you all the benefits by allowing to to transform the data
any way you like.

> 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

Yes, but how do you get it to the client?
At the bottom, I have included the XSLT file I use for that XML sample I
sent yesterday of access logs.
If you cut out all the HTML, which I have done in the bit following it,
there is very little actual XSLT code.
This file causes the server to emit a HTML page with the heirarchy all
nicely collapsed, and all data is client side.
It might look like a lot of code to achieve what is a simple end result
really, but the beauty in this case is that for my other view of the access
logs, where you pick an object and see a list of users, rather than pick a
user & see a list of objects accessed, I use _exactly_ the same XML
file,
but a different XSLT file.

FYI, to display this, I do:
Set oUsers = CreateObject(CAM_USER_ADMIN & ".Users")
Set oXML=Server.CreateObject("MSXML2.DOMDocument.3.0")
Set oXSL=Server.CreateObject("MSXML2.DOMDocument.3.0")
oXML.LoadXML
oUsers.GetXMLObjectsAccessed("",Request.QueryString("object"),Request.QueryS
tring("task"),Request.QueryString
oXSL.Load
Server.MapPath("../StyleSheets/XSLT/AccessByObject.xsl")
Response.Write oXML.transformNode(oXSL)

Set oXSL = nothing
Set oXML = nothing
Set oUsers=nothing

but in ASP.Net it would be something like this:
<ASP:Xml id="lstAccess"
DocumentSource="../xml/AccessList.xml"
TransformSource="../StyleSheets/XSLT/AccessByObject.xsl"
runat="server" />

Much neater!

> > 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?

Not true.  The next version of SQL server will allow this apparently.  ATM,
you still write stored procs in SQL - remember, SQL 2000 is still the
latest
version of that product & has nothing to do with .Net

> Problem is, I am
> not a programmer, never have been, I am just a self-taught
> scripter, I can

As are most programmers :)

> do vbscript, javascript, stored procedures, macros etc but
> have never done
> any VB, C++ etc etc. So will .NET really help me?

If you have done vbscript/asp then you have done vb.
It depends on what you are using it for.  If you want to write scalable
apps, or want to write web services, console apps, faster web apps.....
then
it is worth a look.
C# is basically javascript meets java meets VB, so should be easy to get to
grips with.
VB.Net is vb meets true object orientation.

For the web developer, as well as compiled web apps, proper data typing and
a decent development environment (drag a button onto a web app 'form',
double click on it & you are brought to the code bit to process that
event -
just like 'real' VB), you get a lot of tools like data grids that make it a
piece of p*ss to get your data on screen & looking good......

HTH,


Tony



<?xml version="1.0"?>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
version="1.0">
<xsl:template match="/OBJECTLIST">
<xsl:for-each select="OBJECT">
<xsl:sort select="." order="ascending" />
<DIV>
<IMG SRC="../images/tree/space.jpg" WIDTH="0"
HEIGHT="0" />
<IMG CLASS="HotSpotMouseOut"
SRC="../images/tree/plus.gif" WIDTH="9"
HEIGHT="9">
<xsl:attribute
name="onclick">javascript:Node_onClick();</xsl:attribute>
</IMG>
<SPAN CLASS="HotListMouseOut"
onmouseover="javascript:event.srcElement.className='HotListMouseOver';"
onmouseout="javascript:event.srcElement.className='HotListMouseOut'">
<xsl:attribute
name="onclick">javascript:Node_onClick();</xsl:attribute>
&#xa;
<xsl:value-of select="DESCRIPTION"/> (
<xsl:value-of
select="count(TASK/ACCESS[not(self::ACCESS/@SORTDATE=preceding-sibling::ACCE
SS/@SORTDATE)])" /> )
</SPAN>
<DIV STYLE="display:none">
<xsl:for-each select="TASK">
<xsl:sort select="."
order="ascending" />
<DIV>
<xsl:attribute
name="ID">div<xsl:value-of
select="../@ID"/>Child</xsl:attribute>
<IMG
SRC="../images/tree/space.jpg" WIDTH="18"
HEIGHT="9" />
<IMG CLASS="HotSpotMouseOut"
SRC="../images/tree/plus.gif" WIDTH="9"
HEIGHT="9">
<xsl:attribute
name="onclick">javascript:Node_onClick();</xsl:attribute>
</IMG>
<SPAN
CLASS="HotListMouseOut"
onmouseover="javascript:event.srcElement.className='HotListMouseOver';"
onmouseout="javascript:event.srcElement.className='HotListMouseOut'">
<xsl:attribute
name="onclick">javascript:Node_onClick();</xsl:attribute>
&#xa;
<xsl:value-of
select="DESCRIPTION"/> (
<xsl:value-of
select="count(ACCESS[not(self::ACCESS/@SORTDATE=preceding-sibling::ACCESS/@S
ORTDATE)])" /> )
</SPAN>
<DIV STYLE="display:none">
<xsl:for-each
select="ACCESS[not(@SORTDATE=preceding-sibling::ACCESS/@SORTDATE)]">
<xsl:sort
select="@SORTDATE" order="ascending" />
<DIV
VALIGN="CENTER" CLASS="ListItem">
<img
SRC="../images/tree/space.jpg" WIDTH="30"
HEIGHT="9" />

<xsl:value-of select="@DATE" />
</DIV>
</xsl:for-each>

</DIV>
</DIV>
</xsl:for-each>
</DIV>
</DIV>
</xsl:for-each>
<xsl:if test="count(/OBJECTLIST/OBJECT)=0">
<SPAN CLASS="ListItem">
&lt;No tasks logged for this User between the dates
provided&gt;
</SPAN>
</xsl:if>

</xsl:template>
</xsl:stylesheet>





<?xml version="1.0"?>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
version="1.0">
<xsl:template match="/OBJECTLIST">
<xsl:for-each select="OBJECT">
<xsl:sort select="." order="ascending" />
<xsl:for-each select="TASK">
<xsl:sort select="."
order="ascending" />
<xsl:for-each
select="ACCESS[not(@SORTDATE=preceding-sibling::ACCESS/@SORTDATE)]">
<xsl:sort
select="@SORTDATE" order="ascending" />
</xsl:for-each>

</xsl:for-each>
</xsl:for-each>
<xsl:if test="count(/OBJECTLIST/OBJECT)=0">
<SPAN CLASS="ListItem">
&lt;No tasks logged for this User between the dates
provided&gt;
</SPAN>
</xsl:if>
</xsl:template>
</xsl:stylesheet>


********************************************************************
Visit our Internet site at http://www.rbsmarkets.com

This e-mail is intended only for the addressee named above.
As this e-mail may contain confidential or privileged information,
if you are not the named addressee, you are not authorised to
retain, read, copy or disseminate this message or any part of it.
********************************************************************