Hi! I do see the purpose of events, I just think putting themin the webDAV Layer of slide is the wrong place. Your file-system under windows or linux does not provide observer-hooks allowing you to veto writes as they occur. It would be slow, confusing, and ultimately lead to problems as apps vetoed changes they shouldn't, etc...
Here's some examples of how I see this kind of thing working: Slide needs a presentation and business logic, or workflow, layer on top of the content repository in order to be a functional CMS. Typically this would be a web application, and this application can perform checks and verify content before allowing it to be saved on slide. Additionally, you could set slide up to provide multiple views of the same file system using versioning. Before the HEAD is tagged as stable, releasing it to the public view, the CMS Application can verify the content, and refuse to tag the content if it does not verify. I really like this kind of setup. If you bypass the CMS application and save directly to the slide system, using webfolders for example, you are bypassing the checks and verifications too. Think of it like an IDE, like eclipse - if you dump a file directly into the workspace using windows explorer or nautilus, you need to refresh to make eclipse aware of it. You would not want hooks in Windows Explorer or the file system driver asking eclipse for write permission first... There are many places to tackle the events, including slide, but vetoability is not a good idea. A simple changelistener interface should be sufficient to avoid having to poll for changes, no? Richie On Thu, 2003-12-04 at 10:54, Daniel Florey wrote: > > > > > > > > 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] > >
signature.asc
Description: This is a digitally signed message part
