Thanks Ritu. I was looking for a solution like this also but had overlooked the fact that you can get the properties from each response.
So my question then would be: which way should we go with this? Or can we go both? Your solution works in the client and doesn't need server changes but there are already a number of *Property classes used to pull values from other XML data property types. So although your solution is correct it makes some of the propfindMethod() calls in the DAV client useless. eg. those methods that are supposed to return the values of the properties will only work for non-XML valued props or those props we've already created *Properties files for (owener and some others). The changes I made make these DAV client propfindMethods work for the "checked-in" property, but each additional property containing an XML value will need to have a property class defined. So I think that the additional *Property classes are still warranted and it is beneficial to keep adding them as we need them. Warwick > -----Original Message----- > From: Ritu Kedia [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 15, 2004 11:53 PM > To: 'Slide Users Mailing List' > Subject: RE: New checked-in property class to submit > > > Hi Warwick, > > I had the same issue sometime back about fetching the history > uri of the last checked in version (the report method not > returning a sorted list of versions). Coincidentally my first > solution was just the same as what you did, i.e. add a > CheckedinProperty class for retrieving the href element of > the checked-in property :) But I realized that this is a > generic problem for any property which has xml value and so > here is the solution I adopted: > > Vector properties = new Vector(); > properties.add("checked-in"); > String lastCheckedInVersion = null; > Enumeration e = > getWebdavResource().propfindMethod(resourcePath, > DepthSupport.DEPTH_0, properties); > if(e.hasMoreElements()) > { > ResponseEntity resp = > (ResponseEntity)e.nextElement(); > Enumeration props = resp.getProperties(); > if(props.hasMoreElements()) > { > BaseProperty prop = > (BaseProperty)props.nextElement(); > > if(prop.getLocalName().equals("checked-in")) > { > NodeList list = > prop.getElement().getElementsByTagNameNS("DAV:", "href"); > if (list != null && > list.getLength() > 0 ) > { > > lastCheckedInVersion = list.item(0).getFirstChild().getNodeValue(); > } > } > } > } > > return lastCheckedInVersion; > > This approach could be used for any xml property value (for > e.g. Labels) > > Regards, > Ritu > > > > > -----Original Message----- > From: Warwick Burrows [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 16, 2004 3:52 AM > To: '[EMAIL PROTECTED]' > Subject: New checked-in property class to submit > > > Hi, > > I found today that when callling the propfindMethod for the > "checked-in" property that the returned property value isn't > being unwrapped from the XML response correctly. The value > returned for the checked in property is the entire <href> > element within the "checked-in" element definition rather > than the value of the href. I noticed that the owner property > is the same and that in the case of the owner the XML > response is further decoded and the actual value is returned. > So I've defined an additional property class called > CheckedinProperty that behaves like the OwnerProperty class > so that only the value of the href (the latest history URI) > is returned. If you don't see any problems with this then > I'd like to know if it can be submitted to the slide 2.1 head. > > I've actually created an HrefValuedProperty base class that > extends the BaseProperty class as OwnerProperty does now and > moved the common functionality of the Owner and > CheckedinProperty classes to this common class. The > OwnerProperty and CheckedinProperty now extend this class and > define only their TAGNAME and a constructor. If there are > more properties that could benefit from href decoding then > they could also extend the HrefValuedProperty class. > > Warwick > > > > > --------------------------------------------------------------------- > 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]
