[prev in list] [next in list] [prev in thread] [next in thread] 

List:       slide-dev
Subject:    RE: Binding store and DASL extensions
From:       "Miguel Figueiredo" <mfigueiredo () maisis ! pt>
Date:       2005-02-28 10:59:40
Message-ID: 200502281040.j1SAeeQ01082 () www ! maisis ! pt
[Download RAW message or body]


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: slide-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
> 
> 
> 


-- 
Stefan Lützkendorf  --  luetzkendorf@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]