Re: Events in Slide

[Mike Oliver]

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".

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.

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]