date:20040306

Hi:

Why the c must means something? I think we are missing the point here.
The idea of CForm is to allow easy searching on the Net for Cocoon form.
Just googling:

Form:   133 M
CForm:  28.4 K
CForm1: 180
CForm2: 153

If the C must means something, then choose: cool, creative, coocon
or any other. It can be a tag to help user find our stuff on the net.

What about the next release?

We can call it CForms 2.0, etc. Just the same as cocoon evolves our forms
can evolve. Think what have in common Cocoon 1.0 and Cocoon 2.2? Almost
nothing, even the target was changed from a publisher framework to a web
development framework. It is natural to move the target on the time.

joke
Now I understand why MS tell that OSS project don't innovate:

Look at then, they are rewriting a similar tool as Apache Ant, but it is
not called MS Ant, it is called MS Builder.

Can you see the innovation in the name? New name means innnovation. :-D
/joke

In short, I am +1 to have a clear name for our form-fw: CForms.

Best Regards,

Antonio Gallardo

Ugo Cei dijo:
 Marc Portier wrote:
 another +1 to 'cforms' over 'forms'

 Doesn't the c stand for Cocoon? If it does, I find it somewhat
 redundant, especially in a package name: org.apache.cocoon.forms ==
 org.apache.cocoon.cocoon.forms?

 And what if someday we develop a new forms framework, do we call it
 dforms? ;-)

 I propose to use just forms as the block name, Cocoon Forms in the
 docs, and do a s/woody/forms/ in the package names and namespaces.

 Just MHO,

   Ugo

Re: SimpleFormTransformer (was: From Woody to CocoonForms)

Joerg Heinicke dijo:
 On 05.03.2004 16:57, Ralph Goers wrote:

 I am not in favor of having FormValidatorAction and
 SimpleFormsTransformer
 deprecated.  They are lightweight and do the job they were intended to
 do.

 Until now the discussions about deprecating old form stuff where only
 about the two existing blocks and frameworks XMLForms and JXForms. I
 don't know about SimpleFormTransformer - is Woody/CForms in contrary
 really complex?

Never mind. CForms are very easy. I will be +1 in deprecate the
FormValidatorAction and SimpleFormsTransformer in favor of woody.

Best Regards,

Antonio Gallardo.

RE: Turning off default MRU store

Corin Moss dijo:

 Hi Guys,

 I think the thing to remember here is that it's the Disk Cache
 implementation that has this behaviour, and that it's very easy to use a
 different store type if the user feels it's necessary.  There are other,
 safer store implementations we can use - the only problem in this case
 is that the index is kept in memory (which is what makes it so fast.)
 If the user decides that this is inappropriate for them, the change to a
 different store type is very easy to make within the config.

 I think that moving to a filesystem store would be counter-productive,
 as the thing that JCS provides is total flexibility of store type.

I totally agree with you. JCS is the way to go. I read the docos and it is
a good piece on the Cocoon cake, even if we will never had in mind to
repleace jisp. JCS is the right tool for these job too.

Best Regards,

Antonio Gallardo

Re: Turning off default MRU store

Unico Hommes dijo:
 Geoff Howard wrote:

 Unico Hommes wrote:

 Sylvain Wallez wrote:

 Unico Hommes wrote:


 Unico Hommes wrote:



 Corin Moss wrote:

 Hi Guys,

 I might be getting ahead of myself a bit here, but I'm going to
 try and turn off the default MRU store, in favour of the JCS
 based persistent store.  I'd like to try some tests on
 performance without the default MRU - has anyone else tried
 anything similar? I've simply set the core store's role to point
 to the JCS store implementation.


 I guess I already got ahead of you when I renamed
 JCSPersistentStore JCSStore just now :-) (And merged it with the
 AbstractJCSStore BTW). It seems to me that JCS is both and it
 could replace all three stores: DefaultStore, TransientStore and
 PersistentStore.


 I have to add that this is not the whole story. We do actually need
 to distinguish between persistent and transient storage. Some
 components explicitly want to persist some data instead of just
 cache it for speed. But as far as caching is concerned I think it
 we can leave it completely up to JCS.





 Some components are explicitely using the transient-store to keep
 data that shouldn't (or cannot) be serialized. But AFAIK, no
 component directly uses the persistent-store except the store itself.


 To my knowlegde there is one in eventcache block that uses the
 PersistentStore to persist some info it needs to recover upon next
 startup.

 It does not look to me as though JCS would fit the PersistentStore
 role very well. I was thinking that perhaps. We could have JCSStore
 as a replacement for TransientStore and Store roles and use
 FilesystemStore for the PersistentStore role.



 Wait a minute.  The original issue that brought JCS to the front as
 that the persistent store was broken and had license problems.  Are
 you saying that JCS isn't a good candidate for persisting the cached
 info to disk, or that the fact that it by default has an MRU memory
 front-end makes it not map directly to persistent-store role cleanly?

 IIUC, JCS will always use a memory store in front yes. And it suggests
 on the JCS website that the persistence process is not very reliable:

 from http://jakarta.apache.org/turbine/jcs/IndexedDiskAuxCache.html :

 When the disk cache is properly shutdown, the memory index is written
 to disk and the value file is defragmented. When the cache starts up,
 the disk cache can be configured to read or delete the index file. This
 provides an unreliable persistence mechanism.

 The use of persistent store in eventcache shouldn't be a problem with
 JCS as long as at shutdown, it persists everything it has in its MRU
 if it hasn't already.  If there is some problem it would be much
 better to just go back to the old serializing persistence for the
 event cache data because the only benefit to putting it in the store
 is that you more or less guaranteed that the events and cached
 responses would be kept together.


 Yes, giving up that feature would be too bad.

Why?

If this is a must needed feature we can collaborate with the JCS team to
extend the work.

WDYT?

Best Regards,

Antonio Gallardo.

DO NOT REPLY [Bug 20736] - JXForms validator rejects null value for numeric field

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20736.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20736

JXForms validator rejects null value for numeric field





--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 10:53 ---
I think it should be resolved as WONTFIX.

DO NOT REPLY [Bug 25304] - AggregateField enhancement

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25304.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25304

AggregateField enhancement





--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 11:19 ---
I think it covers everything described in the email. Can Marc take a look at
aggregate field examples and close this bug?

DO NOT REPLY [Bug 27467] - Upgrade all source files to ASF 2.0 license

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467

Upgrade all source files to ASF 2.0 license





--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 11:49 ---
Is it possible, that to some files the ASF 2.0 license has been accidently added?
Take a look at the htmlarea stuff for example:
src/blocks/woody/samples/resources/htmlarea/...

They have now the following header with two copyrights:
/* [snip of ASF 2.0 License Header] */
// htmlArea v3.0 - Copyright (c) 2002-2004 interactivetools.com, inc.
// This copyright notice MUST stay intact for use (see license.txt).
//
// Portions (c) dynarch.com, 2003-2004
//
// A free WYSIWYG editor replacement for textarea fields.
// For full source code and docs, visit http://www.interactivetools.com/
//
// Version 3.0 developed by Mihai Bazon.
//   http://dynarch.com/mishoo
//
// $Id: htmlarea.js,v 1.2 2004/03/06 02:26:06 antonio Exp $

Perhaps other files are affected too.
I don't know, if the mattkruse-lib files are ok.
They are looking this way:
/* [snip of ASF 2.0 License Header] */
// ===
// Author: Matt Kruse [EMAIL PROTECTED]
// WWW: http://www.mattkruse.com/
//
// NOTICE: You may use this code for any purpose, commercial or
// private, without any further permission from the author. You may
// remove this notice from your final code if you wish, however it is
// appreciated by the author if at least my web site address is kept.
//
// You may *NOT* re-distribute this code in any way except through its
// use. That means, you can include it in your product, or your web
// site, or any other form where the code is actually being used. You
// may not put the plain javascript up on your site for download or
// include it in your javascript libraries for download. 
// If you wish to share this code with others, please just point them
// to the URL instead.
// Please DO NOT link directly to my .js files from your site. Copy
// the files to your server and use them there. Thank you.
// ===

Re: Experience with workflow at Hippo Webworks

2004-03-06 Thread Guido Casper

Johan,

thanks a lot for sharing your experiences.

As it happens I'm right now implementing workflow for a customer.

I have no knowledge about OSWorkflow (or any other commercial or 
non-commercial workflow engine) and having looked at Lenya's workflow 
package I couldn't quite get how to use it in my context (I would be 
grateful if Lenya people are listening and jumping into this 
discussion). However while implementing I quickly discovered I came up 
with with similar terms (what surprise :-)

It's interesting that you connected workflow directly at the repository 
(backend) level, which appears right to do so at first. But I believe we 
should try to do it at the Cocoon level. TBH currently I'm only 
interested to do it at the Cocoon level since this would allow me to use 
it in different Cocoon contextes. Whether that should read Cocoon 
repository level instead of Cocoon level I'm not sure since there 
might be other objects (like simple records in a SQL table) to be 
attached to workflow.

But to have a common ground (and terminology) I just talk about 
(Cocoon's) repository and documents (being resources or objects having 
workflow attached).

Our customer's repository is also a WebDAV repository and the current 
workflow state is captured as a WebDAV property of the document.

If the Repository interface within the repository block would be 
extended with get/setProperties (maybe we should simply have another one 
RepoWithProps) I believe the same workflow engine could be connected 
to any repository implementation attached to that interface.

The drawback to that approach is that other access paths to the repo are 
not attached to the workflow (of course you can do things like routing 
your WebDAV traffic through Cocoon).

On a side note, I believe in addition to components implementing the 
Repository interface we could/should come up with a set of components 
(like a WorkflowManager :-) sitting on top of that repository. But this 
gets too much offtopic.

The workflow our customer has goes roughly like this:

  - 
|tobereviewed|--|beingreviewed|--|released|
  - 
 /|\|  |
  | |  |
  |\|/\|/
 --   - --
|beingprocessed|---|tobeprocessed|--|online|
 --   - --
 /|\|  |
  |\|/ |
  |    |
   ---|archived|-

The boxes represent states a particular document might be in and the 
arrows are transitions allowed. Authorization is also taken into account 
in a sense that there are 2 globally valid roles (like user and editor 
:-) and each user must possess one of those. Some transistions are only 
allowed by one of those roles (all this looks very similar to your use 
cases - what surprise again :-). tobeprocessed might have a username 
attached to it and beingprocessed always has a username attached to it 
(the name of the user who put the document into the beingprocessed 
state) and only this user is allowed to edit this document and to 
transfer it into another state. There is another level of authorization 
(such as who might create/delete and edit docs at particular repo 
locations) implemented via WebDAV ACL.

We always capture the states as being properties of a document (that 
means there is no such thing as a workflow instance). So a pending task 
list for a user might simply be implemented by a DASL (or whatever query 
language the particular repository implementation might implement) query 
that goes like:
-give me all documents in tobeprocessed state
-give me all documents in tobeprocessed state with my name attached
-give me all documents in tobereviewed state

and doesn't have to be a concern of the workflow engine at all.

So what might such a WorkflowManager look like? Our WorkflowManager (and 
I hereby propose to follow that path :-) is implemented as a Avalon 
component with the following interface:
-setState(docURI, requestedState, user, optionalObject)
-getState(docURI)
-getAllowedActions(docURI, user)
-setRepo(repo)

I hope the general meaning of the parameters is clear (and the details 
may be discussed later). docURI might be just an object identifier or 
an object carrying things like doctype information (so that your second 
precondition is met). requestedState might be a State object, an 
Action object, an Event object, simply a string or whatever. 
optionalObject in our case is string carrying a comment.

Such an interface might be high level enough to allow for plugging in 
slightly different approaches.

WDYT?

Oh, one more thing that might be worth discussing first. I reasonate 
with many of the

Re: From Woody to CocoonForms

Antonio Gallardo wrote:

Why the c must means something? I think we are missing the point here.
The idea of CForm is to allow easy searching on the Net for Cocoon form.
Just googling:
 

Antonio,

You missed discussion on branding. You suppose to google for Cocoon 
Forms - which means your are searching for Cocoon (brand) Forms 
(functionality). And *no* Cocoon beginner will search for abcxyzforms 
- because they are beginners and they do not know that instead of 
searching for Cocoon Forms they have to search for obscure keyword, 
such as abcforms, or xyzforms, or cforms ;-)

To make it clear, I'm -1 on CForms appearing anywhere in 
documentation, wiki, javadocs. I can live with cforms block directory, 
but forms block directory makes more sence to me.

Vadim

Re: From Woody to CocoonForms

Vadim Gritsenko wrote:

Antonio Gallardo wrote:

Why the c must means something? I think we are missing the point here.
The idea of CForm is to allow easy searching on the Net for Cocoon 
form.
Just googling: 


You missed discussion on branding. You suppose to google for Cocoon 
Forms - which means your are searching for Cocoon (brand) Forms 
(functionality). And *no* Cocoon beginner will search for 
abcxyzforms - because they are beginners and they do not know that 
instead of searching for Cocoon Forms they have to search for 
obscure keyword, such as abcforms, or xyzforms, or cforms ;-)


To prove the point:

 http://www.google.com/search?q=cocoon+formsbtnI=I'm+Feeling+Lucky

Vadim

Re: From Woody to CocoonForms

2004-03-06 Thread Bertrand Delacretaz

Le Samedi, 6 mars 2004, à 14:31 Europe/Zurich, Vadim Gritsenko a écrit :
...To make it clear, I'm -1 on CForms appearing anywhere in 
documentation, wiki, javadocs.
Same here.

...I can live with cforms block directory, but forms block 
directory makes more sence to me.
hmmm... to me cforms is useful as a name of technical stuff: 
packages, block name, etc.

Just because it makes searching easier than just forms, in mailing 
list archives and the like. It's not only end users who are searching 
for stuff ;-)

So to me the best is still Cocoon Forms as the visible name and 
cforms as the internal, technical name.

-Bertrand

Re: Turning off default MRU store

2004-03-06 Thread Geoff Howard

Corin Moss wrote:

Hiya,

That's a very pertinent set of questions - I'll answer as best I can
below, the only caveat is that I won't proclaim myself a JCS expert,
given that I was really only introduced to it a few days ago ;)
 

Ok, fair enough! :)

...

Ok, I apologize that I just can't look into this myself right now, but
let me try to state what I perceive to be the things we really need so
we can narrow down whether this is the right direction to be going:
1)
- we need a high-performance in-memory cache
- we need that cache to be backed by some sort of persistence for two
reasons
 first, so that cached items aren't lost between server starts
 second so that items bumped off the memory cache can still be
preserved as the assumption is that pulling a cached item off disk is
still faster than regenerating the entire pipeline.  for example, the
most popular 100 items are served in memory, but the rest are on disk.
(and at shutdown, the 100 in-memory ones go to disk).
** is JCS (properly configured) a good way to meet both of these
requirements?
CM: Yes.  A JCS store can be configured to use an MRU store (the test
config provided does just this.) This MRU store is in turn configurable
- number of objects catered for, what type of store (memory etc.) The
swapping to disk based store is handled in the same way as Cocoon
currently does - objects are dropped out of MRU store into diskbased
store. The only difference is that the disk based store can in fact be
any of the several stores supported by JCS (remote server, disk, JISP
etc.)
 

Ok.

At shutdown, things can be configured to store to disk (both store, and
index.)  The only issue is that in the event of an abnormal shutdown the
index can be lost (this is only when the index is kept in memory of
course - other store types which use pure disk based index storage
wouldn't be effected by this.)
--
 

Ok, on second thought if this is limited to abnormal shutdown this 
should be OK at least for our use with cached pipelines.  I don't really 
know firsthand the other uses of the Cache.  If they are OK with no 
guarantee of persistence, then I think we're set.

2) currently we accomplish both of those transparently with a
transient-store configured to use a persistent-store.  we have some
subsystems which use a transient-store configured _not_ to use
persistence because of application requirements.
** is JCS (properly configured) a good way to meet this requirement?

CM: Yes.  You could very easily configure a separate role for transient
store which would use a different group / region (JCS terms.)  This
region would be configured to use _only_ memory store, with no support
for persistence.  This could be accomplished as is, by changing roles
appropriately, and providing different config in the xconf for the
transient store.
--
 

Ok, sounds good too.

3) we have one subsystem which goes direct to the persistent-store right
at shutdown which could just as easily go to the in-memory front-end as
long as the persistence between restarts still happened.
** is JCS (properly configured) a good way to meet this requirement?

CM: Yes.  Again, this could either be written to the default store,
which would go to MRU, and then disk at shutdown, _or_ a different group
/ region could be created and configured which would go straight to
disk, without an in-memory MRU involved.
--
 

I think this particular case works better going to the default store.  
It's a very minor use (one object, and only at shutdown) and so not 
worth a different cache entirely.

I am not following the details well here about the persistence issue. 
If we don't use the Disk Cache, what other persistent (on disk, survives
restarts) options are there?

CM: As I mentioned before, the only issue which needs more investigation
is abnormal shutdown with an in-memory index, however, this could
theoretically be up to the user to decide - if their application
requires an absolute guarantee of persistence at all times, they could
configure it to use an on-disk index at all times - this would require
no class change, just a change in the CCF.
 

Ok, I think this bears bringing this issue up in a new thread (so people 
notice it).  The point I take out of this is that JCS makes it explicit 
that successful persistence is not currently guaranteed (at least in the 
default better-performing configuration).  For all we know, this may 
have been the case with JISP too but just not explicit.  I don't know if 
people have used our Cache as a persistence layer for application data.  
I would not have recommended it before, and definitely would not now if 
we go to JCS.  I'm comfortable with this.

Geoff

DO NOT REPLY [Bug 25594] - [PATCH] StreamGenerator can't handle multipart request parameters correctly

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25594.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25594

[PATCH] StreamGenerator can't handle multipart request parameters correctly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
Summary|StreamGenerator can't handle|[PATCH] StreamGenerator
   |multipart request parameters|can't handle multipart
   |correctly   |request parameters correctly



--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 14:37 ---
Thanks Gernot. I added your patch to both 2.1 and 2.2, added a sample to both
and tested it with 2.1. Both the existing sample (upload as string/parameter
value) and the new one (upload as file) work.

It would be good if you can test it too and close the bug afterwards.

Joerg

DO NOT REPLY [Bug 25934] - [PATCH] LuceneIndexContentHandler.java produces CLOBs

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25934.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25934

[PATCH] LuceneIndexContentHandler.java produces CLOBs

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|LuceneIndexContentHandler.ja|[PATCH]
   |va produces CLOBs   |LuceneIndexContentHandler.ja
   ||va produces CLOBs

[CocoonForms] Code freeze

2004-03-06 Thread Reinhard Pötz

In the next few days I'm going to rename Woody to Cocoon Forms. So 
please don't commit into the Woody block any more as it will be removed 
afterwards. Expect results by the end of next week (and not before 
Monday afternoon).

Here are the new names (latest status summing up the recent discussion):

Block Title: Cocoon Forms
Block Name:  forms
Package: org.apache.cocoon.forms
Namespace:   http://apache.org/cocoon/forms/1.0#definition 
http://apache.org/cocoon/forms/1.0#definition
NS Prefix:   fd

Reinhard

Update CocoonForms flowscript API (was Re: [CocoonForms] Code freeze)

2004-03-06 Thread Christopher Oliver

Can we also get rid of the original Woody flowscript API as part of this 
process (and replace it with the v2 version)? The original was clearly 
not ready for prime time.

--
Chris
Reinhard Pötz wrote:

In the next few days I'm going to rename Woody to Cocoon Forms. So 
please don't commit into the Woody block any more as it will be 
removed afterwards. Expect results by the end of next week (and not 
before Monday afternoon).

Here are the new names (latest status summing up the recent discussion):

Block Title: Cocoon Forms
Block Name:  forms
Package: org.apache.cocoon.forms
Namespace:   http://apache.org/cocoon/forms/1.0#definition 
http://apache.org/cocoon/forms/1.0#definition
NS Prefix:   fd

Reinhard

Re: [SUMMARY] From Woody to Cocoon Forms 1.0

Tim Larson wrote:
On Sat, Mar 06, 2004 at 07:05:01AM +, Tim Larson wrote:

On Fri, Mar 05, 2004 at 11:41:15PM +, Pier Fumagalli wrote:

On 5 Mar 2004, at 21:10, Stefano Mazzocchi wrote:

Tim Larson wrote:

On Fri, Mar 05, 2004 at 01:24:57PM -0500, Stefano Mazzocchi wrote:

Package: org.apache.cocoon.cforms

here I would go forms instead. package naming is where the estate 
really is, where class collissions might happen.
I understand how this seems like a good place for the battleground,
but to introduce a new winner it looks like this would force us to
break code compiled against the previous major version because we
would be stealing the class and interface names for the new version.
Does the new block system somehow solve this problem like via
classloaders or something else?
eh, very good question, actually. I spent a few hours discussing with 
Pier about this yesterday over IM. Pier, as usual, sees the very core 
problem and I always miss ;-)
snip long, complex classloading/dependency discussion/

Ok, so to sum up the version/classloading discussion, this plan
(using 'forms' for the package naming) involves burning the users
on major version upgrade by for most practical purposes breaking
the previous major forms version when introducing the new version.
This is incorrect. You are breaking those people that want to use both 
versions in the same classloading context. The chance of this happening 
reduces the higher you get and forms are pretty high in the stack.

I agree with the idea of forcing core developers to choose between
adding enhancements incrementally versus making a *major* effort to
prove that their new revolutionary version deserves to unseat the
current framework, but making things tough for the users is going
too far.  I must be missing something, would somebody enlighten me?


I talked with Antonio on IRC and he had a good idea (IMHO) for this.
Make the package name start as either o.a.c.forms or o.a.c.forms1
and a new major version can go to o.a.c.forms2.  This preserves the
ONE-and-only current forms framework concept (identified by the
current stable version number), while not introducing any classloading
version problems.  Also, the actual class names and interface names
are not polluted with version numbers.
WDYT?
I don't think we need to go that far (this is hacky as hell).

Don't worry, Tim, it's tricky but we are still in good shape :-)

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: From Woody to CocoonForms

Bertrand Delacretaz wrote:

So to me the best is still Cocoon Forms as the visible name and 
cforms as the internal, technical name.
+1

so, how does this translate into the proposal? let's try to reach a 
consensus here.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Update CocoonForms flowscript API (was Re: [CocoonForms] Code freeze)

Christopher Oliver wrote:

Can we also get rid of the original Woody flowscript API as part of this 
process (and replace it with the v2 version)? The original was clearly 
not ready for prime time.
+1

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [CocoonForms] Code freeze

2004-03-06 Thread Bertrand Delacretaz

Le Samedi, 6 mars 2004, à 16:47 Europe/Zurich, Reinhard Pötz a écrit :

...Here are the new names (latest status summing up the recent 
discussion):
...Package: org.apache.cocoon.forms
...NS Prefix:   fd
Do we have volunteers to update the docs, samples and wiki as well to 
account for these changes?

Like I said yesterday, my lazy side would keep the old package name.
But if someone is willing to sync the docs and wiki, no problem.
-Bertrand

Re: cvs commit: cocoon-2.1 status.xml

[EMAIL PROTECTED] wrote:

  public void characters(char[] ch, int start, int length) {
  
  if (ch.length  0  start = 0  length  1) {
 -String text = new String(ch, start, length);
  if (elementStack.size()  0) {
  IndexHelperField tos = (IndexHelperField) elementStack.peek();
 -tos.appendText(text);
 +tos.appendText(ch, start, length);
  }
 -bodyText.append(text);
 +bodyText.append(' ');
 +bodyText.append(ch, start, length);
  }
  }

What will happen when keyword text is streamed as two characters 
events, key and word? I think it will become key word, and 
indexing will break.

IIUC, idea was to add a space in between tags, i.e. so 
psome/pptext/p is not indexed as sometext. If that's correct, 
then better fix would be to add space only if boolean flag 
had_start_or_end_element_in_between_char_events set.

Vadim

Re: From Woody to CocoonForms

2004-03-06 Thread Bertrand Delacretaz

Le Samedi, 6 mars 2004, à 17:44 Europe/Zurich, Stefano Mazzocchi a 
écrit :

Bertrand Delacretaz wrote:

So to me the best is still Cocoon Forms as the visible name and 
cforms as the internal, technical name.
+1

so, how does this translate into the proposal? let's try to reach a 
consensus here.
Reinhard's code freeze proposal uses forms instead of cforms for 
the technical name.
But this is one of those things where it's hard to agree, and not 
terribly important IMHO.

So, although I prefer cforms, I'm fine with either, provided whoever 
does the change syncs the docs and wiki as well, or makes sure there 
are volunteers to sync them.

I'll be mostly offline until Tuesday morning, as I said I'm fine with 
whatever except a half-finished renaming job.

-Bertrand

Re: Update CocoonForms flowscript API (was Re: [CocoonForms] Code freeze)

Christopher Oliver wrote:

Can we also get rid of the original Woody flowscript API as part of 
this process (and replace it with the v2 version)? The original was 
clearly not ready for prime time.


This new API, does it allow creation of JXTemplate macros with proper 
wi:styling handling (old set of macros were printing wi:styling outside 
of wi:field element)?

Vadim

Re: Update CocoonForms flowscript API (was Re: [CocoonForms] Code freeze)

2004-03-06 Thread Christopher Oliver

Those jx macros have never been checked in. I can check in something 
after Reinhard is done if you want. To fix the problem you mention, a 
helper Java class has to be written that buffers the widget's 
end-element event and allows the macro to stream the wi:styling element 
before it. This class can be called from the macro.

Chris

Vadim Gritsenko wrote:

Christopher Oliver wrote:

Can we also get rid of the original Woody flowscript API as part of 
this process (and replace it with the v2 version)? The original was 
clearly not ready for prime time.


This new API, does it allow creation of JXTemplate macros with proper 
wi:styling handling (old set of macros were printing wi:styling 
outside of wi:field element)?

Vadim

Re: [CocoonForms] Code freeze

2004-03-06 Thread Reinhard Pötz

Bertrand Delacretaz wrote:

Le Samedi, 6 mars 2004, à 16:47 Europe/Zurich, Reinhard Pötz a écrit :

...Here are the new names (latest status summing up the recent 
discussion):
...Package: org.apache.cocoon.forms
...NS Prefix:   fd


Do we have volunteers to update the docs, samples and wiki as well to 
account for these changes?

Like I said yesterday, my lazy side would keep the old package name.
But if someone is willing to sync the docs and wiki, no problem.
-Bertrand

AFAIK there are no docs. The samples will be updated by me. So only the 
wiki pages are open

--
Reinhard

Status on Woody--CocoonForms renaming (was: Update CocoonForms flowscript API)

2004-03-06 Thread Reinhard Pötz

Christopher Oliver wrote:

Can we also get rid of the original Woody flowscript API as part of 
this process (and replace it with the v2 version)? The original was 
clearly not ready for prime time.

--
Chris


The first part is done - which means:
- renaming of all Java classes
- reflect changes within Flowscripts
- first run on updating all samples
open
- Stylesheet for namespace change and change the
  namespaces
- tidy up samples (get rid of first flowscript implementation, make
  them easier to understand, ...)
- woody is used at many places (javadocs, parameter names, client-side 
javascript)
  -- as I want to learn more about CocoonForms I'll use this 
opportunity and go
  through all classes and make the updates.

Expect the new block on Wednesday evening (GMT) ;-) as my time the next 
three days is very limited.

--
Reinhard

DO NOT REPLY [Bug 25094] - Move Woody into CocoonForms block

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25094.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25094

Move Woody into CocoonForms block

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|[EMAIL PROTECTED]   |[EMAIL PROTECTED]

DO NOT REPLY [Bug 27467] - Upgrade all source files to ASF 2.0 license

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467

Upgrade all source files to ASF 2.0 license





--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 18:51 ---
Please wait before ranting :-D,

http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107853962408827w=2

Re: Experience with workflow at Hippo Webworks

2004-03-06 Thread Guido Casper

Stefano Mazzocchi wrote:
Johan Stuyts wrote:

Experience with workflow at Hippo Webworks
==
At Hippo we used OSWorkflow to implement a workflow solution in a 
demo. Below are our experiences.

As people with different levels of experience are interested in 
workflow I will start with a (very) brief introduction to workflow.

Workflow introduction
-
Very simply put workflow serves two purposes:
- to determine who can do what at which time with an object;
- to generate a list of pending tasks for users.
An example of the first is that an editor (who) can only publish (do 
what) a document (an object) after a writer has asked for a review (at 
which time).

The lists of documents to be reviewed is an example of a pending task 
list for an editor.

Each object type can have its own specific workflow.

The demo workflow
-
The demo we created has a workflow for a basic document type, a web 
page. I have attached a diagram of it.

A document gets created by a writer. The writer is not allowed to 
publish his document directly, he has to ask the editor for review.

The editor can easily review documents because we generate a list of 
documents waiting for review. The editor can click on the document and 
can either approve or disapprove. If the document gets approved it is 
published on the public server.

If the document gets disapproved the writer can not ask for a review 
without editing it first. Editing the document when it has been 
approved will bring the document back to the editing state too. After 
making his changes the user can ask for a review of the new version.

Implementation
--
For the document repository we use Slide. For the workflow engine we 
used OSWorkflow. We connected these two using Slide interceptors.


wow, supercool!! I want it :-)

When a document is created the interceptor checks to see whether a 
workflow already exists. It does this by retrieving the workflow ID 
from a WebDAV property of the document. If it doesn't exist a new 
workflow is created in the workflow store.


Interesting terminology you use here: let me ask you this before we get 
confused: workflow is for you an instance of the model or the model 
itself?

When our frontend retrieves the tree of documents, the interceptor 
will retrieve the workflow for each document. 


Seems to be the instance. Ok, careful though, because normally people 
refer to workflow as the model, not the instance.

Looking at the role of the user the interceptor will determine which 
actions are enabled. The enabled actions (including their display text 
and activation URLs) are set in a WebDAV property of the document.

For the generation of the pending task list we used the OSWorkflow 
query API to generate the documents which are in the 
waiting-for-review state. The approve and disapprove actions are 
passed to the frontend in the same way as the commands for a writer.

Not all actions are directly shown in the menu, because the user 
invokes them implicitly. The edit action for example is invoked by the 
interceptor each time the user saves the document.

Issues
--
We encountered issues with both slides and OSWorkflow during the 
implementation.

Before we used Slide, we used the Cocoon repository. The semantics of 
the repository interceptors and the Slide interceptors is not the 
same. With the repository interceptor we were able to add a property 
to the document in postStoreContent(...). In Slide we had to do this 
in preStoreContent(...).


IMHO, makes more sense to add metadata in pre-saving than in 
post-saving. It's way more efficient for clustered environments.

Apart from that the Slide interceptors work very well, but (in the 
version of Slide we used) they get called a lot. A single store of a 
document invoked preStoreContent(...) and postStoreContent(...) 
multiple times.


well, this is a bug then. there should be a way to connect to an atomic 
event for a content store... you might want to bring this up on slide-dev

OSWorkflow performed great too. The only disadvantage was the 
complexity of state machines that can be expressed. As you can see in 
the attached diagram nested states are used. OSWorkflow does not 
support these.


The more I hear about workflows, the more I think that writing them with 
flow and continuations makes more sense than writing a finite state 
machine.

Although the attached workflow does not contain parallel states, we 
think it might be needed for some document types. A newsletter for 
example follows the same workflow as the attached one. But parallel to 
this is a mailing workflow for sending it to the newsletter subscribers.

In the mailing workflow the user can send a test email of the current 
version to himself. When he is satisfied he can send the final version 
to the newsletter subscribers. After this, he can neither send a test 
email nor send it to the subscribers.

But what to do if a

Re: From Woody to CocoonForms

Vadim Gritsenko dijo:
 Vadim Gritsenko wrote:

 Antonio Gallardo wrote:

 Why the c must means something? I think we are missing the point
 here.
 The idea of CForm is to allow easy searching on the Net for Cocoon
 form.
 Just googling:


 You missed discussion on branding. You suppose to google for Cocoon
 Forms - which means your are searching for Cocoon (brand) Forms
 (functionality). And *no* Cocoon beginner will search for
 abcxyzforms - because they are beginners and they do not know that
 instead of searching for Cocoon Forms they have to search for
 obscure keyword, such as abcforms, or xyzforms, or cforms ;-)


 To prove the point:

   http://www.google.com/search?q=cocoon+formsbtnI=I'm+Feeling+Lucky

I got:

http://www.root.cz/clanek/2024

This is really lucky ;-)

Best Regards,

Antonio Gallardo

Re: From Woody to CocoonForms

2004-03-06 Thread Tim Larson

On Sat, Mar 06, 2004 at 08:38:07AM -0500, Vadim Gritsenko wrote:
 Vadim Gritsenko wrote:
 
 Antonio Gallardo wrote:
 
 Why the c must means something? I think we are missing the point here.
 The idea of CForm is to allow easy searching on the Net for Cocoon 
 form.
 Just googling: 
 
 
 You missed discussion on branding. You suppose to google for Cocoon 
 Forms - which means your are searching for Cocoon (brand) Forms 
 (functionality). And *no* Cocoon beginner will search for 
 abcxyzforms - because they are beginners and they do not know that 
 instead of searching for Cocoon Forms they have to search for 
 obscure keyword, such as abcforms, or xyzforms, or cforms ;-)
 
 
 To prove the point:
 
  http://www.google.com/search?q=cocoon+formsbtnI=I'm+Feeling+Lucky

My worry was not about finding the main pages, but about finding the
emails and comment postings about issues and solutions that people find.
I guess I will not wory too much, because lazy people (aka good
programmers) will shorten the name Cocoon Forms to cforms to avoid
keystrokes and my searching issue will disappear via this informal
process.  Stefano thinks the versioning will not be a problem, and
since I have other things up my sleeve to attend to, I will defer to
his opinion.  Please consider me happy for now.

--Tim Larson

Re: Cocoon Forms namespaces (was: [SUMMARY] From Woody to Cocoon Forms 1.0)

2004-03-06 Thread Sylvain Wallez

Stefano Mazzocchi wrote:

I would do

  http://apache.org/cocoon/cforms/1.0#definition

so that in the future there is an algorithmical way to get to the 
version.


Hehe, looks like RDF really has infected your mind ;-)

But I like this notation, which makes definition, binding, etc children 
of the more global forms/1.0 entity.

BTW, does this fit with RDDL (I guess yes)?

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: From Woody to CocoonForms

Tim Larson dijo:
 On Sat, Mar 06, 2004 at 08:38:07AM -0500, Vadim Gritsenko wrote:
 Vadim Gritsenko wrote:

 Antonio Gallardo wrote:
 
 Why the c must means something? I think we are missing the point
 here.
 The idea of CForm is to allow easy searching on the Net for Cocoon
 form.
 Just googling:
 
 
 You missed discussion on branding. You suppose to google for Cocoon
 Forms - which means your are searching for Cocoon (brand) Forms
 (functionality). And *no* Cocoon beginner will search for
 abcxyzforms - because they are beginners and they do not know that
 instead of searching for Cocoon Forms they have to search for
 obscure keyword, such as abcforms, or xyzforms, or cforms ;-)


 To prove the point:

  http://www.google.com/search?q=cocoon+formsbtnI=I'm+Feeling+Lucky


 My worry was not about finding the main pages, but about finding the
 emails and comment postings about issues and solutions that people find.
 I guess I will not wory too much, because lazy people (aka good
 programmers) will shorten the name Cocoon Forms to cforms to avoid
 keystrokes and my searching issue will disappear via this informal
 process.  Stefano thinks the versioning will not be a problem, and
 since I have other things up my sleeve to attend to, I will defer to
 his opinion.  Please consider me happy for now.
Tim:

I am +1

Best Regards,

Antonio Gallardo.

DO NOT REPLY [Bug 25021] - [PATCH] ZipArchiveSerializer does not check for non existing files

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25021.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25021

[PATCH] ZipArchiveSerializer does not check for non existing files

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED



--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 20:03 ---
Yes i get the same behaviour with 2.0.5dev, which is a much better behaviour
already then 2.0.4. (In my use-case i still want the zip to be generated even if
entries were not found or invalid, so for me this solution is not adequate). 

Closing this one, thanks for double checking this Jörg.

DO NOT REPLY [Bug 25481] - Caching of aggregated content not working with cocoon:/ protocol

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25481.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25481

Caching of aggregated content not working with cocoon:/ protocol

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 20:23 ---
The suggested workaround to append the parameters to the src uri does the job :
map:part src=cocoon:/nocache?test={1}/

As stated, fixing this in 2.0x is non-trivial.

DO NOT REPLY [Bug 25481] - Caching of aggregated content not working with cocoon:/ protocol

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25481.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25481

Caching of aggregated content not working with cocoon:/ protocol

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

Re: cvs commit: cocoon-2.1/src/blocks/scratchpad/java/org/apache/cocoon/components/source/impl CachingSource.java AsyncCachingSource.java RefresherImpl.java

2004-03-06 Thread Unico Hommes

[EMAIL PROTECTED] wrote:

haul2004/03/06 13:00:39

Modified:src/blocks/scratchpad/java/org/apache/cocoon/components/source/impl
CachingSource.java AsyncCachingSource.java
RefresherImpl.java
Log:
Add log statements for swallowed exceptions
Extract some methods in RefresherImpl
Extract some constants in RefresherImpl
(IOW just moving things around)

Revision ChangesPath
1.6 +18 -4 cocoon-2.1/src/blocks/scratchpad/java/org/apache/cocoon/components/source/impl/CachingSource.java

:-( I had so many changes on my local FS for these classes. I totally
reworked their implemenatations. Not your fault though. I should have
worked more incrementally and checked them in sooner. I'll find a way to
merge it all.

Just to give you an idea of what I am doing here is a quick summary:

Basically I want to move all communication with the Cache into the
Refresher. I am renaming RefresherImpl to DelayRefresher and adding a
Refresher implementation that is externally triggered by events. I am
changing the location protocol string as discussed earlier. Probably can
merge CachingSource and AsynchCachingSource.

I also changed the way DelayRefresher persists its entry configurations
to instead of doing a manual xml serialization of the data just dump the
whole Map of entries into a persistent store.

By the way I think you are the one to ask Christian: I noticed there is
no scheduler.addPeriodicJob(.. Object job, ..) method. Is there a reason
for this or can I add one? So that the Refresher can add itself and its
update targets directly.

Cheers,
Unico

DO NOT REPLY [Bug 27467] - Upgrade all source files to ASF 2.0 license

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467

Upgrade all source files to ASF 2.0 license





--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 22:18 ---
Created an attachment (id=10688)
Please review these files

DO NOT REPLY [Bug 27467] - Upgrade all source files to ASF 2.0 license

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467

Upgrade all source files to ASF 2.0 license





--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 22:31 ---
Now, starting to reverting add Apache licenses on the HTMLArea amd mattkrause
dirs (used in Woody)

First pass at Apache Wiki conversion

2004-03-06 Thread Upayavira

I've been working on converting the JSPWiki Cocoon wiki to MoinMoin 
wiki. This will enable Cocoon to make use of Apache's Wiki farm.

I've now got an initial conversion in place at: 
http://wiki.apache.org/cocoon/

I've converted all pages (except some specifically chosen rubbish 
pages). I haven't yet done anything with attachments. We need to decide 
whether we want to enable them on the new Wiki.

I haven't done that much in terms of converting the syntax. I've been 
more concerned about getting the edit log and history all hanging 
together. There's more I've still got to do.

For those that know Perl regular expressions, here's what I do:

 s#^\*# \*#g; # Bullet lists
 s#\{{2}#\{\{\{#gm; # Inline code snippets
 s#\}{2}#\}\}\}#gm; # Inline code snippets
 s#^\s*\!\!\!(.*)$#= $1 =#gm;   # Largest Heading
 s#^\s*\!\!(.*)$#== $1 ==#gm;  # Middle Heading
 s#^\s*\!(.*)$#=== $1 ===#gm; # Smallest Heading
 s#\[([^\]]+)\|([^\]]+)\]#[$2 $1]#gm; # URIs with labels
 s/^#/ 1./g; # Numbered lists
 # Not yet done:
 # ''Italics''
 # '''bold'''
 # __underline__
 # ^superscript^
 # ,,subscript,,
 # Note:{{{ and }}} can be `backticked`
We need to get the Moin version working well, then we can work out a 
migration process.

Please let me know your comments, publically or privately, so that we 
can get this site working really well.

Regards, Upayavira

Re: cvs commit: cocoon-2.1/src/blocks/scratchpad/java/org/apache/cocoon/components/sou rce/implCachingSource.java AsyncCachingSource.java RefresherImpl.java

Unico:

Is near the day, when we will have JCS as the default Cache system in Cocoon?

I cannot wait. :-)

Best Regards,

Antonio Gallardo

Re: First pass at Apache Wiki conversion

Upayavira dijo:
 I've been working on converting the JSPWiki Cocoon wiki to MoinMoin
 wiki. This will enable Cocoon to make use of Apache's Wiki farm.

Thanks fro your effort.

I already noted many pages are Orphaned:

http://wiki.apache.org/cocoon/OrphanedPages

Best Regards,

Antonio Gallardo

Re: cvs commit: cocoon-2.1/src/blocks/scratchpad/java/org/apache/cocoon/components/sou rce/implCachingSource.java AsyncCachingSource.java RefresherImpl.java

2004-03-06 Thread Unico Hommes

Hi Antonio :-)

Integration of JCS as an excalibur Store service is going pretty well. 
Solved most of the remaining issues I think.

There's one quite fundamental issue on the JCS side that still needs to 
be addressed though. There seems to be a problem flushing the memory 
cache onto disk during shutdown. This effectively means that a lot of 
stuff won't be recoverable between server runs. Obviously this MUST be 
fixed before considering JCS as a caching system for cocoon, let alone 
the default one.

Going by what the guy that helped me on the JCS users mailinglist said 
this is a known issue but no big deal. They just need to put in a simple 
fix.

--
Unico
Antonio Gallardo wrote:
Unico:

Is near the day, when we will have JCS as the default Cache system in Cocoon?

I cannot wait. :-)

Best Regards,

Antonio Gallardo

Performance impact of turning on Instrumentation?

2004-03-06 Thread Andrzej Jan Taramina

Anyone have any insight into what the performance impact is of turning on the 
Instrumentation feature in web.xml (Ver 2.1.4)?

Thanks!

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: Experience with workflow at Hippo Webworks

Guido Casper wrote:

Stefano Mazzocchi wrote:

If FSM work bad for flow, why would they work any better for workflow?
After thinking again about ways to use continuations with workflow I
came to the conclusion this might well be possible. But it looks awkward
to me.
Each document attached to workflow would need a workflow instance as
long as the document lives (from creation to deletion). This would mean
the continuation stack of every document needs to be persisted to - well
- to a database if you don't want to limit your clustering options. The
document has a property holding the continuation ID.
You have a point here, Guido. It is true that continuations in a 
distributed environment would need to be made custer-friendly and 
replicated. This would probably impact the overall performance... but 
keep in mind that continuations are just another way to save state. That 
kind of state transformation (think REST) will have to be done anyway.

Requests for putting a document into another state now simply means (how
simple that really is I have no idea as I'm not familiar with the
details of Rhino or continuations) getting the continuation stack
belonging to the document's continuation ID from the database and resume
processing.
Besides the hassle to maintain the continuation stacks in a database 
there is another drawback IMHO.

Now that I'm able to describe my workflow in a Javascript, how might
that script look like?
Yes, I've been thinking about this myself too. No matter what, I'm 
always scared by the complexity that FSM normally reach, especially if 
they are maintained by more people overtime.

No matter how hard I think about it, it seems I'm unable to come up with
a piece of code that looks simpler than what I have without continuations.
Interesting. would you like to share that with us? I think it would be 
avery good exercise to see the two approaches one beside the other.

Continuations within a webapps are better than a FSMs because the FSM
approach is just a workaround for the lack of a single-threaded view of
my webapp and continuations brought back that view to me. However for
potentially everlasting conditional (and rather detached) workflow state 
transistions FSMs do not look like a workaround to me but like the (or 
one) solution.
I still don't see that, but, admittedly, my experience with complex 
workflows is limited. But I think it would be a great exercise, as I 
said, to try to describe a natural situation in both ways and see which 
one is easier to grasp or feels more natural to people.

Page flow control mostly is rather small pieces of potentially complex
conditional logic with few branches (the user is passively guided
through the page flow) while workflow logic looks like an everlasting
loop of simple conditional logic with potentially lots of branches (the 
user actively triggers the workflow).
I really don't think you can draw a line that easily, but I do see your 
point.

I think it's better to work on a few example of what this might look 
like in the two scenarios (FSM or javascript+continuations) and see what 
happens. WDYT?

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Cocoon Forms namespaces (was: [SUMMARY] From Woody to Cocoon Forms 1.0)