date:20030711

gianugo 2003/07/11 03:27:57

  cocoon-2.1/src/blocks/webdav/conf - New directory

cvs commit: cocoon-2.1/src/blocks/webdav/java/org/apache - New directory

gianugo 2003/07/11 03:27:57

  cocoon-2.1/src/blocks/webdav/java/org/apache - New directory

cvs commit: cocoon-2.1/src/blocks/webdav/java/org/apache/cocoon/components/source/impl - New directory

gianugo 2003/07/11 03:27:58

  cocoon-2.1/src/blocks/webdav/java/org/apache/cocoon/components/source/impl - New 
directory

cvs commit: cocoon-2.1 .cvsignore

cziegeler2003/07/11 03:31:40

  Modified:..cvsignore
  Log:
  Excluding launch conf from cvs
  
  Revision  ChangesPath
  1.3   +1 -0  cocoon-2.1/.cvsignore
  
  Index: .cvsignore
  ===
  RCS file: /home/cvs/cocoon-2.1/.cvsignore,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- .cvsignore27 Jun 2003 20:41:48 -  1.2
  +++ .cvsignore11 Jul 2003 10:31:39 -  1.3
  @@ -3,6 +3,7 @@
   prj.el
   .project
   .classpath
  +cocoon.launch
   local.build.properties
   local.blocks.properties
   cocoon.sampledata

Re: New WebDAV block in CVS

2003-07-11 Thread Daniel Fagerstrom

Gianugo Rabellino wrote:

I just committed a new WebDAV block on CVS (my very first block, so 
please bear with me if I did any mistake). In its current incarnation 
it's a WebDAV Source which is Traversable and Modifiable, we are using 
it already in some of our projects and seems to work fine (despite the 
Slide Webdav client library being far from perfect). 
Cool indeed!

Usage is straigthforward: just point to 
webdav://[host][:port]/[path][?principal=usernamepassword=password] 
to get, write and navigate Webdav resources. 
RFC 1738 - Uniform Resource Locators (URL) 
http://www.ietf.org/rfc/rfc1738.txt (sect. 3.1, 5), suggests:

scheme://[user[:[EMAIL PROTECTED]:port][/path]

for generic url. This syntax for user and password handling seem to be 
supported in Mozilla as well as IE. The syntax that you use seem to be 
pretty common in webapps. Any ideas about if any of the scheemes is 
preferable to the other?

/Daniel

Re: New WebDAV block in CVS

2003-07-11 Thread Gianugo Rabellino

Daniel Fagerstrom wrote:
Usage is straigthforward: just point to 
webdav://[host][:port]/[path][?principal=usernamepassword=password] 
to get, write and navigate Webdav resources. 


RFC 1738 - Uniform Resource Locators (URL) 
http://www.ietf.org/rfc/rfc1738.txt (sect. 3.1, 5), suggests:

scheme://[user[:[EMAIL PROTECTED]:port][/path]

for generic url. This syntax for user and password handling seem to be 
supported in Mozilla as well as IE. The syntax that you use seem to be 
pretty common in webapps. Any ideas about if any of the scheemes is 
preferable to the other?

You are definitely right, and this implementation was was on my todo 
list. Wait for it in the upcoming days, if no one is faster than me. :-)

Ciao,

--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)

Re: Flow Database stuff ( The new FOM? )

2003-07-11 Thread Jeremy Quinn

On Thursday, July 10, 2003, at 09:04 AM, Reinhard Pötz wrote:

IMO no. I would use Object/Relational mapping tools like OJB
http://db.apache.org/ojb/ or Hibernate (http://hibernate.bluemars.net).

Is there a wiki somewhere on this type of thing?
http://wiki.cocoondev.org/ 
Wiki.jsp?page=XMLFormJXFormHibernateAndFlowscr
ipt
and here you find a component providing a Hibernate session:
http://cvs.werken.com/viewcvs.cgi/plexus-components/hibernate
/src/java/org/apache/plexus/hibernate/ 
DefaultHibernateService.java?cvsro
ot=plexus

Forgive me if I have not entirely understood the usage patterns of the  
classes above.

However, with the generous assistance of Ugo Cei, I am successfully  
using the technique highlighted in the first sample here [1] for  
managing Hibernate Sessions in my FlowApp.

The basic issue is that you want to avoid maintaining an open Hibernate  
Session whilst the user is interacting with a form (etc.). The Session  
should to be opened and closed during each Request (and any Transient  
Beans refreshed before re-use). The above technique uses a Servlet  
Filter to manage this, with a static method to retrieve a Session in  
your flowscript at the beginning of each Request that needs it.

[1] http://hibernate.bluemars.net/43.html

HTH

regards Jeremy

RE: Flow Database stuff ( The new FOM? )


 From: Jeremy Quinn 

 
 On Thursday, July 10, 2003, at 09:04 AM, Reinhard Pötz wrote:
 
 
  IMO no. I would use Object/Relational mapping tools like OJB 
  http://db.apache.org/ojb/ or Hibernate 
  (http://hibernate.bluemars.net).
 
 
  Is there a wiki somewhere on this type of thing?
 
  http://wiki.cocoondev.org/
  Wiki.jsp?page=XMLFormJXFormHibernateAndFlowscr
  ipt
  and here you find a component providing a Hibernate session:
  http://cvs.werken.com/viewcvs.cgi/plexus-components/hibernate
  /src/java/org/apache/plexus/hibernate/ 
  DefaultHibernateService.java?cvsro
  ot=plexus
 
 
 Forgive me if I have not entirely understood the usage 
 patterns of the  
 classes above.

IIUC this component provides a Hibernate Session. At the current
FOM implementation you have to take care that you open and close
these sessions correctly.

 
 However, with the generous assistance of Ugo Cei, I am successfully  
 using the technique highlighted in the first sample here [1] for  
 managing Hibernate Sessions in my FlowApp.
 
 The basic issue is that you want to avoid maintaining an open 
 Hibernate  
 Session whilst the user is interacting with a form (etc.). 
 The Session  
 should to be opened and closed during each Request (and any 
 Transient  
 Beans refreshed before re-use). The above technique uses a Servlet  
 Filter to manage this, with a static method to retrieve a Session in  
 your flowscript at the beginning of each Request that needs it.
 
 [1] http://hibernate.bluemars.net/43.html
 

Sounds cool and I remember that I've already heard from it but
haven't found the time to try it myself.


dream-mode
 I would like to use this Avalon component mentioned above and
 the Flow interpreter takes care of releasing (and providing)
 stateful components within my scripts. So I would have to
 lookup the Hibernate Session at the beginning(2) and until I 
 finally release(8) it I don't have to take care for it.

 1  function xxx() {
 2var hibS = cocoon.getComponent( hibernateSession );
 3var custBean = hibS.blablabla // get your beans with hibernate
 4sendPageAndWait( bla, {customer : custBean} );
 5// do something (updates, reads, whatever)
 6var someDifferentBean = hibS.blalbalba
 7sendPageAndWait( bla, {diff : someDifferentBean } );
 8sendPageAndRelease( thankYou, {} );
 9  }

 This would be IMO a very elegant way and IIU the recent discussion
 correctly possible from a technical point of view. Maybe Chris
 can comment on this :-)

 Thoughts?

/dream-mode


Cheers,
Reinhard

cvs commit: cocoon-2.1/src/blocks/taglib/java/org/apache/cocoon/jxpath JXPathCocoonContexts.java

cziegeler2003/07/11 07:17:44

  Modified:src/java/org/apache/cocoon/components
RequestLifecycleComponent.java
CocoonComponentManager.java
   src/blocks/taglib/java/org/apache/cocoon/jxpath
JXPathCocoonContexts.java
  Added:   src/java/org/apache/cocoon/components
GlobalRequestLifecycleComponent.java
  Log:
  Adding global request lifecycle component
  
  Revision  ChangesPath
  1.2   +16 -12
cocoon-2.1/src/java/org/apache/cocoon/components/RequestLifecycleComponent.java
  
  Index: RequestLifecycleComponent.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/RequestLifecycleComponent.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- RequestLifecycleComponent.java9 Mar 2003 00:08:46 -   1.1
  +++ RequestLifecycleComponent.java11 Jul 2003 14:17:44 -  1.2
  @@ -50,26 +50,30 @@
   */
   package org.apache.cocoon.components;
   
  +import java.io.IOException;
  +import java.util.Map;
  +
   import org.apache.avalon.excalibur.pool.Poolable;
  -import org.apache.avalon.framework.component.Component;
   import org.apache.cocoon.ProcessingException;
   import org.apache.cocoon.environment.SourceResolver;
   import org.xml.sax.SAXException;
   
  -import java.io.IOException;
  -import java.util.Map;
  -
   /**
  - * Objects implementing this marker interface have a lifecycle of one
  - * request. This means if one request is looking up several times
  - * an object implementing this interface, it's always the same object.
  - * In addition, the first time this object is looked up during a request,
  - * the setup() method is called
  - *
  + * Components implementing this marker interface have a lifecycle of one
  + * request. This means if during one request a component accepting this
  + * interface is looked up several times, it's always the same instance.
  + * Each internal subrequest, e.g. using the cocoon protocol, is considered
  + * as a new request. So an instance looked up in the main request is
  + * not available to a subrequest.
  + * In addition, the first time this component is looked up during a request,
  + * the [EMAIL PROTECTED] setup(SourceResolver, Map)} method is called.
  + * 
  + * @see org.apache.cocoon.components.GlobalRequestLifecycleComponent
  + * 
* @author a href=mailto:[EMAIL PROTECTED]Carsten Ziegeler/a
* @version CVS $Id$
*/
  -public interface RequestLifecycleComponent extends Component, Poolable {
  +public interface RequestLifecycleComponent extends Poolable {
   
   /**
* Set the [EMAIL PROTECTED] SourceResolver} and the objectModel 
  
  
  
  1.15  +108 -15   
cocoon-2.1/src/java/org/apache/cocoon/components/CocoonComponentManager.java
  
  Index: CocoonComponentManager.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/CocoonComponentManager.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- CocoonComponentManager.java   10 Jul 2003 13:17:04 -  1.14
  +++ CocoonComponentManager.java   11 Jul 2003 14:17:44 -  1.15
  @@ -93,8 +93,7 @@
   {

   /** The key used to store the current process environment */
  -private static final String PROCESS_KEY =
  -   org.apache.cocoon.components.CocoonComponentManager;
  +private static final String PROCESS_KEY = 
CocoonComponentManager.class.getName();

   
   /** The environment information */
  @@ -164,7 +163,21 @@
*/
   public static void leaveEnvironment() {
   final EnvironmentStack stack = (EnvironmentStack)environmentStack.get();
  -stack.pop();
  +final Object[] objs = (Object[])stack.pop();
  +if ( stack.isEmpty() ) {
  +final Environment env = (Environment)objs[0];
  +final Map globalComponents = 
(Map)env.getAttribute(GlobalRequestLifecycleComponent.class.getName());
  +if ( globalComponents != null) {
  +
  +final Iterator iter = globalComponents.values().iterator();
  +while ( iter.hasNext() ) {
  +final Object[] o = (Object[])iter.next();
  +final Component c = (Component)o[0];
  +((CocoonComponentManager)o[1]).releaseRLComponent( c );
  +}
  +}
  +env.removeAttribute(GlobalRequestLifecycleComponent.class.getName());
  +}
   }
   
   /**
  @@ -288,7 +301,11 @@
   final Map objectModel = ((Environment)objects[0]).getObjectModel();
   EnvironmentDescription desc = 
(EnvironmentDescription)objectModel.get(PROCESS_KEY);
   if ( null != desc

cvs commit: cocoon-2.1 status.xml

cziegeler2003/07/11 07:20:35

  Modified:.status.xml
  Log:
  Adding global request lifecycle component
  
  Revision  ChangesPath
  1.86  +4 -1  cocoon-2.1/status.xml
  
  Index: status.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/status.xml,v
  retrieving revision 1.85
  retrieving revision 1.86
  diff -u -r1.85 -r1.86
  --- status.xml11 Jul 2003 08:59:03 -  1.85
  +++ status.xml11 Jul 2003 14:20:35 -  1.86
  @@ -184,6 +184,9 @@
 changes
   
release version=@version@ date=@date@
  +  action dev=CZ type=add
  +   Adding global request lifecycle component.
  +  /action
 action dev=CZ type=update
  The cache used by the caching processing pipeline is now configurable
  allowing to use different caches in different pipelines.

cvs commit: cocoon-2.1/src/blocks/webdav/lib slide-webdavlib-20030711.jar slide-webdavlib.jar

gianugo 2003/07/11 07:29:16

  Modified:.status.xml
   lib  jars.xml
  Added:   src/blocks/webdav/lib slide-webdavlib-20030711.jar
  Removed: src/blocks/webdav/lib slide-webdavlib.jar
  Log:
  Updated the webdavlib jar to the naming rules. Sync status.xml
  
  Revision  ChangesPath
  1.87  +9 -1  cocoon-2.1/status.xml
  
  Index: status.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/status.xml,v
  retrieving revision 1.86
  retrieving revision 1.87
  diff -u -r1.86 -r1.87
  --- status.xml11 Jul 2003 14:20:35 -  1.86
  +++ status.xml11 Jul 2003 14:29:15 -  1.87
  @@ -184,6 +184,14 @@
 changes
   
release version=@version@ date=@date@
  +  action dev=GR type=add
  +   Added a WebDAV block, with an initial implementation of
  +   a modifiable and traversable WebDAV source.
  +  /action
  +  action dev=GR type=add
  +   Added a DirectoryGenerator implementation on scratchpad 
  +   working on any Traversable Source.
  +  /action
 action dev=CZ type=add
  Adding global request lifecycle component.
 /action
  
  
  
  1.63  +2 -2  cocoon-2.1/lib/jars.xml
  
  Index: jars.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/lib/jars.xml,v
  retrieving revision 1.62
  retrieving revision 1.63
  diff -u -r1.62 -r1.63
  --- jars.xml  11 Jul 2003 10:32:35 -  1.62
  +++ jars.xml  11 Jul 2003 14:29:16 -  1.63
  @@ -689,7 +689,7 @@
 titleSlide WebDAV Client library/title
 descriptionThe Jakarta Slide WebDAV client library./description
 used-byWebDAV block/used-by
  -  libwebdav/lib/slide-webdavlib.jar/lib
  +  libwebdav/lib/slide-webdavlib-20030711.jar/lib
 homepagehttp://jakarta.apache.org/slide//homepage
/file
   
  
  
  
  1.1  cocoon-2.1/src/blocks/webdav/lib/slide-webdavlib-20030711.jar
  
Binary file

multithreading in Cocoon-2.1, multithreaded ContentAggregator

2003-07-11 Thread Christoph Gaffga

hi,
I had some difficulties making the ContentAggregator multithreaded. Now it
works, but there are still some open questions. One in dealing with
CocoonComponentManager, the other about the best design for the aggreagator.

(1) synchronization in CocoonComponentManager
-
I always had null-pointer exceptions and index out of bound when processing
multiple parts for the aggregator in parallel in different threads.
It works when I declare the following methods in CocoonComponentManager as
synchronized:
  enterEnvironment,
  leaveEnvironment,
  startProcessing,
  endProcessing,
  addComponentForAutomaticRelease,
  removeFromAutomaticRelease,
  in EnvironmentDescription (same file) I also decleared
addtoAutorelease and
removeFromAutoRelease as synchronized

But I think this is only a workaround, so Im not realy sure what has to be
fixed to have a thread-safe implementation. I would apreciate any
information about how to go on.

(2) best practice for implementing aggregator
-
What would be the best practice for the implementation of the multithreaded
ContentAggregator. I think there are to possibilities:

 a. Make it using IncludeCacheManager, that's the way the
CIncludeTransformer includes it's content, and it's the way my current
implementation works.

 b. Make it using SourceUtil.toSAX and MirrorRecorder. That would be a more
lightwight implementation than using all the CacheManagerSession stuff. But
it didn't work. With this way of implemeting it I had trouble with the
ComponentManager again.

So, does anybody know what exactly the IncludeCacheManagerSession does? I
could'n find something that seems to be so special, like creating a new
Environment/ComponentManager. Does anybody know anything about it?


How is the interest about having another implementation of ContentAggregator
within cocoon? And, is there anybody who could help me to get the
ComponentManager thread-safe?

Regards,
Christoph Gaffga
[EMAIL PROTECTED]

P.S. If anybody is interested in the code, I'll send it over if requested.

cvs commit: cocoon-2.1/src/documentation/xdocs/installing updating.xml

cziegeler2003/07/11 08:10:21

  Modified:src/documentation/xdocs/installing updating.xml
  Log:
  Updating the update doc
  
  Revision  ChangesPath
  1.15  +11 -0 cocoon-2.1/src/documentation/xdocs/installing/updating.xml
  
  Index: updating.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/installing/updating.xml,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- updating.xml  2 Jul 2003 07:21:03 -   1.14
  +++ updating.xml  11 Jul 2003 15:10:20 -  1.15
  @@ -120,6 +120,9 @@
  Due to some interface changes in the Cocoon logging components, custom java
  components (generators,transformers or actions for example) compiled for 
Cocoon 2.0.x will not run
  under Cocoon 2.1 unless recompiled./p
  +   pIt's also advisable to change your implementations from using 
emLogEnabled/em
  + instead of emLoggable/em when it comes to logging in your components.
  +   /p
 /s1
 s1 title=Components
  p
  @@ -237,6 +240,14 @@
   emorg.apache.cocoon.servlet.multipart.Part/em, and the 
emgetFilePath()/em has been renamed
   emPart.getUploadName()./em
/p
  +   /s2
  +   s2 title=RequestLifeCycleComponent
  +pIf you are using the marker interface emRequestLifeCycleComponent/em for 
your
  +own components, you have to make sure that your implementations still implement
  +the emComponent/em interface. The emRequestLifeCycleComponent/em does no
  +longer extend the emComponent/em interface, so you have to declare it in 
your
  +own components together with emRequestLifeCycleComponent/em. Otherwise you
  +will get a emClassCastException/em as soon as you access your component./p
  /s2
 /s1
 s1 title=Components from the scratchpad

RE: Flow Database stuff ( The new FOM? )


From: Jeremy Quinn

 The problem arises when you wish to use a (brilliant) feature of 
 Hibernate called 'lazy-initialisation', whereby access to the DB is 
 only made when you actually ask for Bean Properties.
 
 This is particularly useful when you have large 'graphs' of related 
 Beans, for instance child/parent relationships, whereby loading one 
 Bean may result in the whole database loading!!
 
 If you have closed your Hibernate Session in your Flowscript, your 
 display layer can throw LazyInitialisationExceptions, because the 
 connection is no longer available.
 
 Not closing the Session after you have sent the Response, is 
 considered 
 bad practise, so the Servlet Filter is a handy solution.

It's a pity that Hibernate is under LGPL - this would be a great example
...
Have the Hibernate people ever been asked if they would put their
great piece of software under a more Apache like licence?

As I'm curious I have a technical question:
What's the difference if I read the necessary data in the flow or some
milliseconds latter in the view layer? What do I gain?


  However, with the generous assistance of Ugo Cei, I am 
 successfully 
  using the technique highlighted in the first sample here [1] for 
  managing Hibernate Sessions in my FlowApp.
 
  The basic issue is that you want to avoid maintaining an open 
  Hibernate Session whilst the user is interacting with a 
 form (etc.).
  The Session
  should to be opened and closed during each Request (and any
  Transient
  Beans refreshed before re-use). The above technique uses a Servlet
  Filter to manage this, with a static method to retrieve a 
 Session in
  your flowscript at the beginning of each Request that needs it.
 
  [1] http://hibernate.bluemars.net/43.html
 
 
  Sounds cool and I remember that I've already heard from it 
 but haven't 
  found the time to try it myself.
 
 I am using it ATM on a client project and it is a dream!
 
  dream-mode
   I would like to use this Avalon component mentioned above and  the 
  Flow interpreter takes care of releasing (and providing)  stateful 
  components within my scripts. So I would have to  lookup 
 the Hibernate 
  Session at the beginning(2) and until I  finally release(8) 
 it I don't 
  have to take care for it.
 
   1  function xxx() {
   2var hibS = cocoon.getComponent( hibernateSession );
   3var custBean = hibS.blablabla // get your beans with hibernate
   4sendPageAndWait( bla, {customer : custBean} );
   5// do something (updates, reads, whatever)
   6var someDifferentBean = hibS.blalbalba
   7sendPageAndWait( bla, {diff : someDifferentBean } );
   8sendPageAndRelease( thankYou, {} );
   9  }
 
   This would be IMO a very elegant way and IIU the recent 
 discussion  
  correctly possible from a technical point of view. Maybe Chris  can 
  comment on this :-)
 
   Thoughts?
 
 This is a reality!
 Wake up and smell the toast ;)

;-)

 
 I just do not use the Component Manager, because I cannot manage the 
 Hibernate Session entirely from the FlowScript layer as explained 
 above. I have a static method that gives me a fresh Session. I get s 
 Session at the beginning of  Function, or directly after a 
 sendPageAndWait().

Is it possible to have a look at the sources? I would be very
interested!

Cheers,
Reinhard

Re: Flow Database stuff ( The new FOM? )

Will the attached work?

Reinhard Pötz wrote:



dream-mode
I would like to use this Avalon component mentioned above and
the Flow interpreter takes care of releasing (and providing)
stateful components within my scripts. So I would have to
lookup the Hibernate Session at the beginning(2) and until I 
finally release(8) it I don't have to take care for it.

1  function xxx() {
2var hibS = cocoon.getComponent( hibernateSession );
3var custBean = hibS.blablabla // get your beans with hibernate
4sendPageAndWait( bla, {customer : custBean} );
5// do something (updates, reads, whatever)
6var someDifferentBean = hibS.blalbalba
7sendPageAndWait( bla, {diff : someDifferentBean } );
8sendPageAndRelease( thankYou, {} );
9  }
This would be IMO a very elegant way and IIU the recent discussion
correctly possible from a technical point of view. Maybe Chris
can comment on this :-)
Thoughts?

/dream-mode

Cheers,
Reinhard
 


/*

 
   The Apache Software License, Version 1.1
 

 Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.

 Redistribution and use in source and binary forms, with or without modifica-
 tion, are permitted provided that the following conditions are met:

 1. Redistributions of  source code must  retain the above copyright  notice,
this list of conditions and the following disclaimer.

 2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.

 3. The end-user documentation included with the redistribution, if any, must
include  the following  acknowledgment:  This product includes  software
developed  by the  Apache Software Foundation  (http://www.apache.org/).
Alternately, this  acknowledgment may  appear in the software itself,  if
and wherever such third-party acknowledgments normally appear.

 4. The names Apache Cocoon and  Apache Software Foundation must  not  be
used to  endorse or promote  products derived from  this software without
prior written permission. For written permission, please contact
[EMAIL PROTECTED]

 5. Products  derived from this software may not  be called Apache, nor may
Apache appear  in their name,  without prior written permission  of the
Apache Software Foundation.

 THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
 FITNESS  FOR A PARTICULAR  PURPOSE ARE  DISCLAIMED.  IN NO  EVENT SHALL  THE
 APACHE SOFTWARE  FOUNDATION  OR ITS CONTRIBUTORS  BE LIABLE FOR  ANY DIRECT,
 INDIRECT, INCIDENTAL, SPECIAL,  EXEMPLARY, OR CONSEQUENTIAL  DAMAGES (INCLU-
 DING, BUT NOT LIMITED TO, PROCUREMENT  OF SUBSTITUTE GOODS OR SERVICES; LOSS
 OF USE, DATA, OR  PROFITS; OR BUSINESS  INTERRUPTION)  HOWEVER CAUSED AND ON
 ANY  THEORY OF LIABILITY,  WHETHER  IN CONTRACT,  STRICT LIABILITY,  OR TORT
 (INCLUDING  NEGLIGENCE OR  OTHERWISE) ARISING IN  ANY WAY OUT OF THE  USE OF
 THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

 This software  consists of voluntary contributions made  by many individuals
 on  behalf of the Apache Software  Foundation and was  originally created by
 Stefano Mazzocchi  [EMAIL PROTECTED]. For more  information on the Apache
 Software Foundation, please see http://www.apache.org/.

*/
package org.apache.cocoon.components.flow.javascript.fom;

import java.io.OutputStream;
import java.util.Enumeration;
import java.util.Iterator;
import java.util.LinkedList;
import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.HashSet;
import org.apache.avalon.framework.component.Component;
import org.apache.avalon.framework.component.ComponentManager;
import org.apache.avalon.framework.logger.Logger;
import org.apache.cocoon.components.flow.ContinuationsManager;
import org.apache.cocoon.components.flow.WebContinuation;
import org.apache.cocoon.environment.Cookie;
import org.apache.cocoon.environment.Environment;
import org.apache.cocoon.environment.ObjectModelHelper;
import org.apache.cocoon.environment.Request;
import org.apache.cocoon.environment.Response;
import org.apache.cocoon.environment.Session;
import org.mozilla.javascript.*;
import org.mozilla.javascript.continuations.Continuation;

/**
 * Implementation of FOM (Flow Object Model).
 *
 * @since 2.1 
 * @author a href=mailto:coliver.at.apache.org;Christopher Oliver/a
 * @author a href=mailto:reinhard.at.apache.org;Reinhard Pötz/a
 * @version CVS $Id: FOM_Cocoon.java,v 1.3 2003/07/10 11:40:57 cziegeler Exp $
 */

public class FOM_Cocoon extends ScriptableObject {

private FOM_JavaScriptInterpreter interpreter;

private Environment environment;
private

cvs commit: cocoon-2.1/src/blocks/jsp/mocks/weblogic/servlet/internal ServletContextImpl.java ServletResponseImpl.java ServletOutputStreamImpl.java

2003-07-11 Thread joerg

joerg   2003/07/11 10:03:27

  Modified:src/blocks/jsp/mocks/weblogic/servlet/internal
ServletContextImpl.java ServletResponseImpl.java
ServletOutputStreamImpl.java
  Log:
  added deprecation warnings (push through from ServletContext) to avoid possible 
usage in JSPEngineImplWLS class
  
  Revision  ChangesPath
  1.2   +10 -2 
cocoon-2.1/src/blocks/jsp/mocks/weblogic/servlet/internal/ServletContextImpl.java
  
  Index: ServletContextImpl.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/jsp/mocks/weblogic/servlet/internal/ServletContextImpl.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ServletContextImpl.java   9 Mar 2003 00:04:16 -   1.1
  +++ ServletContextImpl.java   11 Jul 2003 17:03:27 -  1.2
  @@ -63,7 +63,7 @@
*  This is a mock object of the class, not the actual class.
*  It's used to compile the code in absence of the actual class.
*
  - *  This clsss is created by hand, not automatically.
  + *  This class is created by hand, not automatically.
*
* **
* 
  @@ -72,6 +72,8 @@

   public class ServletContextImpl implements ServletContext{
   
  +/** @deprecated The method ServletContextImpl.getServlets() overrides a
  + *  deprecated method from ServletContext */
   public Enumeration getServlets(){
   return null;
   }
  @@ -120,14 +122,20 @@
   return ;
   }
   
  +/** @deprecated The method ServletContextImpl.getServletNames() overrides
  + *  a deprecated method from ServletContext */
   public Enumeration getServletNames(){
   return null;
   }
   
  +/** @deprecated The method ServletContextImpl.getServlet(String) overrides
  + *  a deprecated method from ServletContext */
   public Servlet getServlet(String string){
   return null;
   }
   
  +/** @deprecated The method ServletContextImpl.log(Exception, String)
  + *  overrides a deprecated method from ServletContext */
   public void log(Exception exception, String string){
   }
   
  
  
  
  1.2   +8 -2  
cocoon-2.1/src/blocks/jsp/mocks/weblogic/servlet/internal/ServletResponseImpl.java
  
  Index: ServletResponseImpl.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/jsp/mocks/weblogic/servlet/internal/ServletResponseImpl.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ServletResponseImpl.java  9 Mar 2003 00:04:16 -   1.1
  +++ ServletResponseImpl.java  11 Jul 2003 17:03:27 -  1.2
  @@ -62,7 +62,7 @@
*  This is a mock object of the class, not the actual class.
*  It's used to compile the code in absence of the actual class.
*
  - *  This clsss is created by hand, not automatically.
  + *  This class is created by hand, not automatically.
*
* **
* 
  @@ -98,6 +98,8 @@
   return false;
   }
   
  +/** @deprecated The method ServletResponseImpl.encodeRedirectUrl(String)
  + *  overrides a deprecated method from HttpServletResponse */
   public String encodeRedirectUrl(String arg1) {
   return null;
   }
  @@ -106,6 +108,8 @@
   return null;
   }
   
  +/** @deprecated The method ServletResponseImpl.encodeUrl(String) overrides
  + *  a deprecated method from HttpServletResponse */
   public String encodeUrl(String arg1) {
   return null;
   }
  @@ -207,6 +211,8 @@
   public void setStatus(int status) {
   }
   
  +/** @deprecated The method ServletResponseImpl.setStatus(int, String)
  + *  overrides a deprecated method from HttpServletResponse */
   public void setStatus(int arg1, String arg2) {
   }
   
  
  
  
  1.2   +2 -2  
cocoon-2.1/src/blocks/jsp/mocks/weblogic/servlet/internal/ServletOutputStreamImpl.java
  
  Index: ServletOutputStreamImpl.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/jsp/mocks/weblogic/servlet/internal/ServletOutputStreamImpl.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ServletOutputStreamImpl.java  9 Mar 2003 00:04:16 -   1.1
  +++ ServletOutputStreamImpl.java  11 Jul 2003 17:03:27 -  1.2
  @@ -62,7 +62,7 @@
*  This is a mock object of the class, not the actual class.
*  It's used to compile the code in absence of the actual class.
*
  - *  This clsss is created by hand, not automatically.
  + *  This class is created by hand, not automatically.
*
*

RE: Flow Database stuff ( The new FOM? )

2003-07-11 Thread Hugo Burm


Hello,

I tried to raise this LGPL issue in the Hibernate community.
The answer of Gaving King and Cristian Bauer was: we stick to LGPL untill we
have a compelling reason (a real case) to change our minds.
I did not try to explain that Apache is refusing LGPL altogether.


Hugo


-Original Message-
From: Reinhard Pötz [mailto:[EMAIL PROTECTED]
Sent: Friday, July 11, 2003 6:46 PM
To: [EMAIL PROTECTED]
Subject: RE: Flow Database stuff ( The new FOM? )


It's a pity that Hibernate is under LGPL - this would be a great example
...
Have the Hibernate people ever been asked if they would put their
great piece of software under a more Apache like licence?


Cheers,
Reinhard

JXForms Concerns/Questions

2003-07-11 Thread Chris Clark

 I'm involved in a large development project that will involve a lot of large form 
 filling out/processing.  We are planning on using Cocoon and have laid out a UI 
 model.  Currently we're trying to decide on a form architecture and after looking at 
 samples and docs, there are a few things we'd like to raise here--don't need to 
 focus on how-to's, but rather architectural implications.
 
 1) Do you need a separate flowscript and therefore a separate sitemap for each 
 JXForm?  The samples imply that each form has to have a script and each script is 
 associated with a sitemap.  This would lead to a huge number of subdirectories and 
 sub-sitemaps for our project which is not desirable.  We can live with one java 
 class/form as XMLForm seems to need, but one directory with a script and associated 
 pages per form is unacceptable.
 
 2) For a simple, one-page form, do you need to have a script?  Is there a sample of 
 a single-page form using JXForm?
 
 3) Do you have to use javascript with flow or can you substitute something else (a 
 java class)?  We don't have any experience with javascript and were hoping to keep 
 our development technologies limited to XML/HTML, XSLT and Java classes.
 
 4) Is it possible to dynamically pre-populate a JXForm from a database?  The sample 
 has the data hard-coded and as we're not javascript fluent, we don't know if it's 
 possible.
 
 5) We have some concerns with the continuation model's scalability.  Making the 
 assumption that there is something memory-resident on the server side, how does one 
 clean up old continuation objects?  what is the lifecycle?  what is the memory 
 footprint?
 
6) Regarding the recent discussions of refactoring JXForm and XMLForms and possible 
deprecation of the Cocoon XMLForm codebase.  If we embark on an XMLForm development 
effort - which we were planning to do, we are concerned about impact to our project.  
Will the Cocoon committers consider continued support of XMLForms?

7) If XMLForms code base is retained, is the community considering refactoring 
enhancements in XMLForm.org code base back into Cocoon XMLForm codebase?  We would be 
very interested in this.

And one specific question:

8) JXForm documentation in general - is there any/where is it?  (I haven't been able 
to find anything.)

Sorry for the length, but we're at a crucial decision point in our project and as 
Cocoon seems to be at a similarly crucial decision point, we felt it worthwhile to ask 
these questions.

Thanks,
J. Chris Clark
Senior Developer
Teraview Development

Teranet Inc.
1 Adelaide St. E.
Toronto, ON, M5C 2V9
416.360.8863x2413
[EMAIL PROTECTED]

Proud to be one of Canada's Top 100 Employers 2003
http://www.teranet.ca/corporate/news/top100.html


The information in this email is confidential and may be legally privileged. It is 
intended solely for the addressee. Access to this email by anyone else is 
unauthorized. If you are not the intended recipient, any disclosure, copying, 
distribution or any action taken or omitted to be taken in reliance on it, is 
prohibited and may be unlawful.

Re: Flow Database stuff ( The new FOM? )

Reinhard Pötz wrote:

Hi Chris,

I'll give it a try this weekend.

To understand the changes: In a function with continuations I
call a component once and if sendPageAndWait() is called the
component is released automatically. If the continuation
created is called later the variable with a pointer to a
component will be reassigned with a newly created component of
the same type?
 

Yep.

I know this sounds very disbelieving but I wrote my mail only
a few hours ago and you come up with a solution ... ;-)
 

I had already prototyped it. I didn't write it after you sent your message.

Another question: The JXTemplate* stuff and the petstore are
moved to the main trunk or a block. Do you plan to move the 
JXForms into the XMLForms package? (I want to avoid duplicate 
work because could have time this weekend doing it but can't 
promise it now.) So if you have time don't hesitate ;-)
 

I think it would be easiest to move it to its own block. Then we could 
deprecate XMLForm and those who are using it won't get broken. I'm not 
sure how you would merge it with the XMLForm block, anyway. If making 
JXForms its own block is ok, then I can do that. Otherwise, I don't 
think I'll be able to spend time merging it with XMLForm.

Cheers,
Reinhard
 

-Original Message-
From: Christopher Oliver [mailto:[EMAIL PROTECTED] 
Sent: Friday, July 11, 2003 6:56 PM
To: [EMAIL PROTECTED]
Subject: Re: Flow Database stuff ( The new FOM? )

Will the attached work?

Reinhard Pötz wrote:

   

dream-mode
I would like to use this Avalon component mentioned above and  the 
Flow interpreter takes care of releasing (and providing)  stateful 
components within my scripts. So I would have to  lookup the 
 

Hibernate 
   

Session at the beginning(2) and until I  finally release(8) 
 

it I don't 
   

have to take care for it.

1  function xxx() {
2var hibS = cocoon.getComponent( hibernateSession );
3var custBean = hibS.blablabla // get your beans with hibernate
4sendPageAndWait( bla, {customer : custBean} );
5// do something (updates, reads, whatever)
6var someDifferentBean = hibS.blalbalba
7sendPageAndWait( bla, {diff : someDifferentBean } );
8sendPageAndRelease( thankYou, {} );
9  }
This would be IMO a very elegant way and IIU the recent discussion 
correctly possible from a technical point of view. Maybe Chris can 
comment on this :-)

Thoughts?

/dream-mode

Cheers,
Reinhard

Re: JXForms Concerns/Questions

Chris Clark wrote:

I'm involved in a large development project that will involve a lot of large form filling out/processing. We are planning on using Cocoon and have laid out a UI model. Currently we're trying to decide on a form architecture and after looking at samples and docs, there are a few things we'd like to raise here--don't need to focus on how-to's, but rather architectural implications.

1) Do you need a separate flowscript and therefore a separate sitemap for each JXForm?

No. See the petstore example. You just need a separate function. All
your functions can be in one script.

The samples imply that each form has to have a script and each script is associated with a sitemap. This would lead to a huge number of subdirectories and sub-sitemaps for our project which is not desirable. We can live with one java class/form as XMLForm seems to need, but one directory with a script and associated pages per form is unacceptable.

2) For a simple, one-page form, do you need to have a script? Is there a sample of a single-page form using JXForm?

Yes, you do. Because there will be actions you take to process the form.
These are triggered by the script.

function onePageForm(form) {
var obj = new MyJavaObject();
form.setModel(obj);
form.sendView(theOnlyPage.xml);
// A validated form has been submitted,
// process the form here:
obj.processForm()
}
3) Do you have to use javascript with flow or can you substitute something else (a java class)? We don't have any experience with javascript and were hoping to keep our development technologies limited to XML/HTML, XSLT and Java classes.

You can easily call any Java code from your flow script:

var map = new java.util.HashMap();
map.put(foo, bar);
See: http://wiki.cocoondev.org/Wiki.jsp?page=JavascriptForJavaProgrammers

4) Is it possible to dynamically pre-populate a JXForm from a database?

Yes, of course. See the petstore sample and the below link:

http://wiki.cocoondev.org/Wiki.jsp?page=XMLFormJXFormHibernateAndFlowscript

The sample has the data hard-coded and as we're not javascript fluent, we don't know if it's possible.

5) We have some concerns with the continuation model's scalability. Making the assumption that there is something memory-resident on the server side, how does one clean up old continuation objects? what is the lifecycle? what is the memory footprint?

You can explicitly release continuations, or you can configure garbage
collection for them based on a timer.
Continuations use relatively little dynamic memory (basically they just
contain the program counter and a reference to an array of local
variables for each call frame).

6) Regarding the recent discussions of refactoring JXForm and XMLForms and possible deprecation of the Cocoon XMLForm codebase. If we embark on an XMLForm development effort - which we were planning to do, we are concerned about impact to our project. Will the Cocoon committers consider continued support of XMLForms?

I won't. Maybe others will.

7) If XMLForms code base is retained, is the community considering refactoring enhancements in XMLForm.org code base back into Cocoon XMLForm codebase? We would be very interested in this.

I'm sure any contribution will be considered. What enhancements are you
interested in?

And one specific question:

8) JXForm documentation in general - is there any/where is it? (I haven't been able to find anything.)

Sorry, there's nothing available yet (I can't promise, but maybe next
week I'll have time to work on that). But I believe JXForms is nearly
identical to the updated XMLForm syntax on xmlform.org.

Sorry for the length, but we're at a crucial decision point in our project and as Cocoon seems to be at a similarly crucial decision point, we felt it worthwhile to ask these questions.

Thanks,
J. Chris Clark
Senior Developer
Teraview Development
Teranet Inc.
1 Adelaide St. E.
Toronto, ON, M5C 2V9
416.360.8863x2413
[EMAIL PROTECTED]
Proud to be one of Canada's Top 100 Employers 2003
http://www.teranet.ca/corporate/news/top100.html
The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.

JXForms/XMLForms



From: Christopher Oliver

 I think it would be easiest to move it to its own block. Then 
 we could 
 deprecate XMLForm and those who are using it won't get 
 broken. I'm not 
 sure how you would merge it with the XMLForm block, anyway. If making 
 JXForms its own block is ok, then I can do that. Otherwise, I don't 
 think I'll be able to spend time merging it with XMLForm.

From a **Forms user's point of view there are following points
interesting:

   - the syntax how to describe the form  
 -- different
   - validation rules (schematron)
 -- should be the same
   - the controller
 -- the BIG difference

All other things shouldn't be of much interest for them. So I'm fine
with making
the XMLForms block a deprecated block and create a new one without the
XMLFormsTransformer but the JXFormsGenerator/Transformer instead. The
remaining
question is the different syntax which will cause problems if you want
to migrate.

Which implementation uses the standard described by the W3C?

The second difference is the controller. I should be possible to use the
Actions framework to control the forms, shouldn't it? I only had a brief
look into the sources ...

What do you think?

Reinhard

RE: Flow Database stuff ( The new FOM? )


From: Hugo Burm

 Hello,
 
 This dreammode is almost a reality. See the Wiki pages on Hibernate.
 
 Main spoilers are:
 
 - A user can quit in the middle of your function xxx (e.g. by 
 closing the browser). This will generate a zombie Hibernate 
 session. Jeremy and Ugo are using a workaround based on an 
 newer version of the servlet api.

Maybe Chris' latest prototyp of FOM_Cocoon can help to manage
the zombie session problem.

 
 - Hibernate is LGPL.
 This is a pain in the ass. I cannot provide a ready-to-use 
 Hibernate cocoon block because of LGPL versus Apache license issues.

We (the Cocoon community) should contact them. Maybe there's a chance
...

Cheers,
Reinhard

Re: [RT] Less is More, Finite State Machines and Balkanization

2003-07-11 Thread Berin Loritsch

Long story short:

Dmmmn!  Well said Stefano!

More info in line.

Stefano Mazzocchi wrote:

snip/

Polymorphism is a great technical concept, but it's an incredibly poor
community tool: it creates balkanization.
The Avalon people know very well what I'm talking about.
Now with one of our chief reasons blocking cooperation gone, we are starting
some evolutionary growth in all of our modern containers toward one standard.
We are starting small--we have three very different ways of recording meta
information, which we are unifying.  That said, here are some things which
is helping us toward our goals:
* We have three modern containers with different requirements.  It may sound
  bad, but you need that many different implementations to get close to a
  generic solution.
* We are adopting a more XP approach to the world.  Start small and add as
  necessary.  Adding tests first help us stay honest (although this is slow
  in comming--we are behind).
* The different implementations help us understand what is necessary and
  what isn't.  Designing for simplicity is difficult.  We are not there
  yet, but two people who have migrated from ECM based projects to Fortress
  were very impressed with just how easy it was.  That wasn't by accident.
You may ask, Aren't you standardizing on one way of doing things?  My answer
is yes.  It took a couple of tries to find out what was *good enough*.  We
also are learning how to balance contract strength and usability.
Change is a constant ;P  We are learning to provide our users with the tools
to allow that change without major rework to their projects.
snip/

   - o -

I learned programming at the age of 8, writing BASIC on a Commodore
Vic20. I did BASIC until high school when, at the age of 13, I was
*forced* to learn Pascal.
Ok, I started late.  I was 12 with a Commodore 64.  I jumped from BASIC
to Assembly.
Unlike your experiences, Borland Assembler for the C64 provided a really
nice feature:  labels.  I could put a label any place I needed to jump,
and the compiler would take care of the line numbers.  It even had some
relative labels that were used for conditionals and loops.  Awesome stuff.

Marc is advocating that there is more than just continuation-based flow
control and he is dead right: there are as many ways to implement flow
control as there are stars in the sky.
But there are two major families of approaches: procedural vs. declarative.

The continuation-based flow is procedural. What Marc is proposing in his
wiki page is declerative. state oriented. in short, it's a FSM. it's the
goto equivalent for the web.
I'm sorry, but I cannot stop considering this harmful. or, at least, a
poor substitute (for this kind of usage) for what we achieved with
continuation-based produceral flow descriptions.
The thing you have to ask yourself is what is being modeled?.  The whole
idea of _flow_ means that we have a task with a beginning and an end.  The
procedure is the primary concern.  I agree with your summation in this instance.
However, don't forget that rule based programming (Artificial Intelligence)
is purely declarative.  Given a set of facts, you can apply a rull and get
results that make sense.  That is also a very powerful tool--but not for this
purpose.

Sylvain likes abstactions. Otherwise the sitemap interpreter would be
called SitemapInterpreter instead of TreeProcessor.
I used to love abstractions as well.

Now I'm far more concerned about them: less is more.
Agreed.  The problem with Cocoon is that there are so many extension points
and abstractions, you have a conceptual internal model that is as clear as
mud.  The problem as I tell folks in situations like this is not that
abstractions are bad, but that the *wrong* abstraction is bad.
Abstractions allow you to try different ways of doing things until you find
the one that works.  If you can't find the
Cocoon is powerful because there is *ONE* sitemap semantics and my
continuous obstructionism to the pluggability of sitemap semantics
forced discussions to happen, that created community and focused
development.
Cocoon is powerful for a great many reasons.  Just provide enough wiggle
room for revolutionary ideas like Flow to be able to be tried out.  That
doesn not mean over-abstraction or FS, it just means to allow different
evolutionary paths to be tested.
You will find that as you move forward an abstraction to an idea that
just makes better sense.  For example, as the Cocoon community works
to merge the three different form handling standards into one which
parts of the evolutionary branches are the strongest, how they complement
each other, and how you can provide for future evolution of the standard.
Remember that stagnation is just as bad as balkanization--be careful not
to allow the pendulum to swing too far the other way.
I'm *strongly* +1 to anything that will force discussion and improve the
existing ideas (as we did with the sitemap semantics over the years and

cvs commit: cocoon-2.1/src/blocks/linotype/samples/styles main.css

2003-07-11 Thread vgritsenko

vgritsenko2003/07/11 17:26:45

  Modified:src/blocks/linotype/samples/styles main.css
  Log:
  align
  
  Revision  ChangesPath
  1.2   +1 -1  cocoon-2.1/src/blocks/linotype/samples/styles/main.css
  
  Index: main.css
  ===
  RCS file: /home/cvs/cocoon-2.1/src/blocks/linotype/samples/styles/main.css,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- main.css  17 Jun 2003 01:32:45 -  1.1
  +++ main.css  12 Jul 2003 00:26:45 -  1.2
  @@ -46,7 +46,7 @@
   body {
   margin: 0px;
   padding: 0px;
  - font-family: georgia, times, times new roman, serif;
  +font-family: georgia, times, times new roman, serif;
   color: #222;
   background-color: #fff;
   font-size: 12px;

Re: [RT] Less is More, Finite State Machines and Balkanization

2003-07-11 Thread Marc Portier



Stefano Mazzocchi wrote:
I went thru the recent [RT] Generalizing the flow thread and I want to
give my impressions on it.
First of all, let me remind you that we agreed (for the FOM, but I think
the vote can be applied to anything) on the general design principle
that less is more: start small and add things *only* when needed.
another view on the same 'less is more' principle might be that 
the [abstract interface] is *less* then the [specific implementation]

as for deciding which implementation gets favourised over which 
others the stress on the *only* seems to imply 'only _after_' 
which kind of gives a historic advantage to the first one in place

as such it might be perceived as conflicting to the darwinistic 
approach?

This is exactly the opposite of behavioral abstraction: provide an
abstraction and free the people to implement their own in order to avoid
having to reach consensus.
after the previous remark this would bring us to comparing the 
advantages of 'consensus' over 'darwinism'

pure Darwinism indeed would not be able to exclude some 
cohabitation (as obviously seen in the real world)

Polymorphism is a great technical concept, but it's an incredibly poo
community tool: it creates balkanization.
cohabitation is a far nicer word for it, it also indicates that 
crossing the borders and intermingling is still alowed...

the above paragraph also strikes slightly on the subject of 
'humans controlling technology' or the other way around...

the question arises indeed: will the application of a great 
technical concept lead this community into behaving badly, or 
are the people around here still human enough to find a means to 
control all of it?


The Avalon people know very well what I'm talking about.

Sylvain and Marc are proposing that we create an abstraction for flow
control, stating that a continuation-based implementation is just one of
the particular possible implemenations.
If you read my original RT about flowmaps (written two years ago), I was
wondering exactly this: what is the *best* way of describing the flow of
a web application in a way that keeps it centralized in one location?
There is no single answer. Just like turing completeness doesn't stop
new programming languages to emerge.
   - o -

I learned programming at the age of 8, writing BASIC on a Commodore
Vic20. I did BASIC until high school when, at the age of 13, I was
*forced* to learn Pascal.
First thing I asked after being introduced to the language: if there are
no explicit line numbers, how do you know where to goto? Answer: you
don't, you don't need to.
What?

It was *impossible* for me to concieve a programming language without
gotos. I didn't know that it was such a common misconception that it
took decades for computer scientists to realize it was not the case.
(until Edsger Dijkstra made it evident in 1968).
After Pascal, I moved into C, then x86 assembly code, where I went back
to direct jumps, and hating it. It took me some 8 years to fully
understand why gotos are harmful. And that was as I was a teenager and
my mental flexibility was at maximum.
Will I be able to do the same now? how much time would that take me?

   - o -

Marc is advocating that there is more than just continuation-based flow
control and he is dead right: there are as many ways to implement flow
control as there are stars in the sky.
or slightly less poetic: as many ways as there are willing 
members of this community

But there are two major families of approaches: procedural vs. declarative.

The continuation-based flow is procedural. What Marc is proposing in his
wiki page is declerative. state oriented. in short, it's a FSM. it's the
goto equivalent for the web.
urgh.

what is exactly the relation between FSM and 'goto'?
and why would it be the case in the web-context?
on the side
my computer-science history is far less impressive: to boil it 
down in one line: I never even got to doing the 'goto' stuff!

isn't a simple while loop a FSM?
/on the side
I'm sorry, but I cannot stop considering this harmful. or, at least, a
poor substitute (for this kind of usage) for what we achieved with
continuation-based produceral flow descriptions.
   - o -

I understand Marc has a FSM-based controller already in place and wants
nope, nothing in place yet
some messages must of been introducing this idea
there is just no need for me to use continuations in a particular 
case I'm working on, can that be an observation?

there is also very little experience (and I have to admit 
willingness) to do (a lot of) js wrapping of existing Java 
backend logic.

(just an extra risk that doesn't need to be introduced)

to use it as a flow controller. I think that a few lines of javascript
will do the job perfectly, or he can still keep using actions as he's
doing right now.
this really brings us back to why current flow did get the 
specific flow semantics and

Re: JXForms Concerns/Questions

Ugo Cei wrote:

Christopher Oliver wrote:

Yes, you do. Because there will be actions you take to process the 
form. These are triggered by the script.

function onePageForm(form) {
   var obj  = new MyJavaObject();
   form.setModel(obj);
   form.sendView(theOnlyPage.xml);
   // A validated form has been submitted,
   // process the form here:
   obj.processForm()
}


Don't you need to call form.finish() afterwards in order to clean up?
Yes, you're right.

By the way, form.finish() takes an URI as a mandatory parameter and 
dispatches to it. I was thinking about implementing a parameterless 
version of form.finish that would just perform the necessary cleanup 
but not dispatch to a view. I need this to call a login form before 
showing a data entry form, in case the user has not already logged on. 
After login, I want to show the originally requested form and not a 
fixed one.

function login() {
  // initialize a new form object
  var form = new loginForm();
  form.sendView(login);
  // check credentials
  form.finsh();
}
function protectedForm(form) {
  if (user == null) {
 login();
  }
  form.setModel(...);
  form.sendView(protected);
  // etc...
}
What do you think?


Agree. The page uri should be optional in Form.finish().

Re: JXForms/XMLForms