On Fri, 2003-12-05 at 14:44, Mike Oliver wrote: > Hey#2 > > Richard Unger wrote: > > >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. > > > Concur! > > > > >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. > > > > > Concur!! > > >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. > > > Bingo! You Missed the POINT! We WANT documents to be edited and "save > directly to the slide system, using webfolders" but if the events to the > business logic are not there, then THAT is a problem. We aren't the > patient in the joke that is hitting our head on the wall and you the > doctor tells us to "dont't do that". >
Sorry... > >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... > > > > > No, BUT, we would want Eclipse to automatically pick up that change and > "do something" whether that is to just refresh and add, ask the user on > the next user event, or just report on it in the logs, or maybe we want > it to check it for appropriateness, i.e. a .java file under a registeres > src folder, a .class file under the registerd build, dist, bin or > classes folder, etc. Maybe even trigger a new local build if it compiles. > Fair enough, and this is what I suggested in the last paragraph of my email - slide sends a notification, not a vetoable event, and the business logic can do something with it. But the file gets saved... Eclipse does not change the file for you, or prevent the save. At worst, it displays a bunch of errors once it detects the change. And that's the point - eclipse has an interface for communicating the results of these events to the user - see my next email reply to Martin... Richie > >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] > >> > >> > >> > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
signature.asc
Description: This is a digitally signed message part
