Opinions for Exposing XML from Methods
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Opinions for Exposing XML from Methods
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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Re: Opinions for Exposing XML from Methods
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Opinions for Exposing XML from Methods
Tim, The response document is available as an org.w3c.dom.Document from all of the raw *Method classes (eg. checkinMethod and checkoutMethod class) as they extend the XMLResponseMethodBase class which has a getResponseDocument() method that returns it. So you certainly could save the response document in the same way that each method's call status is saved in the WebdavResource today ie. by setting a class member to the output of getResponseDocument() after each *Method has been called. I don't see any problem with doing this as you're just making the existing response document available from the WebdavResource. Warwick > -Original Message- > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]