Thank you for the response Stefan! Well, we are not using lucene with DASL, not yet anyway. We just set up the bind store with that optional classname="org.apache.slide.store.BindingStore" attribute and everything else is very straight forward (txFile store).
But, returning to the binding issue. I agree with you in that we can't use the displayname like we would for a name of the resource: a resource's href xml element can be anything like you presented, and still reference the same resource. So, it's not possible to give a common name to all bindings of the same resource. This is ok with me. Anyway, how about filling up the displayname, by default, with the ending substring of the binding's href? Like I said previously, I didn't find anything about the displayname property on a resource (or more precisely, on a resource's bind) in the matter of if it is optional or if it is mandatory, so perhaps this isn't a bug. But Slide could still fill up the binding's displayname at its creation, if for anything, for consistence sake with the default store. This could also help me and others when using the Bind store and DASL: we could use the displayname like a name for the resource, even if it wasn't (with some planning we can do it like it was really its name). If this feature is ok with you and the developer team, perhaps I could contribute with a patch if you guys are overwhelmed. I believe it would be very easy to enhance the store. Many thanks, Miguel Figueiredo __________________ The Problem with BINDing and the displayname property is that the property cant used a something like a "filename" of "name of the resource", because different bindings may have diffrent last segments in its uri, e.g. /files/docs/abc.txt and /files/other/def.txt can be bound to the same resource. So you cant determine the "filename" at the resource in general. An other point. What DASL impleemntation do you use? AFAIK at least the lucene base indexer is not yet prepared to work with binding stores :-( Regards, Stefan Miguel Figueiredo wrote: > Hello folks, > > I'm wandering if I found a bug at the binding store. When using it, each > resource does not have a DAV:displayname property - is that a bug? Could not > found anything in the spec saying that the DAV:displayname is optional nor > if it was mandatory, so I'm kind of puzzled on this. > > Well, when trying to use DASL, we have found out that it's not possible to > do a search in resources, and include the href 'property' in our search > options. That is, we could not find any resource, using DASL, and based on > the DAV:href xml element, because this element is not considered as part of > the resource properties like, for example, DAV:displayname is. This is ok, > that's what's expected from the spec. So we started using the > DAV:displayname to find out about the resources names, since that property > had the last substring of the uri of the resource, containing what we > recognize as name of the resource. > > Problem is, when using the binding store, each resource won't have the > DAV:displayname, so we can't search for resources based on their names... > (lol) :) > > Will someone agree with me on adding the same behavior of the default store > to the binding store? Maybe it's not a bug since nothing is said about if > displayname is mandatory, but at least it should be added in the binding > store for consistancy sake. > > Many thanks, > Miguel Figueiredo > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Stefan L�tzkendorf -- [EMAIL PROTECTED] --------------------------------------------------------------------- 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]
