Re: [Kernel22] How to develop a component?

[Nicola Ken Barozzi]

Stefano Mazzocchi wrote:
...
I think it's a good time for cleaning up what avalon did wrong, simplify 
as much as we can and tune it for our needs.

But I'm wide open to suggestions, as long as we move away from avalon.
A bit OT... I can't stand Cocoon not be able to build properly in Gump, 
and IMHO getting away from Avalon will greatly help in this.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Re: cvs commit: cocoon-2.1/src/blocks/web3/samples samples.xml

[Antonio Gallardo]

Joerg Heinicke dijo:
> On 06.04.2004 00:55, Antonio Gallardo wrote:
>
>>>Moreover, even if XML parsers are able to recognize encoding, it's very
>>>bad practice to have an XML file without the encoding property set.
>>
>> We have the default enconding that is UTF-8 in this case.
>
> Of course, but not everybody knows that UTF-8 is the default encoding.

!  I thought this is part of the first lesson of XML.


> So I'm with Stefano, it's bad practice, while I'm ok with converting
> ISO-8859-1 encoded files to UTF-8 of course.

:-D

Best Regards,

Antonio Gallardo

Re: Cocoon Stammtisch, Vienna, Austria

[Joerg Heinicke]

On 05.04.2004 09:50, Reinhard Pötz wrote:

Do you like to meet people interested in Cocoon? Do you have the chance 
to come to Vienna on April, 19th or May, 3rd?
I don't know how big the conflict might be, but the Amsterdam Stammtisch 
is already on April, 19th (including two conferences like XMLEurope).

Joerg

Re: cvs commit: cocoon-2.1/src/blocks/web3/samples samples.xml

[Joerg Heinicke]

On 06.04.2004 00:55, Antonio Gallardo wrote:

Moreover, even if XML parsers are able to recognize encoding, it's very
bad practice to have an XML file without the encoding property set.
We have the default enconding that is UTF-8 in this case.
Of course, but not everybody knows that UTF-8 is the default encoding. 
So I'm with Stefano, it's bad practice, while I'm ok with converting 
ISO-8859-1 encoded files to UTF-8 of course.

Joerg

Re: [build system] - Fine grain inclusion of optional libs?

[Joerg Heinicke]

On 05.04.2004 14:35, Vadim Gritsenko wrote:

BTW, jstyle.jar might be only be of interest for the xsp block, so it 
can possibly be moved to this block.
You can safely drop jstyle.
What about
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/xsp/conf/xsp-program-language.xconf?annotate=1.2#24
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/xsp/java/org/apache/cocoon/components/language/programming/java/JstyleFormatter.java
??
Really simply remove it?
Joerg

[Javaflow] - Recalling a contianuation throws a NPE

[Antonio Gallardo]

Hi:

I am back to work. While figuring out how to implement Groovy Flow Engine
on the base of JavaFlow I meet the following error:

1-Go to calculator demo and give the value of "a" variable.
2-Send the page.
3-Copy the current URI.
4-Open a new browser window and paste the URI.
5-You got a NPE:

java.lang.NullPointerException
at java.lang.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:980)
at java.lang.Float.parseFloat(Float.java:222)
at
org.apache.cocoon.samples.flow.java.CalculatorFlow.getNumber(CalculatorFlow.java:53)
at
org.apache.cocoon.samples.flow.java.CalculatorFlow.doCalculator(CalculatorFlow.java:26)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.cocoon.components.flow.java.JavaInterpreter.handleContinuation(JavaInterpreter.java:238)
at
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:120)

Best Regards,

Antonio Gallardo

Re: cvs commit: cocoon-2.1/src/blocks/web3/samples samples.xml

[Antonio Gallardo]

Stefano Mazzocchi dijo:
> Antonio Gallardo wrote:
>
>> Stefano Mazzocchi dijo:
>>
>>>[EMAIL PROTECTED] wrote:
>>>
>>>
antonio 2004/04/05 05:25:36

  Log:
  removing encoding="ISO-8859-1"
>>>
>>>Why?
>>
>>
>> Since UTF-8 is the new standard, I thought it was good to move our code
>> to
>> UTF-8.
>
> Did you convert the files or you just removed the encoding?

Converted and removed as needed. :-D

> Moreover, even if XML parsers are able to recognize encoding, it's very
> bad practice to have an XML file without the encoding property set.

We have the default enconding that is UTF-8 in this case.

Best Regards,

Antonio Gallardo

Re: [Kernel22] How to develop a component?

[Stefano Mazzocchi]

Carsten Ziegeler wrote:

I'm trying to figure out what the current kernel already provides 
and what not. 

Let's forget all the xml (descriptors etc) for a moment. Imagine I 
want to write a block, that provides - let's say a special file 
generator - that can be used in other blocks (in my app block).

Now, obviously this generator will implement our Cocoon Generator interface.
What else does the kernel already provide for the component lifecycle?
(Logging, Configuration etc.) 

Or is this a to discuss/do?
I guess it's a to-do/to-discuss.

The block design didn't deal with component lifecycle because that's 
another concern (and, originally, it was supposed to be taken care of by 
avalon).

I don't know Pier's ideas about this.

I think it's a good time for cleaning up what avalon did wrong, simplify 
as much as we can and tune it for our needs.

But I'm wide open to suggestions, as long as we move away from avalon.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: new blocks.properties way more painful to use

[Stefano Mazzocchi]

Geoff Howard wrote:

Ugo Cei wrote:

Il giorno 05/apr/04, alle 16:54, Geoff Howard ha scritto:

Ugo Cei wrote:

Il giorno 05/apr/04, alle 15:38, Geoff Howard ha scritto:

Is "/" "." that much more harder than "arrow down" "x" ?

The coommand for findiing the next match is "n" not "/".


Actually, it's /-enter (a blank search - it's an old habit) -
they both work.
Geoff

/-enter is two keystrokes instead of one ;-)
:) true.
First, not everyone is a VI user.

Second, we have introduced an inconsistency between blocks.properties 
and build.properties semantics.

Third, if it isn't broke don't fix it.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: cvs commit: cocoon-2.1/src/blocks/web3/samples samples.xml

[Stefano Mazzocchi]

Antonio Gallardo wrote:

Stefano Mazzocchi dijo:

[EMAIL PROTECTED] wrote:


antonio 2004/04/05 05:25:36

 Log:
 removing encoding="ISO-8859-1"
Why?


Since UTF-8 is the new standard, I thought it was good to move our code to
UTF-8.
Did you convert the files or you just removed the encoding?

Moreover, even if XML parsers are able to recognize encoding, it's very 
bad practice to have an XML file without the encoding property set.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: cvs commit: cocoon-2.1/src/blocks/linotype/samples/images/icons unblock.gif block.gif undo.gif redo.gif underline.gif

[Stefano Mazzocchi]

Ugo Cei wrote:
Il giorno 05/apr/04, alle 13:43, [EMAIL PROTECTED] ha scritto:

  Log:
  committed linotype 1.2. Note: it's not working properly but I don't 
want to stop others from contributing.

Can you give us a brief overview of your changes and what's not working?
I've fixed it today during a boring meeting ;-)

Committing shortly, along with an updated TODO file.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: cvs commit: cocoon-2.1/src/blocks/web3/samples samples.xml

[Antonio Gallardo]

Stefano Mazzocchi dijo:
> [EMAIL PROTECTED] wrote:
>
>> antonio 2004/04/05 05:25:36
>>
>>   Log:
>>   removing encoding="ISO-8859-1"
>
> Why?

Since UTF-8 is the new standard, I thought it was good to move our code to
UTF-8.

Best Regards,

Antonio Gallardo

Re: cvs commit: cocoon-2.1/src/blocks/linotype/samples/images/icons unblock.gif block.gif undo.gif redo.gif underline.gif

[Ugo Cei]

Il giorno 05/apr/04, alle 13:43, [EMAIL PROTECTED] ha scritto:

  Log:
  committed linotype 1.2. Note: it's not working properly but I don't 
want to stop others from contributing.

Can you give us a brief overview of your changes and what's not working?

	Ugo

RE: [RT] - XUL revisited....

[Corin Moss]

Hiya,

+++1

I can't quite say how many plus ones the idea of XUL support from Cforms
gets from me.  As I mentioned earlier, we've been using XUL in
production to drive a web based GUI for a couple of months now.  The
feature set we get is just amazing.  The other interesting thing, in
relation to Luke's point is that there is actually a flash based XUL
engine - meaning that those 98% could still make use of the XUL.  It's
not fully featured yet, and does carry a non OSS license with it - but
bear it in mind:

http://zulu.netspedition.com/zulu/main/overview.shtml

The other thing to consider here is *shudder* Longhorn.   M'soft have
made it very clear that their next gen GUI interface will be based
around a beast incredibly similar to XUL.  If we start with XUL support
now, adapting a Longhorn interface also becomes fairly trivial.

I'm willing to help in any XUL development exercise.

Corin




-Original Message-
From: luke hubbard [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 6 April 2004 2:32 a.m.
To: [EMAIL PROTECTED]
Subject: Re: [RT] - XUL revisited



Sylvain Wallez wrote:
> "if we have the control"... Unfortunately, 90% of people out there use
IE...

98% of people out there have Flash Player. :)
Flash is installed on most machines, it can load and parse xml, and has
a wide range of ui components. It would be great if we could create a
flash component to render cforms that could be used from within the
flash IDE. Also a standalone swf file that could be embedded into a html
page to display a form for ppl without the IDE. As we all  know flash is
not open source, but the swf format is. Im not sure if there are
licencing issues with regard to distributing swf file(s) that contains
the MM ui components. Would need to read the EULA carefuly. Even if it
was a problem I have heard there are a group of developers working on
open source ui components.

Anyway just an idea. I have a few more regarding cocoon & flash
intergration but they can wait for another day. Im not against XUL,
think it would be the right choice for some apps. Would be cool to have
multiple cforms styling options.

Regards,
Luke




CAUTION: This e-mail and any attachment(s) contains information
that is intended to be read only by the named recipient(s). It
may contain information that is confidential, proprietary or the
subject of legal privilege. This information is not to be used by
any other person and/or organisation. If you are not the intended
recipient, please advise us immediately and delete this e-mail
from your system. Do not use any information contained in it.


For more information on the Television New Zealand Group, visit
us online at http://www.tvnz.co.nz

Re: [RT] Flash & Cocoon

[Sylvain Wallez]

luke hubbard wrote:

Hi,
 
Thanks to Sylvain I have finally got round to writing this RT.


Hey, I'm glad I could help this to get written down ;-)




P.S. I would love to help make any of the above a reality.


I'll be mostly offline in the next 2 days, but will follow up on this 
when coming back.

Sylvain

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

Re: Scheme Continuations vs Brakes Continuations was Re: Groovy support in Cocoon

[Christopher Oliver]

Stephan Michels wrote:

First, I'm glad to hear more input ;-) Your mail took some time
to parse it.
Am Mo, den 05.04.2004 schrieb Christopher Oliver um 18:47:
 

OK, IIUC there are three modes of execution of the instrumented code:

1) isCapturing
During this mode the JVM call stack is unwound and its state captured in 
the continuation call stack.
2) isRestoring
During this mode a saved call stack in a continuation is recreated on 
the JVM stack.
3) !isCapturing && !isRestoring
This is the "normal" execution of the JVM  - no modifications are made 
to the JVM call stack or to the continuation call stack.
   

Correct.

 

This is achieved by inserting code before each invoke instruction to 
copy local variables from the continuation stack to the JVM stack and to 
reset the program counter to the value saved in the continuation stack 
if "isRestoring" is true, and by inserting code after each invoke 
instruction to copy the values of local variables from the JVM call 
stack as well as the program counter into the continuation call stack if 
"isCapturing" is true.
   

Yes, but the code for the restore procedure is at the begining of the
method not the before the invocation, but anyway..
 

Yes, of course. Sorry for not being more accurate.

I need some pseudo code for myself ;-) Current situation:

void myFlow() {
 if (continuation.isRestoring()) {
continuation.getStack().popLocalVariables();
continuation.getStack().popOperandStack();
continuation.getStack().popReference(); // used for the  
   //method invocation
push(null) as many null object as the method invovation need for 
   the parameters
goto continuation.getStack().popLastProcessCounter();
 }

 [...]

label 1:
 invoke MySubFlow.bla();
 if (continuation.isCapturing() {
remove the return value (is unimportant)
continuation.getStack().pushLocalVariables();
continuation.getStack().pushOperandStack();
continuation.getStack().pushLastProcessCounter(label 1);
continuation.getStack().pushReference(this);
return null or void;
 }
 [...]
}
 

OK.

To make continuations more "Scheme-like" it must be possible to 
construct a continuation without modifying the JVM call stack (thus the 
current method invocation can "continue as normal").

To make this possible the byte-code transformer could work like this:
1) Insert code before an invoke instruction to push local vars and the 
pc onto the continuation stack if (!isRestoring && !isCapturing)
2) Insert code after an invoke instruction to pop those values from the 
continuation stack if (!isRestoring && !isCapturing)
3) If (isRestoring == true) the pre-invoke code would work as it does now.
4) If (isCapturing == true) the post-invoke code would simply cause the 
current method invocation to return to its caller without modifying the 
continuation stack - since it is already set up from (1). When the JVM 
stack is completely unwound another continuation will take the place of 
this one and that new continuation would be in "isRestoring" mode until 
it is recreated on the JVM stack at which point it would enter 
(!isRestoring && !isCapturing) mode.
   

Okay to recapitulate IIUC. Your proposal:

void myFlow() {
 if (continuation.isRestoring()) {
continuation.getStack().popLocalVariables();
continuation.getStack().popOperandStack();
goto continuation.getStack().popLastProcessCounter();
 }
 [...]

 continuation.getStack().pushLocalVariables();
 continuation.getStack().pushOperandStack();
 continuation.getStack().pushLastProcessCounter(label 1);
label 1:
 invoke MySubFlow.bla();
 if (continuation.isCapturing() {
return null or void;
 } else {
continuation.getStack().popLocalVariables();
continuation.getStack().popOperandStack();
continuation.getStack().popLastProcessCounter();
 }
 [...]
}
Yes, this has the benefit to call "uninstrumented" code, but
the complete frame must be captured and restored for every invocation.
 

See my second message regarding this.

The user interface to this might look something like this:

public class Continuation {
   // Empty continuation for use as an escape procedure
   public static final Continuation SUICIDE;
   

I didn't get the role of SUICIDE.

 

   // Invoke a captured continuation - it will replace the current 
continuation. I.e. the current JVM call stack will be unwound, the call 
stack saved in this object will be recreated on the JVM call stack, and 
the method invocation in which this object was created will return with 
"returnValue".
   public void invoke(Object returnValue);
   

Do you want to use the "returnValue" to return the WebContinuation in
sendPageAndWait() ? The problem I see is that you suspend the thread
at a method invocation not at the end of the method.
 

   // Get the current continuation -
   public static Continuation getCurrentContinuation();
   // Entry point to the instrumented code (precondition: c

Re: new blocks.properties way more painful to use

[Geoff Howard]

Ugo Cei wrote:

Il giorno 05/apr/04, alle 16:54, Geoff Howard ha scritto:

Ugo Cei wrote:

Il giorno 05/apr/04, alle 15:38, Geoff Howard ha scritto:

Is "/" "." that much more harder than "arrow down" "x" ?

The coommand for findiing the next match is "n" not "/".


Actually, it's /-enter (a blank search - it's an old habit) -
they both work.
Geoff

/-enter is two keystrokes instead of one ;-)
:) true.

Geoff

Re: new blocks.properties way more painful to use

[Ugo Cei]

Il giorno 05/apr/04, alle 16:54, Geoff Howard ha scritto:

Ugo Cei wrote:

Il giorno 05/apr/04, alle 15:38, Geoff Howard ha scritto:
Is "/" "." that much more harder than "arrow down" "x" ?

The coommand for findiing the next match is "n" not "/".
Actually, it's /-enter (a blank search - it's an old habit) -
they both work.
Geoff

/-enter is two keystrokes instead of one ;-)

	Ugo

Re: [Kernel22] How to develop a component?

[Stefano Mazzocchi]

Carsten Ziegeler wrote:

Gianugo Rabellino wrote:

Carsten Ziegeler wrote:

I'm trying to figure out what the current kernel already 
provides and 

what not.

Let's forget all the xml (descriptors etc) for a moment. Imagine I 
want to write a block, that provides - let's say a special file 
generator - that can be used in other blocks (in my app block).

Now, obviously this generator will implement our Cocoon 
Generator interface.

What else does the kernel already provide for the component 
lifecycle?

(Logging, Configuration etc.)

Or is this a to discuss/do?
JFYI, Pier is in vacation ATM, so you're better not hold your 
breath... :-)

Ah, thanks! I thought there are perhaps more people out there (Stefano?)
that know the answer.
pretty busy these days, will try to catch up later.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: cvs commit: cocoon-2.1/src/blocks/web3/samples samples.xml

[Stefano Mazzocchi]

[EMAIL PROTECTED] wrote:

antonio 2004/04/05 05:25:36

  Log:
  removing encoding="ISO-8859-1"
Why?

--
Stefano.

[RT] Flash & Cocoon

[luke hubbard]

Hi, 
 
Thanks to Sylvain I have finally got round to 
writing this RT.
 
-
 
What makes Cocoon great for Flash developers 
today.
 
1) No need to know Java to use 
Cocoon.
2) FlowScript should be easy to pickup if you 
already know ActionScript (or vice versa) as they are both based on 
_javascript_ 1.5
3) Cocoon loves XML, as does Flash. Flash 
can use databinding to bind UI components (such as a datagrid) to the xml result 
of a pipeline. 
4) Cocoon can host web services (Am I right 
about this ?) Flash can consume web services.
5) Cocoon is mature and open 
source.
 
6) Anything I missed ?
 
-
 
What could we add to Cocoon to make it 
better for Flash developers.
 
1) Flash Remoting 
 

Flash remoting could be used to call 
flowscript functions, public pipelines, access components, 
etc.
 
The OpenAMF project provides open source Flash 
remoting for Java. However its licenced under LGPL and IMHO is not low level 
enough to be intergrated with cocoon. It has a lot of code for dealing with 
EJBs, JINI, etc. OpenAMF uses ASTranslator for converting between AMF 
(ActionScript Message Format) and Java. ASTranslator has a BSD style licence so 
could be used in Cocoon to implement our own Flash Remoting. 
 
Q: Why do we need remoting if flash can consume web 
services?
A: Remoting is faster (binary protocol) and does not 
use lots of memory in Flash Player. 
 
2) CForms Flash Styling 
 
Would it not be totally cool to be able 
to provide a rich user interface to cforms. I think it would be legal 
(need to check) and possible to create a component for use in Flash IDE and a 
standalone swf file that could be used to load cforms xml and then render the 
form using flash UI components. This would work in a similar way to 
DENG. http://claus.packts.net/  

 
3) XML Socket Server
 
There are a number of xml socket servers for 
Flash (Comms Server, and Unity 2 come to mind). However we need an open 
source server that scales well and can be intergrated with the rest of 
the cocoon. I think it would be best to build our own using a SEDA 
architecture and NIO for networking.
 
4) Open Source FLEX 
 
FLEX is a new technology from MM for creating RIA 
(Rich Internet Applications).
 
How the FLEX server (deployed in J2EE 
container) works:
MXML + MX ActionScript Classes + MX UI 
Components -> Flash Compiler  -> 
SWF File
 
If we wanted to create our own FLEX we would need 
our own Flash Compiler (with support for AS 2), our own versions of all the MM 
ActionScript classes (all the ones starting with mx), and last but not least our 
own UI components. This is quite a lot. But that does not mean I don't think it 
will happen. I'm on the beta program for the latest version of 
KineticFusion (which supports AS 2) and talking to its creator about 
possible Cocoon intergration. Unfortunatly its not open source, but im sure that 
it wont have a crazy $12000 price tag like FLEX when its released. Who knows 
maybe there is another Flash compiler out there that could be used 
instead.
 
5) Any more ideas ?
 

-
 
Right I think thats about it. I'm of for dinner 
now. :)
 
Luke
 
P.S. I would love to help make any of the above a 
reality. 
 
Luke 
Hubbard | Lead Developer | Symbiotic Business Systems020 7681 0477 | [EMAIL PROTECTED] | http://www.symbiosys.biz
 

Scheme Continuations vs Brakes Continuations was Re: Groovy support in Cocoon

[Stephan Michels]

First, I'm glad to hear more input ;-) Your mail took some time
to parse it.

Am Mo, den 05.04.2004 schrieb Christopher Oliver um 18:47:
> OK, IIUC there are three modes of execution of the instrumented code:
> 
> 1) isCapturing
> During this mode the JVM call stack is unwound and its state captured in 
> the continuation call stack.
> 2) isRestoring
> During this mode a saved call stack in a continuation is recreated on 
> the JVM stack.
> 3) !isCapturing && !isRestoring
> This is the "normal" execution of the JVM  - no modifications are made 
> to the JVM call stack or to the continuation call stack.

Correct.

> This is achieved by inserting code before each invoke instruction to 
> copy local variables from the continuation stack to the JVM stack and to 
> reset the program counter to the value saved in the continuation stack 
> if "isRestoring" is true, and by inserting code after each invoke 
> instruction to copy the values of local variables from the JVM call 
> stack as well as the program counter into the continuation call stack if 
> "isCapturing" is true.

Yes, but the code for the restore procedure is at the begining of the
method not the before the invocation, but anyway..

I need some pseudo code for myself ;-) Current situation:

void myFlow() {
  if (continuation.isRestoring()) {
 continuation.getStack().popLocalVariables();
 continuation.getStack().popOperandStack();
 continuation.getStack().popReference(); // used for the  
//method invocation
 push(null) as many null object as the method invovation need for 
the parameters
 goto continuation.getStack().popLastProcessCounter();
  }

  [...]

label 1:
  invoke MySubFlow.bla();

  if (continuation.isCapturing() {
 remove the return value (is unimportant)
 continuation.getStack().pushLocalVariables();
 continuation.getStack().pushOperandStack();
 continuation.getStack().pushLastProcessCounter(label 1);
 continuation.getStack().pushReference(this);
 return null or void;
  }

  [...]
}

> To make continuations more "Scheme-like" it must be possible to 
> construct a continuation without modifying the JVM call stack (thus the 
> current method invocation can "continue as normal").
> 
> To make this possible the byte-code transformer could work like this:
> 1) Insert code before an invoke instruction to push local vars and the 
> pc onto the continuation stack if (!isRestoring && !isCapturing)
> 2) Insert code after an invoke instruction to pop those values from the 
> continuation stack if (!isRestoring && !isCapturing)
> 3) If (isRestoring == true) the pre-invoke code would work as it does now.
> 4) If (isCapturing == true) the post-invoke code would simply cause the 
> current method invocation to return to its caller without modifying the 
> continuation stack - since it is already set up from (1). When the JVM 
> stack is completely unwound another continuation will take the place of 
> this one and that new continuation would be in "isRestoring" mode until 
> it is recreated on the JVM stack at which point it would enter 
> (!isRestoring && !isCapturing) mode.

Okay to recapitulate IIUC. Your proposal:

void myFlow() {
  if (continuation.isRestoring()) {
 continuation.getStack().popLocalVariables();
 continuation.getStack().popOperandStack();
 goto continuation.getStack().popLastProcessCounter();
  }

  [...]

  continuation.getStack().pushLocalVariables();
  continuation.getStack().pushOperandStack();
  continuation.getStack().pushLastProcessCounter(label 1);

label 1:
  invoke MySubFlow.bla();

  if (continuation.isCapturing() {
 return null or void;
  } else {
 continuation.getStack().popLocalVariables();
 continuation.getStack().popOperandStack();
 continuation.getStack().popLastProcessCounter();
  }

  [...]
}

Yes, this has the benefit to call "uninstrumented" code, but
the complete frame must be captured and restored for every invocation.

> The user interface to this might look something like this:
> 
> public class Continuation {
> // Empty continuation for use as an escape procedure
> public static final Continuation SUICIDE;

I didn't get the role of SUICIDE.

> // Invoke a captured continuation - it will replace the current 
> continuation. I.e. the current JVM call stack will be unwound, the call 
> stack saved in this object will be recreated on the JVM call stack, and 
> the method invocation in which this object was created will return with 
> "returnValue".
> public void invoke(Object returnValue);

Do you want to use the "returnValue" to return the WebContinuation in
sendPageAndWait() ? The problem I see is that you suspend the thread
at a method invocation not at the end of the method.

> // Get the current continuation -
> public static Continuation getCurrentContinuation();
> // Entry point to the instrumented code (precondition: cannot 

Re: [PROP] Repository interface

[Guido Casper]

Rolf Kulemann wrote:
On Mon, 2004-04-05 at 13:38, Guido Casper wrote:

Rolf Kulemann wrote:

[Related to http://issues.apache.org/bugzilla/show_bug.cgi?id=28189]


As for WebDAVRepsoitoryVersioningHelper.setVersioned(): I don't think it
is a good idea to throw an 
UnsupportedOperationException only under certain conditions.


Agreed.

Maybe it makes sense to split setVersioned(String, boolean) into two
methods
1.) setVersioned(String)
2.) unsetVersioned(String)
in order to be more flexible in the implementation decisions?
Why should that be more flexible?


Because I can decide if I implement both or only one method. The reason
for the split is, I can use the NotSupportedException more accurate.
Well, throwing UnsupportedOperationException is not my final goal for 
either :-)

I guess having too many of those might indicate an unappropriate interface.



TBH I'm not so sure wether these should be part of the Repository 
interface at all as it looks like being geared towards WebDAV only (but 
I don't know right now).


Ok, I didn't mean the Repsoitory interface, was a litlle bit confusing
maybe, but the RepositoryVersioningHelper. And if a repository does not
support versioning it has no helper at all.
Yes, but I was talking about the RepositoryVersioningHelper as well (a 
single repository having both versioned and non-versioned resources) 
which is exactly the point of my comment above.

I think it might be a wise move to first gather experiences with other 
implementations (instead of adding more operations coming directly from 
a WebDAV context).

Guido

--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn   http://www.s-und-n.de
-

RE: Cocoon and Hibernate

[Hugo Burm]

The authors of Hibernate make a statement on their website that we are
allowed to use the Hibernate API without affecting our own license:

"Using Hibernate (by importing Hibernate's public interfaces in your Java
code), and extending Hibernate (by subclassing) is considered by the authors
of Hibernate to be dynamic linking. Hence our interpretation of the LGPL is
that the use of the unmodified Hibernate source or binary does not affect
the license of your application code."

But during the Gettogether in Gent, last autumn 2003, while discussing this
Hibernate issue, Stefano Mazzocchi told us that the ASF will not take the
risk. The risk is that a GPL contribution may GPL-ify a whole subtree of the
ASF code. At least that is what I understand of this issue.

So I think we must wait for the new block mechanism that will make it easier
to maintain a block outside of the CVS.

To Leszek: I am trying to maintain a few Wiki pages about Hibernate on the
wiki.cocoondev.org. These pages tend to be outdated (especially nowadays,
after the recent Cocoon "renaming game"). I have been thinking about a
Hibernate block on cocoondev.org. So feel free to contact me.


Hugo Burm


> -Original Message-
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 05, 2004 5:23 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Cocoon and Hibernate
>
>
> Leszek Gawron wrote:
>
> >On Mon, Apr 05, 2004 at 03:24:26PM +0200, Reinhard Pötz wrote:
> >
> >
> >>Leszek Gawron wrote:
> >>
> >>
> >>
> >>>I have an application written using cocoon ( flow + jx )
> and hibernate. I
> >>>could strip it down to a simple example and provide a
> patch. What form
> >>>should
> >>>it take? Another block like OJB? A scratchpad directory ?
> >>>
> >>>The case is nearly the same as in hibernate  - there can
> be no sample
> >>>working
> >>>out of the box due to the licensing but I think it will be
> simpler to run
> >>>(hibernate is not as sensitive to libraries version and it
> does not use
> >>>class
> >>>enhancment, only reflection)
> >>>
> >>>If anyone is interested please advise.
> >>>   lg
> >>>
> >>>
> >>>
> >>>
> >>>
> >>Sorry, but we can't add Hibernate to our CVS because it
> licensed under
> >>LGPL. You could ask at cocoondev.org.
> >>
> >>
> >I am not talking about adding hibernate. I am proposing to
> add hibernate
> >sample same way ojb sample is added - the user has to add
> some libraries
> >himself before building.
> >
> >
>
> This should be possible as long as samples are coded against some
> standard, non-(L)GPL API (JDO?) and do not use any hibernate classes
> directly. We can not also host mocks of hibrnate classes.
>
>
> Vadim
>
>

Re: [RT] - XUL revisited....

[luke hubbard]

> Why wait? Ideas are always interesting to share, even more if others can 
> pick them up and implement them.
> 
> Sylvain

Ok, will start another thread. 
Just need a little time to gether my thoughts.
Will try to cover FLEX aswell.

Luke

Re: new blocks.properties way more painful to use

[Tim Larson]

On Sun, Apr 04, 2004 at 06:18:07PM -0400, Stefano Mazzocchi wrote:
> in the past I was used to:
> 
>  1) cp blocks.properties local.blocks.properties
>  2) vi local.blocks.properties
>  3) uncomment the blocks that I wanted to exclude
> 
> Today, I have to go thru a bunch of include and change them from true to 
> false. Much more hassle than just uncommenting/commenting one line.

We could auto-generate two sample config files, one "excluding"
everything and the other "including" everything.  Then you could
pick one of these to copy and comment out the lines you want to
have fall back to the default.

Personally, I like the clarity of the new "include=" syntax.

--Tim Larson

Re: [PROP] Repository interface

[Rolf Kulemann]

On Mon, 2004-04-05 at 13:38, Guido Casper wrote:
> Rolf Kulemann wrote:
> > [Related to http://issues.apache.org/bugzilla/show_bug.cgi?id=28189]
> > 
> > 
> > As for WebDAVRepsoitoryVersioningHelper.setVersioned(): I don't think it
> > is a good idea to throw an 
> > UnsupportedOperationException only under certain conditions.
> > 
> > 
> > Agreed.
> > 
> > Maybe it makes sense to split setVersioned(String, boolean) into two
> > methods
> > 
> > 1.) setVersioned(String)
> > 2.) unsetVersioned(String)
> > 
> > in order to be more flexible in the implementation decisions?
> 
> Why should that be more flexible?

Because I can decide if I implement both or only one method. The reason
for the split is, I can use the NotSupportedException more accurate.

> 
> TBH I'm not so sure wether these should be part of the Repository 
> interface at all as it looks like being geared towards WebDAV only (but 
> I don't know right now).

Ok, I didn't mean the Repsoitory interface, was a litlle bit confusing
maybe, but the RepositoryVersioningHelper. And if a repository does not
support versioning it has no helper at all.

> 
> > 
> > 
> > A setVersioned(uri, false) might be implemented by deleting and  
> > recreating the 
> > resource (making copies for safety and checking for auto-versioning).
> > 
> > 
> > Ehem, how can I check for auto-versioning?
> 
> It's a property of the resource. Wether this property is already set 
> upon resource creation usually depends on some server setting.
> 
> I just changed the code a little bit. However it's now a little hacky 
> and needs completion as after the copy you should check wether the 
> destination is version controlled and if that's the case undo the move 
> (to keep the old version history) and return false.
> 
> I don't know the details of how to check wether a resource is under 
> version control right now (would have to check the DeltaV spec).

I will do that. Thanks.
-- 
Regards,

Rolf Kulemann

Re: Groovy support in Cocoon

[Christopher Oliver]

After thinking about this a few more minutes over coffee, I like the 
idea of constructing the continuation stack as the JVM stack is unwound 
(that way "normal" code doesn't encounter any overhead other than the 
tests for isRestoring() and isCapturing(). So perhaps what we could do 
when Continuation.getCurrentContinuation() is called is to unwind the 
JVM stack, constructing the continuation stack, and then immediately 
restore it returning the newly created continuation object (which will 
contain a copy of the continuation stack we just created). If the 
continuation object is invoked we will again unwind the current JVM 
stack, but this time there's no need to capture it.

Chris

Christopher Oliver wrote:

Stephan Michels wrote:

Am Mo, den 05.04.2004 schrieb Christopher Oliver um 4:42:
 

The current implementation needs some work to qualify as 
"generalized Java continuations". It would be nice to make it work 
more like Scheme continuations:

1) When you access the "current" continuation, it captures the call 
stack up to but not including the current method (and makes a 
(shallow) copy of it). The current method continues as normal.   


What to you mean with "continues as normal". The current impl. stops the
execution of the method with null as return value, if the cuntinuation
is suspended. Then the continuation captures the object of the method
call and the current frame.
 

OK, IIUC there are three modes of execution of the instrumented code:

1) isCapturing
During this mode the JVM call stack is unwound and its state captured 
in the continuation call stack.
2) isRestoring
During this mode a saved call stack in a continuation is recreated on 
the JVM stack.
3) !isCapturing && !isRestoring
This is the "normal" execution of the JVM  - no modifications are made 
to the JVM call stack or to the continuation call stack.

This is achieved by inserting code before each invoke instruction to 
copy local variables from the continuation stack to the JVM stack and 
to reset the program counter to the value saved in the continuation 
stack if "isRestoring" is true, and by inserting code after each 
invoke instruction to copy the values of local variables from the JVM 
call stack as well as the program counter into the continuation call 
stack if "isCapturing" is true.

To make continuations more "Scheme-like" it must be possible to 
construct a continuation without modifying the JVM call stack (thus 
the current method invocation can "continue as normal").

To make this possible the byte-code transformer could work like this:

1) Insert code before an invoke instruction to push local vars and the 
pc onto the continuation stack if (!isRestoring && !isCapturing)
2) Insert code after an invoke instruction to pop those values from 
the continuation stack if (!isRestoring && !isCapturing)
3) If (isRestoring == true) the pre-invoke code would work as it does 
now.
4) If (isCapturing == true) the post-invoke code would simply cause 
the current method invocation to return to its caller without 
modifying the continuation stack - since it is already set up from 
(1). When the JVM stack is completely unwound another continuation 
will take the place of this one and that new continuation would be in 
"isRestoring" mode until it is recreated on the JVM stack at which 
point it would enter (!isRestoring && !isCapturing) mode.

The user interface to this might look something like this:

public class Continuation {
   // Empty continuation for use as an escape procedure
   public static final Continuation SUICIDE;
   // Invoke a captured continuation - it will replace the current 
continuation. I.e. the current JVM call stack will be unwound, the 
call stack saved in this object will be recreated on the JVM call 
stack, and the method invocation in which this object was created will 
return with "returnValue".
   public void invoke(Object returnValue);
   // Get the current continuation -
   public static Continuation getCurrentContinuation();
   // Entry point to the instrumented code (precondition: cannot 
be called recursively and method.getDeclaringClass() must be 
instrumented)
   public static Object invoke(Object obj, Method method, Object[] 
args);
}

Below is some pseudo-code that shows how this would work with Cocoon:

public class JavaInterpreter {
   // ...
   public void callFunction(String function, List params, 
Redirector redirector)
   throws Exception {
   if (!initialized)
   initialize();

   Method method = (Method) methods.get(function);
   Request request = 
ContextHelper.getRequest(this.avalonContext);
   Session session = request.getSession(true);
   HashMap userScopes = (HashMap) 
session.getAttribute(USER_GLOBAL_SCOPE);
   if (userScopes == null)
  userScopes = new HashMap();

   Object flow = (Object) 
userScopes.get(method.getDeclaringClass());

   if (f

Re: Groovy support in Cocoon

[Christopher Oliver]

Stephan Michels wrote:

Am Mo, den 05.04.2004 schrieb Christopher Oliver um 4:42:
 

The current implementation needs some work to qualify as "generalized 
Java continuations". It would be nice to make it work more like Scheme 
continuations:

1) When you access the "current" continuation, it captures the call 
stack up to but not including the current method (and makes a (shallow) 
copy of it). The current method continues as normal. 
   

What to you mean with "continues as normal". The current impl. stops the
execution of the method with null as return value, if the cuntinuation
is suspended. Then the continuation captures the object of the method
call and the current frame.
 

OK, IIUC there are three modes of execution of the instrumented code:

1) isCapturing
During this mode the JVM call stack is unwound and its state captured in 
the continuation call stack.
2) isRestoring
During this mode a saved call stack in a continuation is recreated on 
the JVM stack.
3) !isCapturing && !isRestoring
This is the "normal" execution of the JVM  - no modifications are made 
to the JVM call stack or to the continuation call stack.

This is achieved by inserting code before each invoke instruction to 
copy local variables from the continuation stack to the JVM stack and to 
reset the program counter to the value saved in the continuation stack 
if "isRestoring" is true, and by inserting code after each invoke 
instruction to copy the values of local variables from the JVM call 
stack as well as the program counter into the continuation call stack if 
"isCapturing" is true.

To make continuations more "Scheme-like" it must be possible to 
construct a continuation without modifying the JVM call stack (thus the 
current method invocation can "continue as normal").

To make this possible the byte-code transformer could work like this:

1) Insert code before an invoke instruction to push local vars and the 
pc onto the continuation stack if (!isRestoring && !isCapturing)
2) Insert code after an invoke instruction to pop those values from the 
continuation stack if (!isRestoring && !isCapturing)
3) If (isRestoring == true) the pre-invoke code would work as it does now.
4) If (isCapturing == true) the post-invoke code would simply cause the 
current method invocation to return to its caller without modifying the 
continuation stack - since it is already set up from (1). When the JVM 
stack is completely unwound another continuation will take the place of 
this one and that new continuation would be in "isRestoring" mode until 
it is recreated on the JVM stack at which point it would enter 
(!isRestoring && !isCapturing) mode.

The user interface to this might look something like this:

public class Continuation {
   // Empty continuation for use as an escape procedure
   public static final Continuation SUICIDE;
   // Invoke a captured continuation - it will replace the current 
continuation. I.e. the current JVM call stack will be unwound, the call 
stack saved in this object will be recreated on the JVM call stack, and 
the method invocation in which this object was created will return with 
"returnValue".
   public void invoke(Object returnValue);
   // Get the current continuation -
   public static Continuation getCurrentContinuation();
   // Entry point to the instrumented code (precondition: cannot be 
called recursively and method.getDeclaringClass() must be instrumented)
   public static Object invoke(Object obj, Method method, Object[] 
args);
}

Below is some pseudo-code that shows how this would work with Cocoon:

public class JavaInterpreter {
   // ...
   public void callFunction(String function, List params, 
Redirector redirector)
   throws Exception {
   if (!initialized)
   initialize();

   Method method = (Method) methods.get(function);
   Request request = ContextHelper.getRequest(this.avalonContext);
   Session session = request.getSession(true);
   HashMap userScopes = (HashMap) 
session.getAttribute(USER_GLOBAL_SCOPE);
   if (userScopes == null)
  userScopes = new HashMap();

   Object flow = (Object) 
userScopes.get(method.getDeclaringClass());

   if (flow == null) {
   if (getLogger().isDebugEnabled())
  getLogger().debug("create new instance of 
\""+method.getDeclaringClass()+"\"");

   flow =  method.getDeclaringClass().newInstance();
   userScopes.put(method.getDeclaringClass(), flow);
   int size = params == null ? 0 : params.size();
   Object[] args = new Object[size];
   for (int i = 0; i < size; i++) {
   Interpreter.Argument arg = 
(Interpreter.Argument)params.get(i);
   args[i] = arg.value;
   }
   Continuation.invoke(flow, method, args);
   }

   public void handleContinuation(String id, List params, 
Redirector redirector)
  

RE: [Proposal] Web based GUI development environment for Cocoon

[Hunsberger, Peter]

Bertrand Delacretaz <[EMAIL PROTECTED]> writes:
> 
> Le 5 avr. 04, à 18:09, Hunsberger, Peter a écrit :
> > ...Anyone know if Flex is even something we could
> > really generate (legally) from Cocoon?
> 
> This document 
> http://www.macromedia.com/devnet/flex/articles> /paradigm.html
> 
> says "The first time a user requests 
> HelloWorld.mxml, the server 
> compiles the MXML code into Flash bytecode (a SWF file)
> 
> So IIUC, the Flex XML is not sent to the client but rather used by a 
> (proprietary) server to build an SWF file.

Ok, I remember reading about that now.

> If this is right, and unless there's an open Flex-to-SWF conversion 
> tool, or Flash clients support Flex, we should rather generate SWF 
> directly, either improving the existing Spark-based stuff or using 
> JGenerator (http://www.flashgap.com/, apparently distributed under an 
> Apache style license).

I guess, but since the Flex spec is in XML we know we can do that. Having our own Flex 
to SWF serializer shouldn't be out of the realm of possibility, but may not be legal?  
(Anyone for a Flex to XUL transformer %-?)  Actually, if we're just wanting to "skin" 
cforms, then there is no need for the Flex XML...

However, either, way if you want to support the latest Flash features you still need 
the "compressed" version of the SWF data stream and I don't know if we can "serialize" 
that practically or legally either?

Re: [Proposal] Web based GUI development environment for Cocoon

[Bertrand Delacretaz]

Le 5 avr. 04, à 18:09, Hunsberger, Peter a écrit :
...Anyone know if Flex is even something we could
really generate (legally) from Cocoon?
This document
http://www.macromedia.com/devnet/flex/articles/paradigm.html
says "The first time a user requests HelloWorld.mxml, the server 
compiles the MXML code into Flash bytecode (a SWF file)

So IIUC, the Flex XML is not sent to the client but rather used by a 
(proprietary) server to build an SWF file.

If this is right, and unless there's an open Flex-to-SWF conversion 
tool, or Flash clients support Flex, we should rather generate SWF 
directly, either improving the existing Spark-based stuff or using 
JGenerator (http://www.flashgap.com/, apparently distributed under an 
Apache style license).

-Bertrand

RE: [Proposal] Web based GUI development environment for Cocoon

[Hunsberger, Peter]

Sylvain Wallez <[EMAIL PROTECTED]> writes:
> 
> Hunsberger, Peter wrote:
> 
> 
> 
> >Having said that, one of the things we are doing for our 
> next version 
> >of our internal development GUI is using a Flash front end.  
> I wonder 
> >if this is something that the Cocoon community in general 
> would be able 
> >to use?
> >  
> >
> 
> Yes, definitely yes! See my answer to Luke in the "[RT] - XUL 
> revisited" thread.
> 

Saw that.  Our stuff is our proprietary forms system; what's needed here
is cforms based stuff.  Even if I could get permission to post our stuff
I think it's so far from what the general community needs that our
interface won't help.  

OTOH, having a generalized Flex generator would be compatible with where
we want to go and might be something we can contribute to. Flex, if it's
like the most recent Flash is "compressed", don't know the compression
scheme or if the raw data stream is publicly documented.  This might
take some reverse engineering or at least a bit research; our front guys
haven't yet started to look at Flex, we're currently using the most
recent version of Flash.  Anyone know if Flex is even something we could
really generate (legally) from Cocoon?

Re: [RT] - XUL revisited....

[Torsten Curdt]

Hey, interesting idea!

I recently investigated a bit the SWF Transformer/Serializer we have in 
Cocoon to produce dynamically generated Flash, but unfortunately what is 
provided by Spark isn't really usable as it's mostly composed of 
 tags.

Anyone having a better experience or some ideas on this?

Also a standalone swf file that could be embedded into a html page to
display a form for ppl without the IDE. As we all  know flash is not open
source, but the swf format is. Im not sure if there are licencing issues
with regard to distributing swf file(s) that contains the MM ui 
components.
Would need to read the EULA carefuly. Even if it was a problem I have 
heard
there are a group of developers working on open source ui components.

Anyway just an idea. I have a few more regarding cocoon & flash 
intergration
but they can wait for another day.
 

Why wait? Ideas are always interesting to share, even more if others can 
pick them up and implement them.
It's funny, lately I came across this, too :)

When cleaning up some of the blocks I though
we should also get rid of the spark stuff.
It is no longer maintained. Seems like noone
uses it ...maybe also because there is a
(different) proposed way of using XML with
flash.
So I though it would be good to create
such a "proposed" sample and deprecated
the swf serializer and generator.
How does that sound?

cheers
--
Torsten

Re: [RT] - XUL revisited....

[Gianugo Rabellino]

Sylvain Wallez wrote:

luke hubbard wrote:

Sylvain Wallez wrote:
 

"if we have the control"... Unfortunately, 90% of people out there use
  
IE...

98% of people out there have Flash Player. :)
Flash is installed on most machines, it can load and parse xml, and has a
wide range of ui components. It would be great if we could create a flash
component to render cforms that could be used from within the flash IDE.
 

Hey, interesting idea!

I recently investigated a bit the SWF Transformer/Serializer we have in 
Cocoon to produce dynamically generated Flash, but unfortunately what is 
provided by Spark isn't really usable as it's mostly composed of 
 tags.

Anyone having a better experience or some ideas on this?
What about the next generation of Flash (flex)?

http://www.macromedia.com/devnet/flex/

Might take some time to gather a reasonable user base, but it looks 
quite interesting.

Ciao,

--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Blogging at: http://www.rabellino.it/blog/)

Re: [Proposal] Web based GUI development environment for Cocoon

[Sylvain Wallez]

Hunsberger, Peter wrote:



Having said that, one of the things we are doing for our next version of
our internal development GUI is using a Flash front end.  I wonder if
this is something that the Cocoon community in general would be able to
use?
 

Yes, definitely yes! See my answer to Luke in the "[RT] - XUL 
revisited" thread.

Sylvain

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

Re: [RT] - XUL revisited....

[Sylvain Wallez]

luke hubbard wrote:

Sylvain Wallez wrote:
 

"if we have the control"... Unfortunately, 90% of people out there use
   

IE...

98% of people out there have Flash Player. :)
Flash is installed on most machines, it can load and parse xml, and has a
wide range of ui components. It would be great if we could create a flash
component to render cforms that could be used from within the flash IDE.
 

Hey, interesting idea!

I recently investigated a bit the SWF Transformer/Serializer we have in 
Cocoon to produce dynamically generated Flash, but unfortunately what is 
provided by Spark isn't really usable as it's mostly composed of 
 tags.

Anyone having a better experience or some ideas on this?

Also a standalone swf file that could be embedded into a html page to
display a form for ppl without the IDE. As we all  know flash is not open
source, but the swf format is. Im not sure if there are licencing issues
with regard to distributing swf file(s) that contains the MM ui components.
Would need to read the EULA carefuly. Even if it was a problem I have heard
there are a group of developers working on open source ui components.
Anyway just an idea. I have a few more regarding cocoon & flash intergration
but they can wait for another day.
 

Why wait? Ideas are always interesting to share, even more if others can 
pick them up and implement them.

Sylvain

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

Re: disabling widgets

[Tim Larson]

On Mon, Apr 05, 2004 at 01:28:42PM +0200, Sylvain Wallez wrote:
> So, I propose the following changes to Cocoon forms:
> - add a state to widgets (enabled/disabled/hidden).
> - move to a generator approach.

No official comment on the generator approach since I have not
yet tried it, but it looks pretty good from the descriptions I
have seen.  I was just getting ready to make a proposal about
widget states, so I will just copy it below:

Remember the "direction" attribute in the binding?  I think we
need something like that here, but with a different name that
fits this context.  Here are the options I propose for this attr:

  (Note: Not proposing names, just listing the semantics we need.)

  both
  Send value and receive value from user
  This is the normal case for a widget.
  output
  Send value, but do not receive value from user.
  This disables request parameter processing for the widget
  and all of its child widgets, like what we currently use
  the "output" widget for.  This would add the feature to
  all widgets, so for example you could have a read-only
  table driven by an "output" repeater.
  input
  Send no value, but receive value from user.
  This is for passwords or other sensitive values where we
  do not want to echo the value back into the users's form.
  neither
  Do not send value, and do not receive value from user.
  This is for internal values that we do not want to send
  to the user, not even hidden, but where we still want to
  make use of the other features of widgets, such as event
  handling, validation, binding, etc.

We may also need another separate attribute to handle hiding:

  hidden
  Suppress display of value.
  Hiding is actually orthogonal to the settings above,
  because depending on the use-case we may want to pair
  it with any of "both", "output", or "input" widgets.
  For example, a hidden tab-state would be probably be a
  "both" field, a fixed-size repeater may send the size
  as an "output" field, and a widget recording what
  triggered a submit may be an "input" field.

We need to be able to specify the hidden state and the
selection of {both|output|input|neither} both statically in
the widget definitions and dynamically via flowscript, Java,
binding, and event handling, but not via the view, of course.

--Tim Larson

Re: [PROP] Repository interface

[Guido Casper]

Rolf Kulemann wrote:
Maybe we should simply return false on setVersioned(String, false),
because there are to many cases where we get inconsistent data or have
other problems during moving with coliding file names etc.
Did just that for the time being.

However I think this might be properly implemented by:
-copy to a temporary resource
-check wether the temporary resource is version-controlled
-move the temporary resource back overriding the original resource


We also need to set appropriate locks if supported, imho.
Yes.

Guido

--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn   http://www.s-und-n.de
-

RE: [Proposal] Web based GUI development environment for Cocoon

[Hunsberger, Peter]

roy huang <[EMAIL PROTECTED]> writes:

> 
> Agree!I believe this GUI as an application or an application 
> core is better.It means developers using cocoon can use this 
> core to build their application,like administration panel for 
> form design or management.

Our system uses a Web based GUI for definition of the metadata and
screens, much like part of the proposal.  

There are two major reasons you want use a Web based GUI for something
like Cocoon (and not restrict the development environment to something
like Eclipse):

1) the tools you develop for enabling development of the Cocoon are also
useful for other web applications;

2) it forces the developers to make Cocoon better for the development of
complex applications.  

Having said that, one of the things we are doing for our next version of
our internal development GUI is using a Flash front end.  I wonder if
this is something that the Cocoon community in general would be able to
use?

"stravos" echoing a similar sentiment to Roy

Re: [PROP] Repository interface

[Rolf Kulemann]

On Mon, 2004-04-05 at 16:33, Guido Casper wrote:
> Rolf Kulemann wrote:
> 
> > On Mon, 2004-04-05 at 13:38, Guido Casper wrote:
> > 
> >>Rolf Kulemann wrote:
> >>I just changed the code a little bit. However it's now a little hacky 
> >>and needs completion as after the copy you should check wether the 
> >>destination is version controlled and if that's the case undo the move 
> >>(to keep the old version history) and return false.
> >>
> >>I don't know the details of how to check wether a resource is under 
> >>version control right now (would have to check the DeltaV spec).
> >>
> > 
> > 
> > Maybe we should simply return false on setVersioned(String, false),
> > because there are to many cases where we get inconsistent data or have
> > other problems during moving with coliding file names etc.
> 
> Did just that for the time being.
> 
> However I think this might be properly implemented by:
> -copy to a temporary resource
> -check wether the temporary resource is version-controlled
> -move the temporary resource back overriding the original resource
> 

We also need to set appropriate locks if supported, imho.

-- 
Regards,

Rolf Kulemann

DO NOT REPLY [Bug 28209] New: - BetwixtTransformer does not marshal Collections properly (java.lang.OutOfMemoryError)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28209

BetwixtTransformer does not marshal Collections properly (java.lang.OutOfMemoryError)

   Summary: BetwixtTransformer does not marshal Collections properly
(java.lang.OutOfMemoryError)
   Product: Cocoon 2
   Version: 2.1.4
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: blocks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


in BetwixtTransformer code (around line 256), some steps have been forgotten
when handling Iterator on Collection objects. This results in a
java.lang.OutOfMemoryError. 

//  fix 
if (bean instanceof Collection) {
  Iterator i = ((Collection) bean).iterator();
  while (i.hasNext()) {
Object o = i.next(); // the missing part
if (element == null) {
   beanWriter.write(o); // instead of beanWriter.write(bean)
} else {
   beanWriter.write(element, o);  // idem
}
  }
}

Re: new blocks.properties way more painful to use

[Geoff Howard]

Ugo Cei wrote:

Il giorno 05/apr/04, alle 15:38, Geoff Howard ha scritto:

Is "/" "." that much more harder than "arrow down" "x" ?

The coommand for findiing the next match is "n" not "/".
Actually, it's /-enter (a blank search - it's an old habit) -
they both work.
Geoff

Re: disabling widgets

[Sylvain Wallez]

Vadim Gritsenko wrote:

Sylvain Wallez wrote:

Vadim Gritsenko wrote:

Sylvain Wallez wrote:

Now, as I mentioned already [1], I started using the generator 
approach
to form templates, using the implementation of "wt:" statements using
JXMacro provided by Chris [2]. And this approach is very powerful, 
as it
allows complex conditional form layout without requiring the
introduction of yet-another-control-structure-markup in the "wt:" 
namespace.

Introducing the widget states would allow these conditions to be
computed with the form's own state rather than using some separate 
flow
values.

So, I propose the following changes to Cocoon forms:
- add a state to widgets (enabled/disabled/hidden).
 

Assuming this state will be available during binding, as well as in 
form... +1. But, this will require some kind of "wt:" control markup 
anyway... Given simple example:


There is a need to disable whole table, it's not enough to take out 
widget only.


This is exactly why a generator approach is needed :


Well, of course it will work with generator. But what if generator can 
not be used in this scenario (xslt processing required; use of other 
template engine; something else), what then? Either it should be also 
possible with JXTemplateTransformer, or FormsTransformer to be 
extended, or (ideally) both of those.


The source of your generator can be a "cocoon:". This has the benefit 
(if the "cocoon:" is cacheable) that you don't necessarily have 
recompile the template like what would be needed with a transformer.

Also, what do you think about something to allow generation of 
s? Currently,  does not produce any label at all...


Actually, that's not a generator/transformer problem, but something 
wrong with . It should produce a  tag 
containing what it produces today. This then allows the styling to 
generate the correct  tags.

Sylvain

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

Re: [RT] - XUL revisited....

[luke hubbard]

Sylvain Wallez wrote:
> "if we have the control"... Unfortunately, 90% of people out there use
IE...

98% of people out there have Flash Player. :)
Flash is installed on most machines, it can load and parse xml, and has a
wide range of ui components. It would be great if we could create a flash
component to render cforms that could be used from within the flash IDE.
Also a standalone swf file that could be embedded into a html page to
display a form for ppl without the IDE. As we all  know flash is not open
source, but the swf format is. Im not sure if there are licencing issues
with regard to distributing swf file(s) that contains the MM ui components.
Would need to read the EULA carefuly. Even if it was a problem I have heard
there are a group of developers working on open source ui components.

Anyway just an idea. I have a few more regarding cocoon & flash intergration
but they can wait for another day.
Im not against XUL, think it would be the right choice for some apps.
Would be cool to have multiple cforms styling options.

Regards,
Luke

Re: [PROP] Repository interface

[Guido Casper]

Rolf Kulemann wrote:

On Mon, 2004-04-05 at 13:38, Guido Casper wrote:

Rolf Kulemann wrote:
I just changed the code a little bit. However it's now a little hacky 
and needs completion as after the copy you should check wether the 
destination is version controlled and if that's the case undo the move 
(to keep the old version history) and return false.

I don't know the details of how to check wether a resource is under 
version control right now (would have to check the DeltaV spec).



Maybe we should simply return false on setVersioned(String, false),
because there are to many cases where we get inconsistent data or have
other problems during moving with coliding file names etc.
Did just that for the time being.

However I think this might be properly implemented by:
-copy to a temporary resource
-check wether the temporary resource is version-controlled
-move the temporary resource back overriding the original resource
The open question is what happen to the version history. I tend to 
having a global configuration whether to keep histories of deleted 
resources or remove them (as keeping histories of deleted resources 
might bloat the repository a lot).

Guido

--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn   http://www.s-und-n.de
-

Re: new blocks.properties way more painful to use

[Ugo Cei]

Il giorno 05/apr/04, alle 15:38, Geoff Howard ha scritto:

Is "/" "." that much more harder than "arrow down" "x" ?

The coommand for findiing the next match is "n" not "/".

	Ugo

Re: Cocoon and Hibernate

[Vadim Gritsenko]

Leszek Gawron wrote:

On Mon, Apr 05, 2004 at 03:24:26PM +0200, Reinhard Pötz wrote:
 

Leszek Gawron wrote:

   

I have an application written using cocoon ( flow + jx ) and hibernate. I
could strip it down to a simple example and provide a patch. What form 
should
it take? Another block like OJB? A scratchpad directory ? 

The case is nearly the same as in hibernate  - there can be no sample 
working
out of the box due to the licensing but I think it will be simpler to run
(hibernate is not as sensitive to libraries version and it does not use 
class
enhancment, only reflection) 

If anyone is interested please advise.
lg


 

Sorry, but we can't add Hibernate to our CVS because it licensed under 
LGPL. You could ask at cocoondev.org.
   

I am not talking about adding hibernate. I am proposing to add hibernate
sample same way ojb sample is added - the user has to add some libraries
himself before building.
 

This should be possible as long as samples are coded against some 
standard, non-(L)GPL API (JDO?) and do not use any hibernate classes 
directly. We can not also host mocks of hibrnate classes.

Vadim

Re: new blocks.properties way more painful to use

[Vadim Gritsenko]

Geoff Howard wrote:

Stefano Mazzocchi wrote:

in the past I was used to:

 1) cp blocks.properties local.blocks.properties
 2) vi local.blocks.properties
 3) uncomment the blocks that I wanted to exclude
Today, I have to go thru a bunch of include and change them from true 
to false. Much more hassle than just uncommenting/commenting one line.


?  With the previous uncomment scheme, you probably did arrow down, 
and then the "x" command to delete the # character.  With the new 
scheme for the first line you would do "/true" (find the word true) 
and then "cw" "false" "esc".  From them on you'd do "/" (repeat the 
last find) until you found a line you want to change then "." (repeat 
the last edit).

Is "/" "." that much more harder than "arrow down" "x" ?


I guess it depends on your "vi" skills ;-)

Ok, but it should be fairly easy to make "include" properties default to 
"true" if nothing else is defined - then it (almost) solves an issue: 
block.properties can contain comments only, and explain format. And 
local.block.properties can define properties in any syntax - include or 
exclude.

Vadim

Re: disabling widgets

[Vadim Gritsenko]

Sylvain Wallez wrote:

Vadim Gritsenko wrote:

Sylvain Wallez wrote:

Now, as I mentioned already [1], I started using the generator approach
to form templates, using the implementation of "wt:" statements using
JXMacro provided by Chris [2]. And this approach is very powerful, 
as it
allows complex conditional form layout without requiring the
introduction of yet-another-control-structure-markup in the "wt:" 
namespace.

Introducing the widget states would allow these conditions to be
computed with the form's own state rather than using some separate flow
values.
So, I propose the following changes to Cocoon forms:
- add a state to widgets (enabled/disabled/hidden).
 

Assuming this state will be available during binding, as well as in 
form... +1. But, this will require some kind of "wt:" control markup 
anyway... Given simple example:


There is a need to disable whole table, it's not enough to take out 
widget only.


This is exactly why a generator approach is needed :


Well, of course it will work with generator. But what if generator can 
not be used in this scenario (xslt processing required; use of other 
template engine; something else), what then? Either it should be also 
possible with JXTemplateTransformer, or FormsTransformer to be extended, 
or (ideally) both of those.

Also, what do you think about something to allow generation of s? 
Currently,  does not produce any label at all...

Vadim

Re: disabling widgets

[Upayavira]

Antonio Gallardo wrote:

Upayavira dijo:
 

Leon Widdershoven wrote:

   

- move to a generator approach.
   

Do you mean generator-only approach? I think that would limit the
options of the users quite a bit (and I am one of those). I actually
like the pipeline
approach so that you can build your XML tree dynamically; if one would
move
to a generator only approach other generator-only functionalities
(xsp, though
that appears to be deprecated) can not really be used anymore.
As you notice I am not well enough at home in cocoon core matters to
really have an opinion, but two months ago when I started using cocoon
(and I am working full time with cocoon-2.1.4) the fact that the xsp
was a generator only brought me a lot of trouble so I have a bit of a
phobia about that.
 

Sylvain is not proposing to scrap pipelining, just to merge a couple of
stages. At present, in CForms, you can have:
JXTemplateGenerator->FormTransformer->XSLT->Serialise

What is being proposed is to use JXMacros in JXTemplateGenerator to
implement the functionality of the FormTransformer, so you get:
JXTemplateGenerator->XSLT->Serialise

So, hopefully this scares you less. The template that is being worked
with is very much an XML one - XML to HTML transformation remains
steadfastly with XSLT.
   

Will be also able to use the JXTemplateGenerator without CForms?
 

I think it is more a question of whether you will be able to use 
JXTemplateGenerator without flow. They are (or were) quite tied to each 
other.

But there is no specific connection between CForms and the 
JXTemplateGenerator.

Upayavira

Re: cvs commit: cocoon-2.1/src/blocks/web3/samples samples.xml

[Bruno Dumon]

On Mon, 2004-04-05 at 15:57, Antonio Gallardo wrote:
> Bruno Dumon dijo:
> > On Mon, 2004-04-05 at 14:25, [EMAIL PROTECTED] wrote:
> >> antonio 2004/04/05 05:25:36
> > 
> >>   removing encoding="ISO-8859-1"
> > 
> >
> > Did you also convert those files from ISO-8859-1 to UTF-8?
> 
> Are you having troubles in a particular file?
> 

No, I was just wondering.

Looking around... e.g. FormsMessages_fr.xml seems to be ISO-8859-1
encoded. The safest thing to me seems to run a program over all these
files to recode them.

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

RE: [Kernel22] How to develop a component?

[Carsten Ziegeler]

Gianugo Rabellino wrote:
> 
> Carsten Ziegeler wrote:
> > I'm trying to figure out what the current kernel already 
> provides and 
> > what not.
> > 
> > Let's forget all the xml (descriptors etc) for a moment. Imagine I 
> > want to write a block, that provides - let's say a special file 
> > generator - that can be used in other blocks (in my app block).
> > 
> > Now, obviously this generator will implement our Cocoon 
> Generator interface.
> > What else does the kernel already provide for the component 
> lifecycle?
> > (Logging, Configuration etc.)
> > 
> > Or is this a to discuss/do?
> 
> JFYI, Pier is in vacation ATM, so you're better not hold your 
> breath... :-)
> 
Ah, thanks! I thought there are perhaps more people out there (Stefano?)
that know the answer.

Carsten

[cforms] binding sample

[Klaus Bertram]

Hi all,
i had written at the weekend a small solution for new id's by xml 
binding at my test binding. I can also append it for the sample xml binding.
It's based on jxpath
2 solutions:
 1. iterate all id's to get the highest
 2. append attribute to  with lastID="2"
I prefer 2
Are there any interest?

Klaus

Re: [Kernel22] How to develop a component?

[Gianugo Rabellino]

Carsten Ziegeler wrote:
I'm trying to figure out what the current kernel already provides 
and what not. 

Let's forget all the xml (descriptors etc) for a moment. Imagine I 
want to write a block, that provides - let's say a special file 
generator - that can be used in other blocks (in my app block).

Now, obviously this generator will implement our Cocoon Generator interface.
What else does the kernel already provide for the component lifecycle?
(Logging, Configuration etc.) 

Or is this a to discuss/do?
JFYI, Pier is in vacation ATM, so you're better not hold your breath... :-)

Ciao,

--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Blogging at: http://www.rabellino.it/blog/)

Re: disabling widgets

[Antonio Gallardo]

Upayavira dijo:
> Leon Widdershoven wrote:
>
>>
>>> - move to a generator approach.
>>
>>
>> Do you mean generator-only approach? I think that would limit the
>> options of the users quite a bit (and I am one of those). I actually
>> like the pipeline
>> approach so that you can build your XML tree dynamically; if one would
>> move
>> to a generator only approach other generator-only functionalities
>> (xsp, though
>> that appears to be deprecated) can not really be used anymore.
>>
>> As you notice I am not well enough at home in cocoon core matters to
>> really have an opinion, but two months ago when I started using cocoon
>> (and I am working full time with cocoon-2.1.4) the fact that the xsp
>> was a generator only brought me a lot of trouble so I have a bit of a
>> phobia about that.
>
> Sylvain is not proposing to scrap pipelining, just to merge a couple of
> stages. At present, in CForms, you can have:
>
> JXTemplateGenerator->FormTransformer->XSLT->Serialise
>
> What is being proposed is to use JXMacros in JXTemplateGenerator to
> implement the functionality of the FormTransformer, so you get:
>
> JXTemplateGenerator->XSLT->Serialise
>
> So, hopefully this scares you less. The template that is being worked
> with is very much an XML one - XML to HTML transformation remains
> steadfastly with XSLT.

Will be also able to use the JXTemplateGenerator without CForms?

Best Regards,

Antonio Gallardo

Re: cvs commit: cocoon-2.1/src/blocks/web3/samples samples.xml

[Antonio Gallardo]

Bruno Dumon dijo:
> On Mon, 2004-04-05 at 14:25, [EMAIL PROTECTED] wrote:
>> antonio 2004/04/05 05:25:36
> 
>>   removing encoding="ISO-8859-1"
> 
>
> Did you also convert those files from ISO-8859-1 to UTF-8?

Are you having troubles in a particular file?

Best Regards,

Antonio Gallardo

Re: cvs commit: cocoon-2.1/src/blocks/web3/samples samples.xml

[Bruno Dumon]

On Mon, 2004-04-05 at 14:25, [EMAIL PROTECTED] wrote:
> antonio 2004/04/05 05:25:36

>   removing encoding="ISO-8859-1"


Did you also convert those files from ISO-8859-1 to UTF-8?

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [RT] - XUL revisited....

[Sylvain Wallez]

Antonio Gallardo wrote:

Hi:

I was revisiting the XUL website and found something great:

http://mab.mozdev.org/

I am seriously thinking in XUL as the final code from forms block. I know XUL only works in Mozilla, but if we have the control of all the users machines, XUL can be the best choice. Think in a rich client without the fat of Java Applets. ;-)
 

"if we have the control"... Unfortunately, 90% of people out there use IE...

But a featureful XUL implementation of the CForms styling would 
certainly help to convince people trashing IE and going for Mozilla!

So +1 for a XUL styling.

Sylvain

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

Re: disabling widgets

[Sylvain Wallez]

Upayavira wrote:

Leon Widdershoven wrote:


- move to a generator approach.


Do you mean generator-only approach? I think that would limit the 
options of the users quite a bit (and I am one of those). I actually 
like the pipeline
approach so that you can build your XML tree dynamically; if one 
would move
to a generator only approach other generator-only functionalities 
(xsp, though
that appears to be deprecated) can not really be used anymore.

As you notice I am not well enough at home in cocoon core matters to 
really have an opinion, but two months ago when I started using 
cocoon (and I am working full time with cocoon-2.1.4) the fact that 
the xsp was a generator only brought me a lot of trouble so I have a 
bit of a phobia about that.


Sylvain is not proposing to scrap pipelining, just to merge a couple 
of stages. At present, in CForms, you can have:

JXTemplateGenerator->FormTransformer->XSLT->Serialise

What is being proposed is to use JXMacros in JXTemplateGenerator to 
implement the functionality of the FormTransformer, so you get:

JXTemplateGenerator->XSLT->Serialise

So, hopefully this scares you less. The template that is being worked 
with is very much an XML one - XML to HTML transformation remains 
steadfastly with XSLT.


Exactly. This idea came from the fact that the form state participates 
in defining the page layout through widget states (in the global 
meaning, e.g. when a repeater is empty).

And if this isn't taken into account at the generator level (a dynamic 
one, like JXTemplate), this leads to defining control structure 
statements in the markup handled by a transformer. And this leads to 
defining a myriad of similar-yet-different markups all over the place, 
for a result that cannot achieve the expressional power of a single 
dynamic generator (be it JXTemplate or XSP).

In short, transformers should not be used to define the document 
_structure_.

And believe me, I love pipelines ;-)

Sylvain

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

Re: Cocoon and Hibernate

[Leszek Gawron]

On Mon, Apr 05, 2004 at 03:24:26PM +0200, Reinhard Pötz wrote:
> Leszek Gawron wrote:
> 
> >I have an application written using cocoon ( flow + jx ) and hibernate. I
> >could strip it down to a simple example and provide a patch. What form 
> >should
> >it take? Another block like OJB? A scratchpad directory ? 
> >
> >The case is nearly the same as in hibernate  - there can be no sample 
> >working
> >out of the box due to the licensing but I think it will be simpler to run
> >(hibernate is not as sensitive to libraries version and it does not use 
> >class
> >enhancment, only reflection) 
> >
> >If anyone is interested please advise.
> > lg
> >
> > 
> >
> Sorry, but we can't add Hibernate to our CVS because it licensed under 
> LGPL. You could ask at cocoondev.org.
I am not talking about adding hibernate. I am proposing to add hibernate
sample same way ojb sample is added - the user has to add some libraries
himself before building.
lg
-- 
__
 | /  \ |Leszek Gawron//  \\
\_\\  //_/   [EMAIL PROTECTED]   _\\()//_
 .'/()\'. Phone: +48(501)720812 / //  \\ \
  \\  //  recursive: adj; see recursive  | \__/ |

Re: disabling widgets

[Sylvain Wallez]

Vadim Gritsenko wrote:

Sylvain Wallez wrote:

Now, as I mentioned already [1], I started using the generator approach
to form templates, using the implementation of "wt:" statements using
JXMacro provided by Chris [2]. And this approach is very powerful, as it
allows complex conditional form layout without requiring the
introduction of yet-another-control-structure-markup in the "wt:" 
namespace.

Introducing the widget states would allow these conditions to be
computed with the form's own state rather than using some separate flow
values.
So, I propose the following changes to Cocoon forms:
- add a state to widgets (enabled/disabled/hidden).
 

Assuming this state will be available during binding, as well as in 
form... +1. But, this will require some kind of "wt:" control markup 
anyway... Given simple example:


There is a need to disable whole table, it's not enough to take out 
widget only.


This is exactly why a generator approach is needed :


 
   
 
   
   
  
   
 
 
   This data is currently not available.
 

Sylvain

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

Re: disabling widgets

[Upayavira]

Leon Widdershoven wrote:


- move to a generator approach.


Do you mean generator-only approach? I think that would limit the 
options of the users quite a bit (and I am one of those). I actually 
like the pipeline
approach so that you can build your XML tree dynamically; if one would 
move
to a generator only approach other generator-only functionalities 
(xsp, though
that appears to be deprecated) can not really be used anymore.

As you notice I am not well enough at home in cocoon core matters to 
really have an opinion, but two months ago when I started using cocoon 
(and I am working full time with cocoon-2.1.4) the fact that the xsp 
was a generator only brought me a lot of trouble so I have a bit of a 
phobia about that.
Sylvain is not proposing to scrap pipelining, just to merge a couple of 
stages. At present, in CForms, you can have:

JXTemplateGenerator->FormTransformer->XSLT->Serialise

What is being proposed is to use JXMacros in JXTemplateGenerator to 
implement the functionality of the FormTransformer, so you get:

JXTemplateGenerator->XSLT->Serialise

So, hopefully this scares you less. The template that is being worked 
with is very much an XML one - XML to HTML transformation remains 
steadfastly with XSLT.

Hope that helps.

Upayavira

Re: Cocoon and Hibernate

[Antonio Gallardo]

Brian McCallister dijo:
> fwiw: OJB can be done completely legally, the OJB block just happens to
> really be a JDO via OJB block, which requires the JDORI jars.

The OJB block also work with PB.

Best Regards,

Antonio Gallardo

Re: new blocks.properties way more painful to use

[Geoff Howard]

Stefano Mazzocchi wrote:

in the past I was used to:

 1) cp blocks.properties local.blocks.properties
 2) vi local.blocks.properties
 3) uncomment the blocks that I wanted to exclude
Today, I have to go thru a bunch of include and change them from true to 
false. Much more hassle than just uncommenting/commenting one line.
?  With the previous uncomment scheme, you probably did arrow down, and then the 
"x" command to delete the # character.  With the new scheme for the first line 
you would do "/true" (find the word true) and then "cw" "false" "esc".  From 
them on you'd do "/" (repeat the last find) until you found a line you want to 
change then "." (repeat the last edit).

Is "/" "." that much more harder than "arrow down" "x" ?

Geoff

[RT] - XUL revisited....

[Antonio Gallardo]

Hi:

I was revisiting the XUL website and found something great:

http://mab.mozdev.org/

I am seriously thinking in XUL as the final code from forms block. I know
XUL only works in Mozilla, but if we have the control of all the users
machines, XUL can be the best choice. Think in a rich client without the
fat of Java Applets. ;-)

WDYT?

Best Regards,

Antonio Gallardo.

Re: disabling widgets

[Leon Widdershoven]

- move to a generator approach.
Do you mean generator-only approach? I think that would limit the options of 
the users quite a bit (and I am one of those). I actually like the pipeline
approach so that you can build your XML tree dynamically; if one would move
to a generator only approach other generator-only functionalities (xsp, though
that appears to be deprecated) can not really be used anymore.

As you notice I am not well enough at home in cocoon core matters to really 
have an opinion, but two months ago when I started using cocoon (and I am 
working full time with cocoon-2.1.4) the fact that the xsp was a generator 
only brought me a lot of trouble so I have a bit of a phobia about that.

Regards,
Leon Widdershoven

[Kernel22] How to develop a component?

[Carsten Ziegeler]

I'm trying to figure out what the current kernel already provides 
and what not. 

Let's forget all the xml (descriptors etc) for a moment. Imagine I 
want to write a block, that provides - let's say a special file 
generator - that can be used in other blocks (in my app block).

Now, obviously this generator will implement our Cocoon Generator interface.
What else does the kernel already provide for the component lifecycle?
(Logging, Configuration etc.) 

Or is this a to discuss/do?

Carsten 

Re: Cocoon and Hibernate

[Reinhard Pötz]

Leszek Gawron wrote:

I have an application written using cocoon ( flow + jx ) and hibernate. I
could strip it down to a simple example and provide a patch. What form should
it take? Another block like OJB? A scratchpad directory ? 

The case is nearly the same as in hibernate  - there can be no sample working
out of the box due to the licensing but I think it will be simpler to run
(hibernate is not as sensitive to libraries version and it does not use class
enhancment, only reflection) 

If anyone is interested please advise.
lg
 

Sorry, but we can't add Hibernate to our CVS because it licensed under 
LGPL. You could ask at cocoondev.org.

--
Reinhard

Re: Cocoon and Hibernate

[Brian McCallister]

fwiw: OJB can be done completely legally, the OJB block just happens to 
really be a JDO via OJB block, which requires the JDORI jars. I am 
working on fixing that (the need for the JDORI jars, not the JDO -- JDO 
isn't too bad in and of itself ;-)

-Brian

On Apr 5, 2004, at 9:04 AM, Leszek Gawron wrote:

I have an application written using cocoon ( flow + jx ) and 
hibernate. I
could strip it down to a simple example and provide a patch. What form 
should
it take? Another block like OJB? A scratchpad directory ?

The case is nearly the same as in hibernate  - there can be no sample 
working
out of the box due to the licensing but I think it will be simpler to 
run
(hibernate is not as sensitive to libraries version and it does not 
use class
enhancment, only reflection)

If anyone is interested please advise.
lg
--
__
 | /  \ |Leszek Gawron//  \\
\_\\  //_/   [EMAIL PROTECTED]   _\\()//_
 .'/()\'. Phone: +48(501)720812 / //  \\ \
  \\  //  recursive: adj; see recursive  | \__/ |

Re: Cocoon and Hibernate

[Leszek Gawron]

On Mon, Apr 05, 2004 at 03:04:43PM +0200, Leszek Gawron wrote:
> I have an application written using cocoon ( flow + jx ) and hibernate. I
> could strip it down to a simple example and provide a patch. What form should
> it take? Another block like OJB? A scratchpad directory ? 
> 
> The case is nearly the same as in hibernate  - there can be no sample working
Of course I meant OJB, sorry for that

lg
-- 
__
 | /  \ |Leszek Gawron//  \\
\_\\  //_/   [EMAIL PROTECTED]   _\\()//_
 .'/()\'. Phone: +48(501)720812 / //  \\ \
  \\  //  recursive: adj; see recursive  | \__/ |

Cocoon and Hibernate

[Leszek Gawron]

I have an application written using cocoon ( flow + jx ) and hibernate. I
could strip it down to a simple example and provide a patch. What form should
it take? Another block like OJB? A scratchpad directory ? 

The case is nearly the same as in hibernate  - there can be no sample working
out of the box due to the licensing but I think it will be simpler to run
(hibernate is not as sensitive to libraries version and it does not use class
enhancment, only reflection) 

If anyone is interested please advise.
lg

-- 
__
 | /  \ |Leszek Gawron//  \\
\_\\  //_/   [EMAIL PROTECTED]   _\\()//_
 .'/()\'. Phone: +48(501)720812 / //  \\ \
  \\  //  recursive: adj; see recursive  | \__/ |

database block depends on xsp

[Leszek Gawron]

I cannot compile databases block if I exclude xsp block from build. It is not
reflected in blocks.properties.

here's a stacktrace:

C:\dev\apache-projects\cocoon-2.1\src\blocks\databases\java\org\apache\cocoon\acting\DatabaseCookieAuthenticatorAction.j
ava:23: cannot resolve symbol
symbol  : class XSPCookieHelper
location: package xsp
import org.apache.cocoon.components.language.markup.xsp.XSPCookieHelper;
^
C:\dev\apache-projects\cocoon-2.1\src\blocks\databases\java\org\apache\cocoon\acting\DatabaseCookieAuthenticatorAction.j
ava:268: cannot resolve symbol
symbol  : variable XSPCookieHelper
location: class org.apache.cocoon.acting.DatabaseCookieAuthenticatorAction
cookie_value = XSPCookieHelper.getCookie(objectModel,
cookie_name, -1).getValue();
   ^
2 errors
BUILD FAILED
C:\dev\apache-projects\cocoon-2.1\tools\targets\compile-build.xml:172:
Following error occured while executing this line

C:\dev\apache-projects\cocoon-2.1\build\cocoon-2.1.5-dev\temp\blocks-build.xml:2553:
Compile failed; see the compiler er
ror output for details.
Total time: 1 minute 2 seconds
Result: 1

-- 
__
 | /  \ |Leszek Gawron//  \\
\_\\  //_/   [EMAIL PROTECTED]   _\\()//_
 .'/()\'. Phone: +48(501)720812 / //  \\ \
  \\  //  recursive: adj; see recursive  | \__/ |

Re: Still we need Apples?

[Brian McCallister]

I think Apples attempts to model flow as an explicit FSM. May still be 
appropriate.

-Brian

On Apr 5, 2004, at 8:09 AM, Antonio Gallardo wrote:

Hi:

Don't know much about the Apples block. AFAIK, this was an intent to
implement a Flow engine using Java. If this is right, I am requesting 
to
delete it.

WDYT?

Best Regards,

Antonio Gallardo

Re: [Proposal] Web based GUI development environment for Cocoon

[Vadim Gritsenko]

Corin Moss wrote:

Hiya,

This does indeed sound like a very powerful tool.  Can I urge anyone who might be interested in pursuing this to take a look at XUL (part of the Mozilla project.)  XUL would make complex data display infinately easier (built in tree views, RDF driven templting - every rich widget you could imagine.)  I know it's not a technology used within the cocoon core, but it would make a lot of the development a lot less painful.  The sort of information you're going to render needs (IMHO) a fairly rich GUI interface - something which becomes unmanageble very quickly with HTML / Javascript.  XUL provides a toolkit to make such things really easy to develop.

The project I've been heading for the last few months makes extensive use of RDF driven XUL (all coming out of cocoon of course ;)  I'd be happy to evangilise directly if anyone is interested in learning more about XUL + cocoon :)

If you want to evangelize... The best way to evangelize is to show some 
code :-)
Can you implement something on XUL which can be included as part of 
Cocoon examples? Even adding simplest "Hello XUL" to the samples will be 
step forward, and it would be good to see some reach GUI example as well.

Another place where your help would be appreciated is to develop XUL 
view for the CForms.

Vadim

Re: [PROP] Repository interface

[Rolf Kulemann]

On Mon, 2004-04-05 at 13:38, Guido Casper wrote:
> Rolf Kulemann wrote:
> I just changed the code a little bit. However it's now a little hacky 
> and needs completion as after the copy you should check wether the 
> destination is version controlled and if that's the case undo the move 
> (to keep the old version history) and return false.
> 
> I don't know the details of how to check wether a resource is under 
> version control right now (would have to check the DeltaV spec).
> 

Maybe we should simply return false on setVersioned(String, false),
because there are to many cases where we get inconsistent data or have
other problems during moving with coliding file names etc.

Makes sense?

-- 
Regards,

Rolf Kulemann

Re: [DONE] Nested variable resolving

[Vadim Gritsenko]

Upayavira wrote:

We could do with some documentation about this - as there's some 
interesting consequences that should be written about, and 
recommendations/bad practice. Any suggestions where?


There is no documentation for sitemap variables in the main site 
(couldn't find with Google)... Closest one is an FAQ entry:
 http://cocoon.apache.org/2.1/faq/faq-sitemap.html#faq-N100C0

If you can write a sitemap-variables.xml xdoc linked from
 http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html
and mentioned FAQ entry and other places... that would be great :-)
Vadim

Still we need Apples?

[Antonio Gallardo]

Hi:

Don't know much about the Apples block. AFAIK, this was an intent to
implement a Flow engine using Java. If this is right, I am requesting to
delete it.

WDYT?

Best Regards,

Antonio Gallardo

Re: disabling widgets

[Vadim Gritsenko]

Sylvain Wallez wrote:

Now, as I mentioned already [1], I started using the generator approach
to form templates, using the implementation of "wt:" statements using
JXMacro provided by Chris [2]. And this approach is very powerful, as it
allows complex conditional form layout without requiring the
introduction of yet-another-control-structure-markup in the "wt:" namespace.
Introducing the widget states would allow these conditions to be
computed with the form's own state rather than using some separate flow
values.
So, I propose the following changes to Cocoon forms:
- add a state to widgets (enabled/disabled/hidden).
 

Assuming this state will be available during binding, as well as in 
form... +1. But, this will require some kind of "wt:" control markup 
anyway... Given simple example:


There is a need to disable whole table, it's not enough to take out 
widget only.


- move to a generator approach.
 

+1.

Vadim


WDYT?

Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108072698303323&w=2
[2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107332516118153&w=2

Re: disabling widgets

[Sylvain Wallez]

Antonio Gallardo wrote:

Sylvain Wallez dijo:
 

So, I propose the following changes to Cocoon forms:
- add a state to widgets (enabled/disabled/hidden).
   

It maybe good. Can reach the same result using another pipeline to
generate the "form definition" file?
 

Do you mean disabling fields by using dynamically-generated forms? This 
isn't enough, as we need to be able to change the state of widgets 
within the interaction of a user with a form instance, e.g. depending on 
the entered values.

- move to a generator approach.
   

Can we still use JXTemplateGenerator expression inside? AFAIK, this is a very important issue.
 

I'm currently using JX macros which, of course, use JXTemplateGenerator ;-)

Sylvain

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

Re: [PROP] Repository interface

[Guido Casper]

Rolf Kulemann wrote:
[Related to http://issues.apache.org/bugzilla/show_bug.cgi?id=28189]


As for WebDAVRepsoitoryVersioningHelper.setVersioned(): I don't think it
is a good idea to throw an 
UnsupportedOperationException only under certain conditions.


Agreed.

Maybe it makes sense to split setVersioned(String, boolean) into two
methods
1.) setVersioned(String)
2.) unsetVersioned(String)
in order to be more flexible in the implementation decisions?
Why should that be more flexible?

TBH I'm not so sure wether these should be part of the Repository 
interface at all as it looks like being geared towards WebDAV only (but 
I don't know right now).


A setVersioned(uri, false) might be implemented by deleting and  
recreating the 
resource (making copies for safety and checking for auto-versioning).


Ehem, how can I check for auto-versioning?
It's a property of the resource. Wether this property is already set 
upon resource creation usually depends on some server setting.

I just changed the code a little bit. However it's now a little hacky 
and needs completion as after the copy you should check wether the 
destination is version controlled and if that's the case undo the move 
(to keep the old version history) and return false.

I don't know the details of how to check wether a resource is under 
version control right now (would have to check the DeltaV spec).

Guido

--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn   http://www.s-und-n.de
-

Re: disabling widgets

[Antonio Gallardo]

Sylvain Wallez dijo:
> So, I propose the following changes to Cocoon forms:
> - add a state to widgets (enabled/disabled/hidden).

It maybe good. Can reach the same result using another pipeline to
generate the "form definition" file?
> - move to a generator approach.

Can we still use JXTemplateGenerator expression inside? AFAIK, this is a
very important issue.

Best Regards,

Antonio Gallardo

Re: [build system] - Fine grain inclusion of optional libs?

[Vadim Gritsenko]

Joerg Heinicke wrote:

On 05.04.2004 02:41, Antonio Gallardo wrote:

Hi:

Currently, the optional libs always are copied to the resulted build.
Seems like it is the same as puting them in lib/core dir. That 
apporach is
not good at all. I would like to see an extension of the current Cocoon
build system that will check if every optional lib need to be 
included or
not.

WDYT?


Based on what information? At the moment libs are added in dependency 
on selected blocks. The optional libs are in use in different blocks. 
So you either have to double them by putting one jar in block 1 and 
block 2, or only in block 1 and let depend block 2 on block 1 (which 
is completely painful as there is mostly no need for this 
inter-block-dependency), or put each optional jar in its own block and 
let the blocks needing this jar depend on the jar's block. Some 
optional jars are not even tight to any block, e.g. servlet.jar or 
pizza compiler, they are just optional (chosen environment, chosen 
compiler). Furthermore these are only 13 jars. IMO it's not worth any 
of the effort.

BTW, jstyle.jar might be only be of interest for the xsp block, so it 
can possibly be moved to this block.


You can safely drop jstyle.

Vadim

Re: disabling widgets

[Sylvain Wallez]

roy huang wrote:

>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107792005324520&w=2
>In this link,Sylvain suggest 3 states for a widget,I think it's a good idea.
>Today I want to hide an action under some condition ,but I just can't if I don't 
>modify the forms-field-styling.xsl.
>I use a transformer to generate different cocoon form define under different 
>condition,but the widget is always there(type may be different).So in style xml I can 
>always use widget like that:
>
>  
>But if I remove the widget from the form define file,display will generate an error 
>about 'Widget with id "***" does not exist in the form container'.I thought an 
>afternoon and believe I must modify forms-field-styling.xsl to do the job,but I don't 
>like this method.(see 
>also:http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107774469108519&w=2)
>
>Yes,content and display should separate ,but if just the content indicate display it 
>or not?The Cocoon Forms proposal contain  
>(http://wiki.cocoondev.org/Wiki.jsp?page=WoodyScratchpad), I think this proposal is 
>similar to what I am doing now.So if the inline widget doesn't exist and 
>displaytemplate use it ,it will generate the same error.
>
>Solution suggestion:
>1.Do not generate error if a widget not exist ,just not render or ignore it.Of course 
>,this can turn on and off by parameter.
>  
>

I don't like this, as it makes finding typo errors very difficult. The
view must be strict about widget identifiers.

>2.Sylvain's suggest,3 states for a widget.this state is an attribute of a widget 
>define,we can modify it by flow or own transformer.
>  
>

Yes, this state would be an attribute of the widget, that can be
modified by the flow and event handlers, but not by the transformer. The
transformer should be able to react on the widget's state (i.e. ignore
it if it's in hidden state), but, being part of the view, should not
modify the form's state. This is the role of the controller.

Now, as I mentioned already [1], I started using the generator approach
to form templates, using the implementation of "wt:" statements using
JXMacro provided by Chris [2]. And this approach is very powerful, as it
allows complex conditional form layout without requiring the
introduction of yet-another-control-structure-markup in the "wt:" namespace.

Introducing the widget states would allow these conditions to be
computed with the form's own state rather than using some separate flow
values.

So, I propose the following changes to Cocoon forms:
- add a state to widgets (enabled/disabled/hidden).
- move to a generator approach.

WDYT?

Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108072698303323&w=2
[2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107332516118153&w=2

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

Re: Known concurrency issues in 2.1.4/JISP bugs....possible workaround?

[Vadim Gritsenko]

Geoff Howard wrote:

Sylvain Wallez wrote:

Geoff Howard wrote:

Sylvain Wallez wrote:

Geoff Howard wrote:



I don't know for sure but I think it's the order of the index used 
by the JISP impl.


Thanks for this enlightning explanation, but erm... what is the 
"order" of an index???

;-)


http://www.coyotegulch.com/jisp/docs/com/coyotegulch/jisp/BTreeIndex.html#BTreeIndex(java.lang.String,%20int,%20boolean) 


Ah, ok! Thanks!

But, erm... where does this "2701" come from? And yes, I googled for 
"JISP 2701" before asking ;-)


Unfortunately I have no idea where this came from but assume it was 
from some authoritative source to begin with?  I'm surprised google 
didn't find something in the dev list archives about it.


http://cvs.apache.org/viewcvs.cgi/cocoon-2-historical/src/java/org/apache/cocoon/components/store/Attic/jisp.xconf?rev=1.4&hideattic=0&view=markup

It was the value which worked for Cocoon documentation webapp.

Vadim

[PROP] Repository interface

[Rolf Kulemann]

[Related to http://issues.apache.org/bugzilla/show_bug.cgi?id=28189]


As for WebDAVRepsoitoryVersioningHelper.setVersioned(): I don't think it
is a good idea to throw an 
UnsupportedOperationException only under certain conditions.


Agreed.

Maybe it makes sense to split setVersioned(String, boolean) into two
methods

1.) setVersioned(String)
2.) unsetVersioned(String)

in order to be more flexible in the implementation decisions?


A setVersioned(uri, false) might be implemented by deleting and  
recreating the 
resource (making copies for safety and checking for auto-versioning).


Ehem, how can I check for auto-versioning?

-- 
Regards,

Rolf Kulemann

Re: [Proposal] Web based GUI development environment for Cocoon

[roy huang]

Agree!I believe this GUI as an application or an application core is better.It means 
developers using cocoon can use this core to build their application,like 
administration panel for form design or management.

Roy Huang
- Original Message - 
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Jens Maukisch" <[EMAIL PROTECTED]>
Sent: Monday, April 05, 2004 5:59 PM
Subject: Re: [Proposal] Web based GUI development environment for Cocoon


> 
> hi people
> i'm not a developer in cocoon community but i want to say somenthing about 
> this thread. A GUI will be a great step forward in cocoon proj. many 
> people that use cocoon use allready an IDE. so why this GUI will be an 
> stand alone WEB-based or not application and not just a part of an 
> existing IDE. A netbeans module for example?
> 
> 
> --stavros
> 
> 
> 
> 
> On Mon, 5 Apr 2004, Leszek Gawron wrote:
> 
> > On Sat, Apr 03, 2004 at 11:25:33AM +0200, Jens Maukisch wrote:
> > > Hi,
> > > 
> > > > I propose we create a web based GUI development environment for Cocoon
> > > > build using Cocoon technology, such as CForms, flow, portals, etc.
> > > 
> > > [...]
> > > 
> > > > WDYT?
> > > 
> > > Hmm, a webapplication for developing webapplications seems a little
> > > bit strange for me :-)
> > > 
> > > Wouldn't it be better to have a 'real' ide (e.g. based on eclipse).
> > > Maybe the upcoming Eclipse Web Tools Platform Project (with some
> > > nice contributions form IBM:
> > > http://www.cs.huji.ac.il/~dar/wdt/ibm.html) and other available tools
> > > are a good point to start/extend.
> > There is a tool that uses both (commercial). It's called W4Toolkit. Strange
> > really :))
> > 
> > I am also in favour of eclipse as one would have one place to 
> > - code in Java
> > - edit XML files
> > - edit sitemap (sunBow)
> > - build up forms (cocoon GUI)
> > 
> > using a non-web IDE would make the implementation much simpler I think as
> > after the application reaches some point of complexity it is a nightmare to
> > provide a good and flexible GUI.
> > 
> > Remember that developers usually do not use the mouse so often - keyboard is
> > much faster if you know the shortcuts. The standard application can also make
> > use of other features like drag'n'drop or executing external applications.
> > 
> > lg
> > 
> 
> 

Re: disabling widgets

[roy huang]

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107792005324520&w=2
In this link,Sylvain suggest 3 states for a widget,I think it's a good idea.
Today I want to hide an action under some condition ,but I just can't if I don't 
modify the forms-field-styling.xsl.
I use a transformer to generate different cocoon form define under different 
condition,but the widget is always there(type may be different).So in style xml I can 
always use widget like that:

  
But if I remove the widget from the form define file,display will generate an error 
about 'Widget with id "***" does not exist in the form container'.I thought an 
afternoon and believe I must modify forms-field-styling.xsl to do the job,but I don't 
like this method.(see 
also:http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107774469108519&w=2)

Yes,content and display should separate ,but if just the content indicate display it 
or not?The Cocoon Forms proposal contain  
(http://wiki.cocoondev.org/Wiki.jsp?page=WoodyScratchpad), I think this proposal is 
similar to what I am doing now.So if the inline widget doesn't exist and 
displaytemplate use it ,it will generate the same error.

Solution suggestion:
1.Do not generate error if a widget not exist ,just not render or ignore it.Of course 
,this can turn on and off by parameter.
2.Sylvain's suggest,3 states for a widget.this state is an attribute of a widget 
define,we can modify it by flow or own transformer.

WDYT?

Roy Huang

DO NOT REPLY [Bug 28189] - Fix for WebDAVRepository*

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28189

Fix for WebDAVRepository*

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-04-05 10:17 ---
I will complete setVersion(String, false) today.

Re: [Proposal] Web based GUI development environment for Cocoon

[gounis]

hi people
i'm not a developer in cocoon community but i want to say somenthing about 
this thread. A GUI will be a great step forward in cocoon proj. many 
people that use cocoon use allready an IDE. so why this GUI will be an 
stand alone WEB-based or not application and not just a part of an 
existing IDE. A netbeans module for example?


--stavros




On Mon, 5 Apr 2004, Leszek Gawron wrote:

> On Sat, Apr 03, 2004 at 11:25:33AM +0200, Jens Maukisch wrote:
> > Hi,
> > 
> > > I propose we create a web based GUI development environment for Cocoon
> > > build using Cocoon technology, such as CForms, flow, portals, etc.
> > 
> > [...]
> > 
> > > WDYT?
> > 
> > Hmm, a webapplication for developing webapplications seems a little
> > bit strange for me :-)
> > 
> > Wouldn't it be better to have a 'real' ide (e.g. based on eclipse).
> > Maybe the upcoming Eclipse Web Tools Platform Project (with some
> > nice contributions form IBM:
> > http://www.cs.huji.ac.il/~dar/wdt/ibm.html) and other available tools
> > are a good point to start/extend.
> There is a tool that uses both (commercial). It's called W4Toolkit. Strange
> really :))
> 
> I am also in favour of eclipse as one would have one place to 
> - code in Java
> - edit XML files
> - edit sitemap (sunBow)
> - build up forms (cocoon GUI)
> 
> using a non-web IDE would make the implementation much simpler I think as
> after the application reaches some point of complexity it is a nightmare to
> provide a good and flexible GUI.
> 
> Remember that developers usually do not use the mouse so often - keyboard is
> much faster if you know the shortcuts. The standard application can also make
> use of other features like drag'n'drop or executing external applications.
> 
>   lg
> 

Re: Groovy support in Cocoon

[Stephan Michels]

Am Mo, den 05.04.2004 schrieb Christopher Oliver um 4:42:
> The current implementation needs some work to qualify as "generalized 
> Java continuations". It would be nice to make it work more like Scheme 
> continuations:
> 
> 1) When you access the "current" continuation, it captures the call 
> stack up to but not including the current method (and makes a (shallow) 
> copy of it). The current method continues as normal. 

What to you mean with "continues as normal". The current impl. stops the
execution of the method with null as return value, if the cuntinuation
is suspended. Then the continuation captures the object of the method
call and the current frame.

> The reason for 
> making a copy is to prevent further modification of the captured 
> continuation stack as the method call stack unwinds (see below).
> 2) To resume a continuation you invoke it - like a method call through 
> reflection - and you can pass an object to this call (which becomes the 
> return value of the method where the continuation was created).

Yes, but you need all the objects of every stack trace elements to
restore the stack trace. Not only the last one.

> 3) Before the continuation is resumed another copy of the stack is made 
> (the original continuation stack is treated as an immutable object). 
> This makes it possible to invoke the continuation more than once.

Yes.

> It's possible to make the stack copying occur lazily as an optimization 
> (in case another continuation is invoked the method at the top of the 
> stack never returns so copying the remaining frames isn't necessary).

? Sorry, I didn't get it :-/

Can you elaborate this a bit more, how you want to make work like in
Scheme?

Re: CachingURICoplet and cl:links caching too aggressively - possible fix?

[Jon Evans]

Hi,
On 4 Apr 2004, at 18:00, Vadim Gritsenko wrote:
Try this instead. Works for me.

  http://www.mozilla.org/projects/netlib/http/http-caching-faq.html
Confirmed - adding Cache-Control: no-store properly disables the back 
button, in Mozilla at least.

Carsten, please can you add that to NoClientCachingEventAspect?

Cheers,

Jon

Re: cvs commit: cocoon-2.1/src/blocks/forms/samples/flow bindings.js

[Marc Portier]

[EMAIL PROTECTED] wrote:

mpo 2004/04/05 02:38:51

  Modified:src/blocks/forms/samples/flow bindings.js
  Log:
  Code formatting. (tabs to spaces)
  
Anyone out there using a js editor that does it OOTB?

-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: Groovy support in Cocoon

[Stephan Michels]

Am So, den 04.04.2004 schrieb Christopher Oliver um 20:32:
> Stefano Mazzocchi wrote:
> >
> > Next I would like to see is a groovy implementation of flow ;-)
> >
> It should be _fairly_ straightforward. The only tricky part I see is 
> controlling the byte-code transformation. All methods in the call-chain 
> leading from the method invoked by Interpreter.callFunction()  to 
> sendPageAndWait() or any other method that creates a continuation must 
> be instrumented. The current implementation only instruments classes 
> that implement the interface "Continuable". In the case of scripting 
> languages like Groovy, Jython, or Rhino, pretty much the entire 
> interpreter and all classes generated from scripts will need to be 
> instrumented. Any callbacks from non-instrumented code to instrumented 
> code will break the continuation.

Yes, that's correct, the complete stacktrace must be 'instrumented' to
restore the continuation. I thought about it a long time to get
an idea how fix this problem, but I get no idea :-/

BTW, I must add a flag to the Continuation Class, to mark the
continuation as disabled for calling uninstrumented code.

> One approach might be to instrument the build system to rename class 
> files that require instrumentation to have a special extension 
> (".iclass" or whatever) making them invisible to normal class loaders 
> but recognizable to the class loader that performs the byte-code 
> transformation.

Are you talking about instrumenting at compile time?

> Another possible approach is to provide a configuration to the class 
> loader using wildcard specifications (e.g. "groovy.*", etc) to allow it 
> to identify which classes to instrument.

Yes, I think it's a good idea. It's same problem like specifying the
pointcuts in AOP.

Stephan.

Cocoon Stammtisch, Vienna, Austria

[Reinhard Pötz]

Do you like to meet people interested in Cocoon? Do you have the chance 
to come to Vienna on April, 19th or May, 3rd? If you've answered both 
question with "yes" add your name and your preferred date on 
http://wiki.cocoondev.org/Wiki.jsp?page=CocoonUserGroupAustria. The day 
with more votes, to be counted on April 13th, will win.

Last year at our last meeting we had a lot of fun!

If you have questions please make comments at the webpage or contact me 
directly in order to keep the traffic for the Cocoon lists low. Thanks!

--
Reinhard

Re: [Proposal] Web based GUI development environment for Cocoon

[Leszek Gawron]

On Sat, Apr 03, 2004 at 11:25:33AM +0200, Jens Maukisch wrote:
> Hi,
> 
> > I propose we create a web based GUI development environment for Cocoon
> > build using Cocoon technology, such as CForms, flow, portals, etc.
> 
> [...]
> 
> > WDYT?
> 
> Hmm, a webapplication for developing webapplications seems a little
> bit strange for me :-)
> 
> Wouldn't it be better to have a 'real' ide (e.g. based on eclipse).
> Maybe the upcoming Eclipse Web Tools Platform Project (with some
> nice contributions form IBM:
> http://www.cs.huji.ac.il/~dar/wdt/ibm.html) and other available tools
> are a good point to start/extend.
There is a tool that uses both (commercial). It's called W4Toolkit. Strange
really :))

I am also in favour of eclipse as one would have one place to 
- code in Java
- edit XML files
- edit sitemap (sunBow)
- build up forms (cocoon GUI)

using a non-web IDE would make the implementation much simpler I think as
after the application reaches some point of complexity it is a nightmare to
provide a good and flexible GUI.

Remember that developers usually do not use the mouse so often - keyboard is
much faster if you know the shortcuts. The standard application can also make
use of other features like drag'n'drop or executing external applications.

lg
-- 
__
 | /  \ |Leszek Gawron//  \\
\_\\  //_/   [EMAIL PROTECTED]   _\\()//_
 .'/()\'. Phone: +48(501)720812 / //  \\ \
  \\  //  recursive: adj; see recursive  | \__/ |

Re: report message [jdbc/DB2/AIX]

[Leszek Gawron]

On Sun, Apr 04, 2004 at 11:47:40PM +0200, Oliver Raupach wrote:
> Hi !
> 
> I have found this message at sitemap.log (cocoon 2.1.4 / tomcat 4.1.24):
> 
> 
> WARN(2004-04-04) 23:30.03:780   [sitemap.generator.serverpages]
> (/cocoon/mcp/main) Thread-10/AbstractEsqlConnection: Your database
> [db2/6000] is not being recognized yet. Using the generic [jdbc] query as
> default.  Please report this to cocoon-dev or to tcurdt.at.apache.org
> directly.
cocoon cannot recognise the database basing on the db url. you can make it
work right now by executing the query like this:


  jdbc
  select * from table
  

lg
-- 
__
 | /  \ |Leszek Gawron//  \\
\_\\  //_/   [EMAIL PROTECTED]   _\\()//_
 .'/()\'. Phone: +48(501)720812 / //  \\ \
  \\  //  recursive: adj; see recursive  | \__/ |

Cocoon without a web Container

[Marchiori Carlo]

I would like to use Cocoon outside a web
environment. I think most of the Cocoon
heart is indipendent from such an enviroment.

Only, I see the method debug of the org.apache.cocoon.Cocoon
class explicitly uses web session and request objects.
Maybe that should be removed. 

In my opinion protocol should be known only
by the component which sets up the invocation context,
which is outside of Cocoon, and eventually
by generators and serializers which may look up
protocol objects in the object model.

Is there anybody out there  interested in 
using Cocoon out of a web environment?

My target would be to use Cocoon in a general
integration environment.

Thanks,
Carlo.

Portal Engine Links and Google

[Björn Voigt]

Moin Cocooner,

during the past two weeks I experimented a littlebit with
the cocoon portal engine and it looks quiet good, but I think
there is a fundamental problem with the link handling.
The links are dynamicaly generated and I dont believe, that
google can find this pages again. But I think it is importend,
that my page and a special coplet content is found by any
search engines.
And other portals give the possibilty like zdnet, where I can
find articles.
Björn