> > > > > > WebDAV doesn't support observation, nor I know any draft that proposes > > > this (am I wrong?), so I think the API for observability will be put at > > > the Slide API level, or even in the domain.xml file. > > No, there is no webDAV draft for event handling as far as I know. > > The first step will be to implement event handling at Slide API level. It will > > affect many classes, but I think it is worth to do so. There will be some > > kind of event dispatcher that can be requested via > > NamespaceAccessToken.getEventHelper() ... ). You can register event listeners > > for different types of events and fire events. The dispatcher will do some > > event filtering to speed up event dispatching (as there might be a lot of > > traffic lateron). My goal is to keep it as simple as possible. > > > > > Hmmmm..... To me this begs the question, why is it not part of webDAV? > And I think the answer is that webdav is a lower level protocol, for the > *safe* transport, storage and retrieval of data in groups. > So basically I think adding vetoable events at this level is a bad idea. > If the user, for some reason, should not store the file in a certain > place, he should not have write permissions for that place. More than > this adds levels of non-determinism and uncertainty to an operation that > should be safe. But what if the content is not accepted for any reason? Any serious content management solution should be able to do some kind of content/referential integrity checking, so there is a number of reasons why an operation could fail, not only permissions. If webDAV is not able to give the user some additional feedback on the occured error, it should be extended. I'll look into the protocol to check if some error messages can be sent.
> What if a user commits a set of files, with different events being fired > for each one, some of them vetoing, some not? The transaction will be rolled back if one event fires a veto. > As for non-vetoing events, this seems ok, but then why not stick with > the listeners? > > I think there are much better places for the event logic. As has been > pointed out in numerous threads, slide is not a full content management > system, it is more like a repository at the moment. Layers like workflow > and presentation are missing entirely, and are realized by combining > slide with other Servlets/Web Applications to build a full system. This > is the place to put such events, not in the repository logic. > > Richie Slide started as a full cms, even though it is more like a content repository at the moment. But remember that it is the base for many content management solutions. And one very importent part is the ability to check referential integrity or validate content. This must be done in a tranaction aware manner. What if you are uploading some documents in a single transaction and one of it fails because of some reason? The whole transaction must be rolled back. This can not be achieved by the use of interceptors at the moment. So I think vetoable events are an elegant solution which enables slide to be used as a transactional content repository. If you only use slide as a simple webDAV-Folder this might sound a little bit overdosed, but if you think of it as a content repsitory this is a must. Daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
