Opinions for Exposing XML from Methods

[Tim Frank <tf...@registrar.uoguelph.ca>]

I have been working with the Webdav Client using the 
org.apache.webdav.lib.methods package directly to get the XML response 
from the slide server. I am using the XML results with XSLT to build web 
interfaces and reports.

I noticed that the WebdavResource class seems to be the powerhouse of 
the client API, however, it does not seem to provide a way to extract 
the XML responses in any easy way. The best I have seen is a piece of 
code that walks through the nodelists to merely output the same XML that 
came from the server originally. This seems to be odd when the XML is 
available from most methods is available with getResponseDocument().

As a result, I was thinking of attempting to make the XML result 
available in the WebdavResource class for easy access to those needing 
the DOM representation of the result. My idea would be to store it as a 
w3c.dom variable in the class that would get set to something other than 
a default when a method was called that returns an XML response. This 
should also be useful for extracting error messages after methods are 
executed.

I would appreciate ideas/opinions from others who may find this useful, 
or in some way problematic.

Tim

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org

Re: Opinions for Exposing XML from Methods

[Tim Frank <tf...@registrar.uoguelph.ca>]

Mirko,

I have to agree with your feelings about the duality of the 
WebdavResource class. I think there does need to be a split somehow 
between access the properties from the result of a particular operation. 
For example, there is a getOwner() method in the class but it is only 
used for "locking purposes", therefore not useful for many other operations.

The other problem I was having was trying to figure out what I would 
need to do if I wanted to get at properties that could be returned from 
a method that aren't stored in java. For example, the "lockMethod()" 
sets the owner and the lockToken which are accessible. However, the 
depth and timeout are returned in the XML, but don't seem to be 
accessible with java.

Regardless, all of these properties are extracted with DOM 
operations/searches at a low level. This was the main reason why I 
wanted the actual DOM XML result available so that I could extract 
anything I wished.

Tim

Mirko Froehlich wrote on 15/11/04 02:41 PM:
> XML support sounds very useful for debugging.
> 
> Speaking of the WebDAV client API: I have only recently started working
> with Slide and the WebDAV client API, and even though the client API is
> very powerful, I have to admit that I have mixed feelings about it.
> 
> In particular, the WebdavResource does not have very clearly delineated
> responsibilities. It seems to act as a combination of a general facade
> into the API with many convenience methods, while also trying to act as
> an entity that represents a particular WebDAV resource. In my opinion,
> these responsibilities should be clearly split up, so that
> WebdavResource only acts as an entity and another class (maybe something
> like WebdavConnection, or maybe just the WebdavSession, which
> WebdavResource currently extends) could act as a more general facade
> into the API if necessary.
> 
> Once created, a WebdavResource should only represent a particular folder
> or document, and all operations on it should use relative paths (based
> on the resource the instance represents), rather than allowing absolute
> paths.
> 
> Anyway, just a side note. :)
> 
> -Mirko
> 
> 
> On Mon, 2004-11-15 at 11:26, Tim Frank wrote:
> 
> 
>>I have been working with the Webdav Client using the 
>>org.apache.webdav.lib.methods package directly to get the XML response 
>>from the slide server. I am using the XML results with XSLT to build web 
>>interfaces and reports.
>>
>>I noticed that the WebdavResource class seems to be the powerhouse of 
>>the client API, however, it does not seem to provide a way to extract 
>>the XML responses in any easy way. The best I have seen is a piece of 
>>code that walks through the nodelists to merely output the same XML that 
>>came from the server originally. This seems to be odd when the XML is 
>>available from most methods is available with getResponseDocument().
>>
>>As a result, I was thinking of attempting to make the XML result 
>>available in the WebdavResource class for easy access to those needing 
>>the DOM representation of the result. My idea would be to store it as a 
>>w3c.dom variable in the class that would get set to something other than 
>>a default when a method was called that returns an XML response. This 
>>should also be useful for extracting error messages after methods are 
>>executed.
>>
>>I would appreciate ideas/opinions from others who may find this useful, 
>>or in some way problematic.
>>
>>Tim
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: slide-user-help@jakarta.apache.org
>>
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org

Re: Opinions for Exposing XML from Methods

[Mirko Froehlich <mf...@digitalchocolate.com>]

XML support sounds very useful for debugging.

Speaking of the WebDAV client API: I have only recently started working
with Slide and the WebDAV client API, and even though the client API is
very powerful, I have to admit that I have mixed feelings about it.

In particular, the WebdavResource does not have very clearly delineated
responsibilities. It seems to act as a combination of a general facade
into the API with many convenience methods, while also trying to act as
an entity that represents a particular WebDAV resource. In my opinion,
these responsibilities should be clearly split up, so that
WebdavResource only acts as an entity and another class (maybe something
like WebdavConnection, or maybe just the WebdavSession, which
WebdavResource currently extends) could act as a more general facade
into the API if necessary.

Once created, a WebdavResource should only represent a particular folder
or document, and all operations on it should use relative paths (based
on the resource the instance represents), rather than allowing absolute
paths.

Anyway, just a side note. :)

-Mirko


On Mon, 2004-11-15 at 11:26, Tim Frank wrote:

> I have been working with the Webdav Client using the 
> org.apache.webdav.lib.methods package directly to get the XML response 
> from the slide server. I am using the XML results with XSLT to build web 
> interfaces and reports.
> 
> I noticed that the WebdavResource class seems to be the powerhouse of 
> the client API, however, it does not seem to provide a way to extract 
> the XML responses in any easy way. The best I have seen is a piece of 
> code that walks through the nodelists to merely output the same XML that 
> came from the server originally. This seems to be odd when the XML is 
> available from most methods is available with getResponseDocument().
> 
> As a result, I was thinking of attempting to make the XML result 
> available in the WebdavResource class for easy access to those needing 
> the DOM representation of the result. My idea would be to store it as a 
> w3c.dom variable in the class that would get set to something other than 
> a default when a method was called that returns an XML response. This 
> should also be useful for extracting error messages after methods are 
> executed.
> 
> I would appreciate ideas/opinions from others who may find this useful, 
> or in some way problematic.
> 
> Tim
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-user-help@jakarta.apache.org
>