date:20030712

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

2003-07-12 Thread Antonio Gallardo

Hi:

Sorry to include my spoon here, but I am feeling again that this
discussion is raising the level and will end in a ugly no-sense discusion,
that can have bad consecuencies for the community. Maybe someone will be
to angry that will decide to go away again. I think we can discuss all of
this more friendly. I am not an older Cocoon community member but I
learned this rule:

1-Does not interpret arguments against your proposal as an attack to you.
2-Try to defend your proposal with direct arguments.

Remember, people always tend to hate and attack changes, this is part of
any human being. Of couse many of us are trying to be open mind, but
this is hard.

This remembered me a discusion about a little change I suggested for the
database block. In that discusion someone, told me I dont know how to do
database stuff! I know, I am not the better database guy in the world, but
I have working in the database world more than 10 years. Well, I choiced
not answer this argument and continue with the discusion in the correct
way.

Now back to the things:

On one side I understand the Stefano concern of try to keep the project in
the correct line as he figured it. I know he is the founder of the project
and has a longer vision about Cocoon than most of us. Please note this is
the Stefano position. His work is keep the project in the correct line.

Cocoon currently has many ways to reach the same goal. This tend people to
be confused and be concerned about the choice they do and thought about
what if my choice is not the good one. If this is good or bad, please
dont ask me. For both can be good and bad arguments.

On the other side many of us is trying to give back to this wonderful
project some work back. We are trying to extend it in the way we see it
usefull for us and maybe for many other. This is good too and Stefano know
and support this.

I think the flow technology is not well defined or digested. Still there
can be others and better ways to follow. But currently people is crying
to have one full functional solution of flow in Cocoon. After many
discussion emerged one of the proposals and we must end this
implementation. If the implementation of the picked proposal is not
functional this is always a step ahead for us. We will learned this is not
the correct path to follow. Please note I feel Flow is a key innovation
for Cocoon.

Please dont ask me what is the better path to follow in the flow. If I
know dont doubt I will tell you. I also know here is better people that
know more about flow than me.

My points are:

1-Keep try the discusion friendly.
2-Lets end the current flow proposal and lets show if this is the correct
way.
3-There can be new proposal that can live in the scratchpad, this is the
way always averything started.

I hope this will be usefull.

Best Regards,

Antonio Gallardo.

P.S: Please does not bad interpret my english, I tried to be the most
respectfull that my poor english can allow to me.

DO NOT REPLY [Bug 21536] New: - Two new Generators to support MultiPartPosted XML and MS Excel conten

2003-07-12 Thread bugzilla

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=21536.
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=21536

Two new Generators to support MultiPartPosted XML and MS Excel conten

   Summary: Two new Generators to support MultiPartPosted XML and MS
Excel conten
   Product: Cocoon 2
   Version: 2.0.4
  Platform: All
   URL: http://www.tempeststrings.com/cocoon/
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: general components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Used together, these two Generators will allow Cocoon to convert back and forth
between POSTed MS Excel  GnumericXML, effectively allowing it to serve as an
Import/Export tool/WebService for MS Excel.

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

2003-07-12 Thread Marc Portier

thx Antonio, really appreciate this.

you did not make a statement that did not cross my mind,

I did a lot of effort to get all the stings out of the mail (and 
I thought I succeeded) since I rally am mister nice guy that 
wants us all to live together in peace

however I have to make the observation that there must of been 
some selfpreserving cry towards the driver of the bulldozer for 
not overlooking my very existence along his path

all in all, it is nice to see people care

warm regards,
-marc=
Antonio Gallardo wrote:
Hi:

Sorry to include my spoon here, but I am feeling again that this
discussion is raising the level and will end in a ugly no-sense discusion
that can have bad consecuencies for the community. Maybe someone will be
to angry that will decide to go away again. I think we can discuss all o
this more friendly. I am not an older Cocoon community member but I
learned this rule:
1-Does not interpret arguments against your proposal as an attack to you.
2-Try to defend your proposal with direct arguments.
Remember, people always tend to hate and attack changes, this is part of
any human being. Of couse many of us are trying to be open mind, but
this is hard.
This remembered me a discusion about a little change I suggested for the
database block. In that discusion someone, told me I dont know how to do
database stuff! I know, I am not the better database guy in the world, but
I have working in the database world more than 10 years. Well, I choiced
not answer this argument and continue with the discusion in the correct
way.
Now back to the things:

On one side I understand the Stefano concern of try to keep the project in
the correct line as he figured it. I know he is the founder of the project
and has a longer vision about Cocoon than most of us. Please note this is
the Stefano position. His work is keep the project in the correct line.
Cocoon currently has many ways to reach the same goal. This tend people to
be confused and be concerned about the choice they do and thought about
what if my choice is not the good one. If this is good or bad, please
dont ask me. For both can be good and bad arguments.
On the other side many of us is trying to give back to this wonderful
project some work back. We are trying to extend it in the way we see it
usefull for us and maybe for many other. This is good too and Stefano know
and support this.
I think the flow technology is not well defined or digested. Still there
can be others and better ways to follow. But currently people is crying
to have one full functional solution of flow in Cocoon. After many
discussion emerged one of the proposals and we must end this
implementation. If the implementation of the picked proposal is not
functional this is always a step ahead for us. We will learned this is not
the correct path to follow. Please note I feel Flow is a key innovation
for Cocoon.
Please dont ask me what is the better path to follow in the flow. If I
know dont doubt I will tell you. I also know here is better people that
know more about flow than me.
My points are:

1-Keep try the discusion friendly.
2-Lets end the current flow proposal and lets show if this is the correct
way.
3-There can be new proposal that can live in the scratchpad, this is the
way always averything started.
I hope this will be usefull.

Best Regards,

Antonio Gallardo.

P.S: Please does not bad interpret my english, I tried to be the most
respectfull that my poor english can allow to me.




--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
Read my weblog at  http://radio.weblogs.com/0116284/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

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

2003-07-12 Thread Marc Portier



Christopher Oliver wrote:
Marc Portier wrote:


leaving me speechless,
could somebody explain how to still contribute?


Put your code in the scratchpad and let people use it.

Chris,

thx for making things simple and clear again...
prepping up to do so
in the mean time I'll learn how to interpret all that was said as 
being long wording for this nice and clear motivating invitation

warm regards,
-marc=
Regards,

Chris

--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
Read my weblog at  http://radio.weblogs.com/0116284/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

RE: JXForms/XMLForms

2003-07-12 Thread Reinhard Pötz

 -Original Message-
 From: Christopher Oliver [mailto:[EMAIL PROTECTED] 
 Sent: Saturday, July 12, 2003 4:27 AM
 To: [EMAIL PROTECTED]
 Subject: Re: JXForms/XMLForms

 Reinhard Pötz wrote:

 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?

 JXForms

 The second difference is the controller. I should be possible to use 
 the Actions framework to control the forms, shouldn't it?

 No!  You don't need actions.  (But that's only my opinion, and I know 
 others disagree with me)

I don't need them too, believe me. The question is: Should we provide
backwards compatibility in the new block (without ever releasing the
deprecated block)?

So after our discussion I think it is the best way to simply move
JXForms into it's own block. If the need for an action controller arises
and somebody starts a discussion on this topic again we can decide in
the future whether we want to integrate it into JXForms or not.
I also say this because I expect ONE Cocoon Forms block where we
provide ONE solution (integrating the best from
JXForms/XMLForms/Woody/JSF/M$Forms/...) in the future.

Cheers,
Reinhard

cvs commit: cocoon-2.1/src/blocks/jsp/java/org/apache/cocoon/components/jsp JSPEngineImplNamedDispatcherInclude.java JSPEngineImpl.java

2003-07-12 Thread joerg

joerg   2003/07/12 06:30:02

  Modified:src/blocks/jsp/java/org/apache/cocoon/generation
JspGenerator.java
   .status.xml
   src/blocks/jsp/java/org/apache/cocoon/components/jsp
JSPEngineImplNamedDispatcherInclude.java
JSPEngineImpl.java
  Log:
  bugfix 4934 applied: made JSPs working in Resin that don't end on .jsp (thanks to 
Ryder Rishel)
  avoid NPE in JSPEngineImplNamedDispatcherInclude when no RequestDispatcher is found
  
  Revision  ChangesPath
  1.4   +1 -3  
cocoon-2.1/src/blocks/jsp/java/org/apache/cocoon/generation/JspGenerator.java
  
  Index: JspGenerator.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/jsp/java/org/apache/cocoon/generation/JspGenerator.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- JspGenerator.java 10 Jul 2003 23:38:04 -  1.3
  +++ JspGenerator.java 12 Jul 2003 13:30:02 -  1.4
  @@ -131,8 +131,6 @@
   throw new ProcessingException(SAXException 
JspGenerator.generate(),e.getException());
   } catch (IOException e) {
   throw new ProcessingException(IOException JspGenerator.generate(),e);
  -} catch (ProcessingException e) {
  -throw e;
   } catch (Exception e) {
   throw new ProcessingException(Exception JspGenerator.generate(),e);
   } finally {
  
  
  
  1.89  +4 -1  cocoon-2.1/status.xml
  
  Index: status.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/status.xml,v
  retrieving revision 1.88
  retrieving revision 1.89
  diff -u -r1.88 -r1.89
  --- status.xml11 Jul 2003 18:32:25 -  1.88
  +++ status.xml12 Jul 2003 13:30:02 -  1.89
  @@ -184,6 +184,9 @@
 changes
   
release version=@version@ date=@date@
  +  action dev=JH type=fix fixes-bug=4934 due-to=Ryder Rishel due-to-email= 
 [EMAIL PROTECTED]
  +   Made JSPs working in Resin that don't end on *.jsp.
  +  /action
 action dev=JH type=update
  All Reader accessing Avalon components now extend the ServiceableReader
  instead of deprecated ComposerReader. It pertains the JSPReader, the
  
  
  
  1.4   +12 -7 
cocoon-2.1/src/blocks/jsp/java/org/apache/cocoon/components/jsp/JSPEngineImplNamedDispatcherInclude.java
  
  Index: JSPEngineImplNamedDispatcherInclude.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/jsp/java/org/apache/cocoon/components/jsp/JSPEngineImplNamedDispatcherInclude.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- JSPEngineImplNamedDispatcherInclude.java  10 Jul 2003 23:38:04 -  1.3
  +++ JSPEngineImplNamedDispatcherInclude.java  12 Jul 2003 13:30:02 -  1.4
  @@ -79,8 +79,10 @@
   public class JSPEngineImplNamedDispatcherInclude extends AbstractLogEnabled
   implements JSPEngine, Parameterizable, ThreadSafe {
   
  -/** The Servlet Include Path */
  +/** The servlet include path. */
   public static final String INC_SERVLET_PATH = 
javax.servlet.include.servlet_path;
  +/** The servlet request uri, needed for Resin. */
  +public static final String INC_REQUEST_URI = 
javax.servlet.include.request_uri;
   
   /** config-parameter name for specifying the jsp servlet-name.
 ie. servlet-name
  @@ -123,11 +125,13 @@
   // start JSPServlet.
   javax.servlet.RequestDispatcher rd = context.getNamedDispatcher( 
servletName );
   if (rd != null) {
  -  rd.include( request, response );
  -  response.flushBuffer();
  -  bytes = response.toByteArray();
  +rd.include( request, response );
  +response.flushBuffer();
  +bytes = response.toByteArray();
   } else {
  -  getLogger().error( Specify a correct  + CONFIG_SERVLET_NAME +   + 
servletName );
  +// FIXME: I guess it's better to throw a more specific exception.
  +throw new Exception(No RequestDispatcher found. Specify a correct '
  ++ CONFIG_SERVLET_NAME + ':  + servletName);
   }
   return bytes;
   }
  @@ -170,8 +174,9 @@
   /** @deprecated use isRequestedSessionIdFromURL instead. */
   public boolean isRequestedSessionIdFromUrl(){ return 
request.isRequestedSessionIdFromUrl(); }
   public Object getAttribute(String s){
  -if(s != null  s.equals(INC_SERVLET_PATH))
  +if (s != null  (s.equals(INC_SERVLET_PATH) || 
s.equals(INC_REQUEST_URI))) {
   return jspFile;
  +}
   return request.getAttribute(s);
   }
   public Enumeration getAttributeNames(){ return

cvs commit: cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/transformation RSSTransformer.java

2003-07-12 Thread cziegeler

cziegeler2003/07/12 06:49:56

  Modified:lib  jars.xml
   src/blocks/portal/java/org/apache/cocoon/portal/transformation
RSSTransformer.java
  Added:   src/blocks/html/lib jtidy-04aug2000r7-dev.jar
  Removed: src/blocks/html/lib .cvsignore
   lib/optional jtidy-04aug2000r7-dev.jar
  Log:
  Removing direct dependency from portal block to jtidy
  
  Revision  ChangesPath
  1.3   +0 -0  cocoon-2.1/src/blocks/html/lib/jtidy-04aug2000r7-dev.jar
  
Binary file
  
  
  1.65  +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.64
  retrieving revision 1.65
  diff -u -r1.64 -r1.65
  --- jars.xml  11 Jul 2003 20:25:30 -  1.64
  +++ jars.xml  12 Jul 2003 13:49:56 -  1.65
  @@ -496,7 +496,7 @@
 titleTransform HTML to XML/title
 descriptionTidy is a HTML syntax checker and pretty printer./description
 used-byHTML generator (html block), RSSTransformer (Portal block)/used-by
  -  liboptional/jtidy-04aug2000r7-dev.jar/lib
  +  libhtml/lib/jtidy-04aug2000r7-dev.jar/lib
 homepagehttp://lempinen.net/sami/jtidy//homepage
/file
   
  
  
  
  1.2   +108 -34   
cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/transformation/RSSTransformer.java
  
  Index: RSSTransformer.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/transformation/RSSTransformer.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- RSSTransformer.java   11 Jul 2003 14:17:02 -  1.1
  +++ RSSTransformer.java   12 Jul 2003 13:49:56 -  1.2
  @@ -50,8 +50,22 @@
   */
   package org.apache.cocoon.portal.transformation;
   
  +import java.io.ByteArrayInputStream;
  +import java.io.IOException;
  +import java.io.InputStream;
  +import java.util.Map;
  +
  +import org.apache.avalon.framework.component.Component;
  +import org.apache.avalon.framework.component.ComponentException;
  +import org.apache.avalon.framework.parameters.Parameters;
  +import org.apache.cocoon.ProcessingException;
  +import org.apache.cocoon.components.sax.XMLDeserializer;
  +import org.apache.cocoon.components.sax.XMLSerializer;
  +import org.apache.cocoon.environment.SourceResolver;
   import org.apache.cocoon.transformation.AbstractSAXTransformer;
  -import org.w3c.tidy.Tidy;
  +import org.apache.cocoon.xml.IncludeXMLConsumer;
  +import org.apache.cocoon.xml.XMLConsumer;
  +import org.apache.excalibur.xmlizer.XMLizer;
   import org.xml.sax.Attributes;
   import org.xml.sax.SAXException;
   
  @@ -66,6 +80,18 @@
   public final class RSSTransformer
   extends AbstractSAXTransformer {
   
  +/** The xmlizer for converting html to xml */
  +protected XMLizer xmlizer;
  +
  +/** The xml serializer */
  +protected XMLSerializer serializer;
  +
  +/** The xml deserializer */
  +protected XMLDeserializer deserializer;
  +
  +/** The filter */
  +protected XMLConsumer filter;
  +
   /**
*  receive notification of start element event.
**/
  @@ -85,47 +111,95 @@
   if (description.equals(name)) {
   final String text = this.endTextRecording();
   final String html = htmlbody+text+/body/html;
  -
  +
  +boolean parsed = false;
   try {
  -final Tidy xhtmlconvert = new Tidy();
  -xhtmlconvert.setXmlOut(true);
  -xhtmlconvert.setXHTML(true);
  -xhtmlconvert.setShowWarnings(false);
  -org.w3c.dom.Document doc = xhtmlconvert.parseDOM(new 
java.io.ByteArrayInputStream(html.getBytes()), null);
  -org.w3c.dom.NodeList node = 
org.apache.cocoon.xml.dom.DOMUtil.selectNodeList(doc, /html/body/*);
  -if (null != node) {
  -for(int i = 0; i  node.getLength(); i++) {
  -this.sendEvents(node.item(i));
  -}
  -} else {
  -this.sendTextEvent(text);
  -}
  -} catch (Exception e) {
  +InputStream inputStream = new ByteArrayInputStream(html.getBytes());
  +this.xmlizer.toSAX(inputStream,
  +text/html,
  +null,
  +this.serializer);
  +// if no exception occurs, everything is fine!
  +parsed = true;
  +} catch (Exception ignore) {
  +}
  +if ( parsed ) {
  +this.deserializer.setConsumer( this.filter );
  +this.deserializer.deserialize(

Re: cvs commit: cocoon-2.1/src/blocks/jsp/java/org/apache/cocoon/components/jspJSPEngineImplNamedDispatcherInclude.java JSPEngineImpl.java

2003-07-12 Thread Vadim Gritsenko

[EMAIL PROTECTED] wrote:

joerg   2003/07/12 06:30:02

 --- JspGenerator.java	10 Jul 2003 23:38:04 -	1.3
 +++ JspGenerator.java	12 Jul 2003 13:30:02 -	1.4
 @@ -131,8 +131,6 @@
  throw new ProcessingException(SAXException JspGenerator.generate(),e.getException());
  } catch (IOException e) {
  throw new ProcessingException(IOException JspGenerator.generate(),e);
 -} catch (ProcessingException e) {
 -throw e;
 

This code avoids unnecessary wrapping of ProcessingException into one 
more ProcessingException. What was the reason to remove it? It took some 
time to add all those small pieces to avoid excessive exception wrapping...

Vadim

Re: cvs commit: cocoon-2.1/src/blocks/jsp/java/org/apache/cocoon/components/jspJSPEngineImplNamedDispatcherInclude.java JSPEngineImpl.java

2003-07-12 Thread Joerg Heinicke

Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:

  throw new ProcessingException(SAXException 
JspGenerator.generate(),e.getException());
  } catch (IOException e) {
  throw new ProcessingException(IOException 
JspGenerator.generate(),e);
 -} catch (ProcessingException e) {
 -throw e;
 

This code avoids unnecessary wrapping of ProcessingException into one 
more ProcessingException. What was the reason to remove it? It took some 
time to add all those small pieces to avoid excessive exception wrapping...

Vadim
Sorry, have been too fast here. I only saw the re-throw, which could be 
removed in general, but not if Exception is caught afterwards.

Joerg

cvs commit: cocoon-2.0/src/java/org/apache/cocoon/reading JSPReader.java

2003-07-12 Thread joerg

joerg   2003/07/12 07:57:49

  Modified:src/java/org/apache/cocoon/reading JSPReader.java
  Log:
  applied latest changes from 2.1:
  revert encoding changes in JSPEngineImpl (bug 14327)
  made JSPs working in Resin not ending on .jsp (bug 4934, thanks to Ryder Rishel)
  avoid NPE in JSPEngineImplNamedDispatcherInclude if no RequestDispatcher was found
  deprecation messages added
  
  Revision  ChangesPath
  1.2   +4 -3  cocoon-2.0/src/java/org/apache/cocoon/reading/JSPReader.java
  
  Index: JSPReader.java
  ===
  RCS file: /home/cvs/cocoon-2.0/src/java/org/apache/cocoon/reading/JSPReader.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- JSPReader.java9 Mar 2003 00:03:07 -   1.1
  +++ JSPReader.java12 Jul 2003 14:57:49 -  1.2
  @@ -103,7 +103,7 @@
   JSPEngine engine = null;
   try {
   
  -// FIXME (KP): Should we exclude not supported protocols, say 'context'?
  +// TODO (KP): Should we exclude not supported protocols, say 'context'?
   String url = this.source;
   
   // absolute path is processed as is
  @@ -120,10 +120,11 @@
   getLogger().debug(JSPReader executing JSP: + url);
   
   byte[] bytes = engine.executeJSP(url, httpRequest, httpResponse, 
httpContext);
  -// FIXME (KP): Make buffer size configurable
  +// TODO (KP): Make buffer size configurable
   byte[] buffer = new byte[8192];
   int length = -1;
   
  +// TODO: Recode from UTF8 to desired output encoding.
   ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
   while ((length = bais.read(buffer))  -1) {
   out.write(buffer, 0, length);

cvs commit: cocoon-2.0/src/java/org/apache/cocoon/generation JspGenerator.java

2003-07-12 Thread joerg

joerg   2003/07/12 07:58:00

  Modified:src/java/org/apache/cocoon/generation JspGenerator.java
  Log:
  applied latest changes from 2.1:
  revert encoding changes in JSPEngineImpl (bug 14327)
  made JSPs working in Resin not ending on .jsp (bug 4934, thanks to Ryder Rishel)
  avoid NPE in JSPEngineImplNamedDispatcherInclude if no RequestDispatcher was found
  deprecation messages added
  
  Revision  ChangesPath
  1.2   +2 -2  
cocoon-2.0/src/java/org/apache/cocoon/generation/JspGenerator.java
  
  Index: JspGenerator.java
  ===
  RCS file: 
/home/cvs/cocoon-2.0/src/java/org/apache/cocoon/generation/JspGenerator.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- JspGenerator.java 9 Mar 2003 00:02:59 -   1.1
  +++ JspGenerator.java 12 Jul 2003 14:58:00 -  1.2
  @@ -122,7 +122,7 @@
   
   // explicitly specify bytestream encoding
   InputSource input = new InputSource(new ByteArrayInputStream(bytes));
  -// FIXME (KP): Why do we need this?
  +// utf-8 is default encoding; specified explicitely here as a reminder.
   input.setEncoding(utf-8);
   
   // pipe the results into the parser

cvs commit: cocoon-2.0 changes.xml

2003-07-12 Thread joerg

joerg   2003/07/12 07:58:13

  Modified:.changes.xml
  Log:
  applied latest changes from 2.1:
  revert encoding changes in JSPEngineImpl (bug 14327)
  made JSPs working in Resin not ending on .jsp (bug 4934, thanks to Ryder Rishel)
  avoid NPE in JSPEngineImplNamedDispatcherInclude if no RequestDispatcher was found
  deprecation messages added
  
  Revision  ChangesPath
  1.29  +8 -1  cocoon-2.0/changes.xml
  
  Index: changes.xml
  ===
  RCS file: /home/cvs/cocoon-2.0/changes.xml,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- changes.xml   3 Jul 2003 02:10:01 -   1.28
  +++ changes.xml   12 Jul 2003 14:58:13 -  1.29
  @@ -43,6 +43,13 @@
/devs
   
release version=@version@ date=@date@
  +  action dev=JH type=fix fixes-bug=4934 due-to=Ryder Rishel due-to-email= 
 [EMAIL PROTECTED]
  +Made JSPs working in Resin that don't end on *.jsp.
  +  /action
  +  action dev=JH type=fix fixes-bug=14327
  +Reverted the encoding changes in the JSP engine. The fix should be done in
  +the JSPReader.
  +  /action
 action dev=VG type=remove
   Removed deprecated notification classes in org.apache.cocoon and in
   org.apache.cocoon.sitemap packages. Removed deprecated methods in

cvs commit: cocoon-2.1 blocks.properties

2003-07-12 Thread joerg

joerg   2003/07/12 08:23:24

  Modified:.blocks.properties
  Log:
  alphabetical sorting makes it a bit easier
  taglib block is marked unstable in the gump descriptor, so moving it to the unstable 
blocks here too
  
  Revision  ChangesPath
  1.19  +24 -24cocoon-2.1/blocks.properties
  
  Index: blocks.properties
  ===
  RCS file: /home/cvs/cocoon-2.1/blocks.properties,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- blocks.properties 11 Jul 2003 10:32:34 -  1.18
  +++ blocks.properties 12 Jul 2003 15:23:24 -  1.19
  @@ -16,33 +16,32 @@
   # developers are committed to back compatibility. In short, stuff you can
   # depend on.
   
  -#exclude.block.fop=true
  +#exclude.block.authentication-fw=true
   #exclude.block.batik=true
  +#exclude.block.bsf=true
   #exclude.block.chaperon=true
  -#exclude.block.itext=true
  -#exclude.block.jfor=true
  -#exclude.block.swf=true
  -#exclude.block.session-fw=true
  -#exclude.block.authentication-fw=true
  -#exclude.block.portal-fw=true
   #exclude.block.databases=true
  +#exclude.block.deli=true
  +#exclude.block.fop=true
   #exclude.block.hsqldb=true
  -#exclude.block.poi=true
  -#exclude.block.naming=true
  -#exclude.block.jsp=true
  -#exclude.block.php=true
  -#exclude.block.python=true
  -#exclude.block.lucene=true
   #exclude.block.html=true
  +#exclude.block.itext=true
  +#exclude.block.jfor=true
  +#exclude.block.jsp=true
   #exclude.block.linkrewriter=true
  -#exclude.block.bsf=true
  +#exclude.block.lucene=true
  +#exclude.block.naming=true
  +#exclude.block.php=true
  +#exclude.block.poi=true
  +#exclude.block.portal-fw=true
   #exclude.block.profiler=true
  +#exclude.block.python=true
  +#exclude.block.session-fw=true
  +#exclude.block.slide=true
  +#exclude.block.swf=true
   #exclude.block.velocity=true
   #exclude.block.web3=true
  -#exclude.block.slide=true
  -#exclude.block.taglib=true
   #exclude.block.xmldb=true
  -#exclude.block.deli=true
   #exclude.block.xmlform=true
   
   
  @@ -56,15 +55,16 @@
   # its development as thing might change over time before they are marked
   # stable.
   
  -#exclude.block.proxy=true
   #exclude.block.asciiart=true
  -#exclude.block.precept=true
  -#exclude.block.mail=true
   #exclude.block.axis=true
  -#exclude.block.portal=true
  -#exclude.block.woody=true
  -#exclude.block.qdox=true
  -#exclude.block.stx=true
   #exclude.block.linotype=true
  +#exclude.block.mail=true
  +#exclude.block.qdox=true
   #exclude.block.petstore=true
  +#exclude.block.precept=true
  +#exclude.block.proxy=true
  +#exclude.block.portal=true
  +#exclude.block.stx=true
  +#exclude.block.taglib=true
   #exclude.block.webdav=true
  +#exclude.block.woody=true

calling actions from flow

2003-07-12 Thread Leszek Gawron

I've been tracking the subject a little but still I do not get what is the
current status of the matter so:

1. Will there be a possibility to call actions from flow ? 

2. If not what should I do with a bunch of XSP actions if I wanted to use the
logic in flow? 

quote
source=http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105407572313285w=2;
The migration path between Actions and flow is: move away from actions.

Who? piece of cake: instead of using the Action interface, just
implement your own service interface. that's it.

Java components give services and these components should not be
connected to cocoon.

If you want, you can write a thin action wrapper around those
components, but once you have the flow, I really don't see why you would
go that way.
/quote

So how could I migrate from ESQL intensive XSP actions to java components ?
What is so bad in using actions in flow?

ouzo

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

2003-07-12 Thread Ricardo Rocha

Antonio: I'm impressed me by your candor and sense of community. Your
comments are absolutely relevant.

It has taken me years to understand why and how open source is more
than just code and technology. I tended to think stricly in terms of
genericity, elegance, or economy of terms. The notion that bad code
and good ideas create communities was alien to me. Paraphrasing the
Matrix Architect, I found it unacceptable to release what appeared to
me as incomplete or imperfect code for what was otherwise a harmony
of mathematical precision. Uff! Definitely, worse is better.

The ugly, non-sense discussions mentioned by Antonio are generally
characterized by over-focusing on technical arguments in disregard
for community goals. I dislike harsh language and irony, but in this
one case I agree with the balkanization part of this thread's title.
Should we make core abstractions pluggable just because it's possible,
even if it can confuse users and fragment the community? The Über-Avalon
syndrome? Definitely, less is more.


Ricardo


Antonio Gallardo wrote:
 
 Sorry to include my spoon here, but I am feeling again that 
 this discussion is raising the level and will end in a ugly 
 no-sense discusion, that can have bad consecuencies for the 
 community. Maybe someone will be to angry that will decide to 
 go away again. I think we can discuss all of this more 
 friendly. I am not an older Cocoon community member but I 
 learned this rule:
 
 1-Does not interpret arguments against your proposal as an 
 attack to you. 2-Try to defend your proposal with direct arguments.
 
 Remember, people always tend to hate and attack changes, 
 this is part of any human being. Of couse many of us are 
 trying to be open mind, but this is hard.
 
 This remembered me a discusion about a little change I 
 suggested for the database block. In that discusion someone, 
 told me I dont know how to do database stuff! I know, I am 
 not the better database guy in the world, but I have working 
 in the database world more than 10 years. Well, I choiced not 
 answer this argument and continue with the discusion in the 
 correct way.
 
 Now back to the things:
 
 On one side I understand the Stefano concern of try to keep 
 the project in the correct line as he figured it. I know he 
 is the founder of the project and has a longer vision about 
 Cocoon than most of us. Please note this is the Stefano 
 position. His work is keep the project in the correct line.
 
 Cocoon currently has many ways to reach the same goal. This 
 tend people to be confused and be concerned about the choice 
 they do and thought about what if my choice is not the good 
 one. If this is good or bad, please dont ask me. For both can 
 be good and bad arguments.
 
 On the other side many of us is trying to give back to this 
 wonderful project some work back. We are trying to extend it 
 in the way we see it usefull for us and maybe for many other. 
 This is good too and Stefano know and support this.
 
 I think the flow technology is not well defined or digested. 
 Still there can be others and better ways to follow. But 
 currently people is crying to have one full functional 
 solution of flow in Cocoon. After many discussion emerged one 
 of the proposals and we must end this implementation. If the 
 implementation of the picked proposal is not functional this 
 is always a step ahead for us. We will learned this is not 
 the correct path to follow. Please note I feel Flow is a key 
 innovation for Cocoon.
 
 Please dont ask me what is the better path to follow in the 
 flow. If I know dont doubt I will tell you. I also know here 
 is better people that know more about flow than me.
 
 My points are:
 
 1-Keep try the discusion friendly.
 2-Lets end the current flow proposal and lets show if this is 
 the correct way. 3-There can be new proposal that can live in 
 the scratchpad, this is the way always averything started.
 
 I hope this will be usefull.
 
 Best Regards,
 
 Antonio Gallardo.
 
 P.S: Please does not bad interpret my english, I tried to be 
 the most respectfull that my poor english can allow to me.

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

2003-07-12 Thread coliver

coliver 2003/07/12 12:07:33

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

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

2003-07-12 Thread coliver

coliver 2003/07/12 12:07:43

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

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

2003-07-12 Thread coliver

coliver 2003/07/12 12:07:52

  cocoon-2.1/src/blocks/petstore/java/org/apache/cocoon/components - New directory

cvs commit: cocoon-2.1/src/blocks/petstore/java/org/apache/cocoon/components/flow - New directory

2003-07-12 Thread coliver

coliver 2003/07/12 12:08:01

  cocoon-2.1/src/blocks/petstore/java/org/apache/cocoon/components/flow - New directory

cvs commit: cocoon-2.1/src/blocks/petstore/java/org/apache/cocoon/components/flow/javascript - New directory

2003-07-12 Thread coliver

coliver 2003/07/12 12:08:10

  cocoon-2.1/src/blocks/petstore/java/org/apache/cocoon/components/flow/javascript - 
New directory

cvs commit: cocoon-2.1/src/scratchpad/src/org/apache/cocoon/components/flow/javascript Database.js ScriptableConnection.java ScriptableResult.java

2003-07-12 Thread coliver

coliver 2003/07/12 12:09:28

  Removed: src/scratchpad/src/org/apache/cocoon/components/flow/javascript
Database.js ScriptableConnection.java
ScriptableResult.java
  Log:
  Moving to petstore block

cvs commit: cocoon-2.1/src/blocks/petstore/java/org/apache/cocoon/components/flow/javascript Database.js ScriptableConnection.java ScriptableResult.java

2003-07-12 Thread coliver

coliver 2003/07/12 12:09:39

  Added:   src/blocks/petstore/java/org/apache/cocoon/components/flow/javascript
Database.js ScriptableConnection.java
ScriptableResult.java
  Log:
  Moving to petstore block
  
  Revision  ChangesPath
  1.1  
cocoon-2.1/src/blocks/petstore/java/org/apache/cocoon/components/flow/javascript/Database.js
  
  Index: Database.js
  ===
  //
  // CVS $Id: Database.js,v 1.1 2003/07/12 19:09:39 coliver Exp $
  //
  // Prototype Database API
  //
  // TBD: Move this Database stuff to its own library outside of flow
  //
  
  defineClass(org.apache.cocoon.components.flow.javascript.ScriptableConnection);
  defineClass(org.apache.cocoon.components.flow.javascript.ScriptableResult);
  
  Database.getConnection = function(selectorValue) {
  var selector = 
cocoon.componentManager.lookup(Packages.org.apache.avalon.excalibur.datasource.DataSourceComponent.ROLE
 + Selector);
  try {
var ds = selector.select(selectorValue);
return new Database(ds.getConnection());
  } finally {
cocoon.componentManager.release(selector);
  }
  }
  
  
  
  
  1.1  
cocoon-2.1/src/blocks/petstore/java/org/apache/cocoon/components/flow/javascript/ScriptableConnection.java
  
  Index: ScriptableConnection.java
  ===
  /* -*- Mode: java; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 4 -*-
  
   
 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.
  
  */
  package org.apache.cocoon.components.flow.javascript;
  import org.mozilla.javascript.*;
  import java.sql.*;
  
  /**
   * Wraps a JDBC connection and provides an API similar to JSTL
   * A ScriptableConnection provides two methods:
   *
   * UL
   * LIquery([String] stmt, [Array] parameters, [Number] startRow, [Number] 
maxRows)/LI
   * LIupdate([String] stmt, [Array] parameters)/LI
   * /UL
   * The object returned by codequery/code contains the following
   * properties:
   * UL
   * LI[Array] rows - an array of row objects/LI
   * LI[Array] rowsByIndex - An array with an array per row of column values/LI
   * LI[Array] columnNames - An array of column names/LI
   * LI[Number] rowCount - Number of rows returned/LI
   * LI[Boolean] limitedByMaxRows - true if not all rows are included due to 
matching a maximum value /LI
   * /UL
   *
   * A ScriptableConnection is also a wrapper around a real JDBC Connection and thus 
   * provides all of methods

cvs commit: cocoon-2.1/src/blocks/jxforms/lib - New directory

2003-07-12 Thread coliver

coliver 2003/07/12 12:11:04

  cocoon-2.1/src/blocks/jxforms/lib - New directory

cvs commit: cocoon-2.1/src/blocks/jxforms/java - New directory

2003-07-12 Thread coliver

coliver 2003/07/12 12:11:04

  cocoon-2.1/src/blocks/jxforms/java - New directory

cvs commit: cocoon-2.1/src/blocks/jxforms/samples - New directory

2003-07-12 Thread coliver

coliver 2003/07/12 12:11:04

  cocoon-2.1/src/blocks/jxforms/samples - New directory

cvs commit: cocoon-2.1/src/blocks/jxforms/java/org/apache/cocoon/components/jxforms/xmlform - New directory

2003-07-12 Thread coliver

coliver 2003/07/12 12:12:50

  cocoon-2.1/src/blocks/jxforms/java/org/apache/cocoon/components/jxforms/xmlform - 
New directory

cvs commit: cocoon-2.1/src/blocks/jxforms/samples/view - New directory

2003-07-12 Thread coliver

coliver 2003/07/12 12:14:47

  cocoon-2.1/src/blocks/jxforms/samples/view - New directory

cvs commit: cocoon-2.1/src/blocks/jxforms/samples/stylesheets - New directory

2003-07-12 Thread coliver

coliver 2003/07/12 12:14:47

  cocoon-2.1/src/blocks/jxforms/samples/stylesheets - New directory

cvs commit: cocoon-2.1/src/blocks/velocity/java/org/apache/cocoon/generation VelocityGenerator.java

2003-07-12 Thread coliver

coliver 2003/07/12 12:39:41

  Modified:src/blocks/velocity/java/org/apache/cocoon/generation
VelocityGenerator.java
  Log:
  Moved from scratchpad
  
  Revision  ChangesPath
  1.7   +730 -250  
cocoon-2.1/src/blocks/velocity/java/org/apache/cocoon/generation/VelocityGenerator.java
  
  Index: VelocityGenerator.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/velocity/java/org/apache/cocoon/generation/VelocityGenerator.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- VelocityGenerator.java3 Jul 2003 11:36:10 -   1.6
  +++ VelocityGenerator.java12 Jul 2003 19:39:41 -  1.7
  @@ -1,4 +1,4 @@
  -/*
  +/* -*- Mode: java; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 4 -*-
   

  The Apache Software License, Version 1.1
  @@ -50,46 +50,90 @@
   */
   package org.apache.cocoon.generation;
   
  +import java.beans.PropertyDescriptor;
  +import java.io.BufferedReader;
  +import java.io.IOException;
  +import java.io.InputStream;
  +import java.io.StringReader;
  +import java.io.StringWriter;
  +import java.util.*;
  +
   import org.apache.avalon.framework.activity.Initializable;
   import org.apache.avalon.framework.component.Component;
   import org.apache.avalon.framework.component.ComponentException;
   import org.apache.avalon.framework.configuration.Configurable;
   import org.apache.avalon.framework.configuration.Configuration;
   import org.apache.avalon.framework.configuration.ConfigurationException;
  -import org.apache.avalon.framework.context.Context;
   import org.apache.avalon.framework.context.ContextException;
   import org.apache.avalon.framework.context.DefaultContext;
   import org.apache.avalon.framework.parameters.Parameters;
   import org.apache.cocoon.ProcessingException;
   import org.apache.cocoon.ResourceNotFoundException;
  +import org.apache.cocoon.components.flow.FlowHelper;
  +import org.apache.cocoon.components.flow.WebContinuation;
   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.apache.cocoon.environment.SourceResolver;
   import org.apache.commons.collections.ExtendedProperties;
  +import org.apache.commons.jxpath.DynamicPropertyHandler;
  +import org.apache.commons.jxpath.JXPathBeanInfo;
  +import org.apache.commons.jxpath.JXPathIntrospector;
   import org.apache.excalibur.source.Source;
   import org.apache.excalibur.xml.sax.SAXParser;
   import org.apache.velocity.VelocityContext;
   import org.apache.velocity.app.Velocity;
   import org.apache.velocity.app.VelocityEngine;
  +import org.apache.velocity.context.Context;
   import org.apache.velocity.runtime.RuntimeServices;
   import org.apache.velocity.runtime.log.LogSystem;
  +import org.apache.velocity.util.introspection.Info;
  +import org.apache.velocity.util.introspection.UberspectImpl;
  +import org.apache.velocity.util.introspection.VelMethod;
  +import org.apache.velocity.util.introspection.VelPropertyGet;
  +import org.apache.velocity.util.introspection.VelPropertySet;
  +import org.mozilla.javascript.*;
   import org.xml.sax.InputSource;
   import org.xml.sax.SAXException;
  -
  -import java.io.IOException;
  -import java.io.InputStream;
  -import java.io.StringReader;
  -import java.io.StringWriter;
  -import java.util.ArrayList;
  -import java.util.HashMap;
  -import java.util.Iterator;
  -import java.util.List;
  -import java.util.Map;
  +import org.xml.sax.SAXParseException;
   
   /**
* pCocoon [EMAIL PROTECTED] Generator} that produces dynamic XML SAX events
* from a Velocity template file./p
  + * If called from a Flowscript, the immediate properties of the context object from 
the Flowscript are available in the Velocity context.
  + * In that case, the current Web Continuation from the Flowscript 
  + * is also available as a variable named codecontinuation/code. You would 
  + * typically access its codeid/code:
  + * ppre
  + *lt;form action=$continuation.idgt;
  + * /pre/p
  + * pYou can also reach previous continuations by using the 
codegetContinuation()/code function:/p
  + * ppre
  + * lt;form action=$continuation.getContinuation(1).id} 
  + * /pre/p
  + * 
  + * In addition the following implicit objects are always available in
  + * the Velocity context:
  + * p
  + * dl
  + * dtcoderequest/code 
(codeorg.apache.cocoon.environment.Request/code)/dt
  + * ddThe Cocoon current request/dd
  + *
  + * dtcoderesponse/code 
(codeorg.apache.cocoon.environment.Response/code)/dt
  + * ddThe Cocoon response associated with the current request/dd
  + *
  + * dtcodesession/code 
(codeorg.apache.cocoon.environment.Session/code)/dt
  + * ddThe Cocoon

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

2003-07-12 Thread Carsten Ziegeler

Stefano Mazzocchi wrote:

 We choose one direction for our core and we keep evolving that. No
 polymorphism just because a few people have legacy they want to reuse,
 it's not our problem.

 Yeah, the next thing to unify will have to be the form handling. XMLForm
 and JXForm will be shortly unified. Hopefully, Woody will be as well.

I think one of the main tasks for 2.2 will be unifying and consolidating the
code. We have three form handling blocks, several including mechanism, many
template approaches etc.
It's not good to offer users many different ways to do one single thing. But
it's good to have different implementations/designs/ideas to make the single
usable solution. A unified development effort can really increase the
result.
We (sn and BASF IT Services) for example have seen this with the new
portal framework; it's much better than the single ideas we or BASF IT
Services
allone had (although of course the single ideas where not bad).


 Balkanization is the problem. FS is the signal. Community fragementation
 is the danger, expecially when blocks will be there.
Yepp, we should control the creation of new blocks when the time comes.


 So, instead of routing around consensus, let's work toward it, that
 means: no abstraction for core parts.

 It seems like everybody has an agenda to place their favorite technology
 right in the core of cocoon.
Yes, and that's one of the points I didn't like with flow in the first
beginning,
because it's tight to the core and the core had to be changed in some
places.
Now, if you say flow belongs to the core (and we do this now), then it's ok
to change the core. But it should be avoided to change the core for anything
that doesn't belong to it.

Before someone else mentions it: some of you might have noticed that I
started
Dywel, another project/block for cocoon dealing with (what else?) form
handling,
continuations etc. First, before you get worried about it, it's only an
experiment of building a better way of building web applications with
Cocoon.
Perhaps, I'm on the wrong track and will trash it as soon as I realize it.
Therefore
I will not add it to the Cocoon CVS before I really see the value of it.
The main idea is to add a framework on top of Cocoon with all the existing
structure, but without changing anything in Cocoon. I think this is
possible.
For most parts, like e.g. form handling or continuations, I plan to use
the existing things in Cocoon instead of developing another version of an
already existing thing.
But I have to do it as I had the ideas for it more than three years ago when
I left the WebObjects development area and came directly to Cocoon. So, it's
more a personal challenge then anything else.

Carsten

Re: Lifecycle Help

2003-07-12 Thread Geoff Howard

Geoff Howard wrote:
Is is safe to act on other components during intialize() as a general 
rule?  (I'm guessing no) If not, if a recoverable error occurs during 
initialize that affects other components, how is one to tell them?
Follow up:

Is the order of component initialization a reliable contract with the
Container?  If component A is defined before component B, can it be
relied on that they are initialize()-ed first A then B?
Geoff

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

2003-07-12 Thread Antonio Gallardo

Carsten Ziegeler dijo:
 But I have to do it as I had the ideas for it more than three years ago
 when I left the WebObjects development area and came directly to Cocoon.
 So, it's more a personal challenge then anything else.

Good luck! :)

Antonio Gallardo

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

2003-07-12 Thread Vadim Gritsenko

[EMAIL PROTECTED] wrote:

gianugo 2003/07/11 03:32:35

  src/blocks/webdav/lib slide-webdavlib.jar

Do we know the version number?

Vadim

cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/validationruleimpl RegExpValidationRule.java RegExpValidationRuleBuilder.java

2003-07-12 Thread vgritsenko

vgritsenko2003/07/12 18:27:48

  Modified:
src/blocks/woody/java/org/apache/cocoon/woody/datatype/validationruleimpl
RegExpValidationRule.java
RegExpValidationRuleBuilder.java
  Log:
  Fix line endings
  
  Revision  ChangesPath
  1.2   +96 -96
cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/validationruleimpl/RegExpValidationRule.java
  
  Index: RegExpValidationRule.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/datatype/validationruleimpl/RegExpValidationRule.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- RegExpValidationRule.java 9 Jul 2003 12:17:21 -   1.1
  +++ RegExpValidationRule.java 13 Jul 2003 01:27:48 -  1.2
  @@ -1,96 +1,96 @@
  -/*
  -
  - 
  -   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.woody.datatype.validationruleimpl;
  -
  -import org.apache.cocoon.woody.datatype.ValidationError;
  -import org.apache.cocoon.woody.datatype.validationruleimpl.AbstractValidationRule;
  -import org.apache.oro.text.regex.Pattern;
  -import org.apache.oro.text.regex.PatternMatcher;
  -import org.apache.oro.text.regex.Perl5Matcher;
  -import org.outerj.expression.ExpressionContext;
  -
  -
  -/**
  - * Checks that a String matches a regular expression.
  - *
  - * pThe a href=http://jakarta.apache.org/oro/;Jakarta ORO/a library
  - * is used as regexp engine.
  - */
  -public class RegExpValidationRule extends AbstractValidationRule {
  - /** Compiled regular expression. */
  - private Pattern pattern;
  -/** Original string representation of the regexp, used for informational 
purposes only. */
  -private String regexp;
  -
  -public ValidationError validate(Object value, ExpressionContext 
expressionContext) {
  - String string = (String)value;
  - 
  - if(matchesRegExp(string))
  - return null;   
  - else
  - return hasFailMessage() ? getFailMessage() : new 
ValidationError(validation.string.regexp, new String[] {regexp});
  -}
  -
  -private boolean

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

2003-07-12 Thread Vadim Gritsenko

[EMAIL PROTECTED] wrote:

 +   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
... to change ... from using emLogEnabled/em
... instead of emLoggable/em
Is it me or wording is confusing?

Vadim

cvs commit: cocoon-2.1/src/scratchpad/src/org/apache/cocoon/generation JXFormsGenerator.java

2003-07-12 Thread ghoward

ghoward 2003/07/12 20:33:41

  Removed: src/scratchpad/src/org/apache/cocoon/generation
JXFormsGenerator.java
  Log:
  Store has this, Cache didn't - needed it.

cvs commit: cocoon-2.1/src/blocks/jxforms/java/org/apache/cocoon/components/jxforms/flow/javascript JXForm.java

2003-07-12 Thread ghoward

ghoward 2003/07/12 20:36:12

  Modified:
src/blocks/jxforms/java/org/apache/cocoon/components/jxforms/flow/javascript
JXForm.java
  Log:
  static access
  
  Revision  ChangesPath
  1.2   +1 -1  
cocoon-2.1/src/blocks/jxforms/java/org/apache/cocoon/components/jxforms/flow/javascript/JXForm.java
  
  Index: JXForm.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/jxforms/java/org/apache/cocoon/components/jxforms/flow/javascript/JXForm.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- JXForm.java   12 Jul 2003 19:22:29 -  1.1
  +++ JXForm.java   13 Jul 2003 03:36:12 -  1.2
  @@ -220,7 +220,7 @@
   
   public void jsFunction_removeForm() {
   FOM_Cocoon cocoon = getCocoon();
  -form.remove(cocoon.getEnvironment().getObjectModel(), id);
  +Form.remove(cocoon.getEnvironment().getObjectModel(), id);
   cocoon.getRequest().removeAttribute(this.id);
   }

cvs commit: cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching EventRegistry.java

2003-07-12 Thread ghoward

ghoward 2003/07/12 21:40:52

  Modified:src/scratchpad/src/org/apache/cocoon/caching/impl
EventAwareCacheImpl.java
   src/scratchpad/src/org/apache/cocoon/caching/validity
Event.java
  Added:   src/scratchpad/src/org/apache/cocoon/caching/impl
DefaultEventRegistryImpl.java
EventRegistryDataWrapper.java
   src/scratchpad/src/org/apache/cocoon/caching
EventRegistry.java
  Log:
  refactoring - a little more mature now.
  
  Revision  ChangesPath
  1.2   +114 -126  
cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/impl/EventAwareCacheImpl.java
  
  Index: EventAwareCacheImpl.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/scratchpad/src/org/apache/cocoon/caching/impl/EventAwareCacheImpl.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- EventAwareCacheImpl.java  1 Jul 2003 04:38:48 -   1.1
  +++ EventAwareCacheImpl.java  13 Jul 2003 04:40:51 -  1.2
  @@ -45,70 +45,59 @@
   */
   package org.apache.cocoon.caching.impl;
   
  -import java.util.Collection;
   import java.util.Iterator;
   import java.util.Map;
   
  +import org.apache.avalon.framework.activity.Initializable;
   import org.apache.avalon.framework.component.ComponentException;
   import org.apache.avalon.framework.component.ComponentManager;
   import org.apache.cocoon.ProcessingException;
   import org.apache.cocoon.caching.CachedResponse;
  +import org.apache.cocoon.caching.EventRegistry;
   import org.apache.cocoon.caching.PipelineCacheKey;
   import org.apache.cocoon.caching.validity.Event;
   import org.apache.cocoon.caching.validity.EventValidity;
  -import org.apache.commons.collections.MultiHashMap;
   import org.apache.excalibur.source.SourceValidity;
   import org.apache.excalibur.source.impl.validity.AggregatedValidity;
   
   /**
* Very experimental start at external cache invalidation.
* Warning - API very unstable.  Do not use!  
  + * (But it's getting closer!)
* 
* This implementation holds all mappings between Events and PipelineCacheKeys 
* in two MultiHashMap to facilitate efficient lookup by either as Key.
* 
  - * TODO: Implement Persistence.
* TODO: Test performance.
  + * TODO: Handle MultiThreading
* 
* @author Geoff Howard ([EMAIL PROTECTED])
* @version $Id$
*/
  -public class EventAwareCacheImpl extends CacheImpl {
  +public class EventAwareCacheImpl 
  +extends CacheImpl 
  +implements Initializable {
   
  +private ComponentManager m_manager;
  +
  + private EventRegistry m_eventRegistry;
   
/** 
  - * Clears the entire Cache, including all held event-pipeline key 
  + * Clears the entire Cache, including all registered event-pipeline key 
* mappings..
  - * 
  -  * @see org.apache.cocoon.caching.Cache#clear()
 */
public void clear() {
super.clear();
  -m_keyMMap.clear();
  -m_eventMMap.clear();
  - }
  -
  -/**
  -  * Compose
  - * 
  - * TODO: the Maps should not be initialized here (and should not be hardcoded 
size)
  - * TODO: Attempt to recover/deserialize persisted event listing. (but not here)
  - * 
  - * @see 
org.apache.avalon.framework.component.Composable#compose(org.apache.avalon.framework.component.ComponentManager)
  -  */
  - public void compose(ComponentManager manager) throws ComponentException {
  - super.compose(manager);
  -this.m_eventMMap = new MultiHashMap(100); // TODO: don't hardcode initial 
size
  -this.m_keyMMap = new MultiHashMap(100); // TODO: don't hardcode initial size
  +m_eventRegistry.clear();
}
   
  -
  -
/** 
  - * When a new Pipeline key is stored, it needs to be registered in 
  - * the local Event-PipelineKey mapping.
  + * When a new Pipeline key is stored, it needs to be have its 
  + * codeSourceValidity/code objects examined.  For every 
  + * codeEventValidity/code found, its codeEvent/code will be 
  + * registered with this key in the codeEventRegistry/code.
* 
  -  * @see org.apache.cocoon.caching.Cache#store(java.util.Map, 
org.apache.cocoon.caching.PipelineCacheKey, org.apache.cocoon.caching.CachedResponse)
  + * codeAggregatedValidity/code is handled recursively.
 */
public void store(Map objectModel,
PipelineCacheKey key,
  @@ -116,125 +105,124 @@
throws ProcessingException {
   SourceValidity[] validities = response.getValidityObjects();
   for (int i=0; i validities.length;i++) {
  -if (validities[i] instanceof AggregatedValidity) {
  - // AggregatedValidity must be

38 matches

Mail list logo