Yes, you are correct; I wanted it done automatically on server side.
Many thanks! Miguel ___ If you are look for a standard way like webdav, you can set the displayname by a PROPPATCH request. But I thought you want any thing that the server does automatically. Stefan Miguel Figueiredo wrote: > 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]
