Hey Stefan, Your suggestion solved my problem! Many thanks :)
Best Regards, Miguel Figueiredo ___ Hello Stefan, I never looked to the event's part of Slide since they weren't a standard technology like webdav is. Anyway, from your insight I can see that it might gracefully do what I wanted. I'll certainly give it a try. Many thanks, Miguel Figueiredo ________________ Because I dont see any standart way you may implement and use an event handler. There is currently a event handler called MacroPropertyUpdater that maintains the display name while copy or move. This may serve as a sample. May be a WebdavEventListener is appropriate for your. It can set the displayname on PUT, MKCOL, COPY ... Cheers, Stefan Miguel Figueiredo wrote: > Sorry, let me add a clarification: > > Anyway, how about filling up the displayname, by default, with the ending > substring of the original binding's href? > > Many thanks, > Miguel Figueiredo > > ____ > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
