RE: Bug in forms-lib.js when adding @id to submit buttons?

[Bart Molenkamp]

...

> 
> > It's a problem of HTML, so we should not fix it in CForms IMO.
> > Otherwise it will be a never ending story. It's a 'feature' that
> > should made it into the FAQ.
> 
> 
> Ok for the FAQ, but if several people fall into that trap, we may add
> some checks into the HMTL styling part of CForms for some well-known
> cases like "submit".
> 

Or maybe send messages to some log (e.g. warning?)

Bart.

[GUMP@brutus]: Project cocoon-block-midi (in module cocoon) success

[Gump]

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-midi *no longer* has an issue.
The current state of this project is 'Success'.

Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-midi/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [midi-block.jar] identifier set to project name
 -INFO- No license on redistributable project with outputs.



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-midi/gump_work/build_cocoon_cocoon-block-midi.html
Work Name: build_cocoon_cocoon-block-midi (Type: Build)
Work ended in a state of : Success
Elapsed: 6 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=03112004 -Dblock-name=midi gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-03112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-03112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-03112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-03112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-03112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-03112004.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-03112004/checkstyle-03112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-03112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-03112004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-03112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-03112004.jar:/usr/local/gump/public/workspace/excalibur/components/xmlutil/target/excalibur-xmlutil-03112004.jar:/usr/local/gump/public/workspace/excalibur/components/store/target/excalibur-store-03112004.jar:/usr/local/gump/publi

[GUMP@brutus]: Project cocoon-block-chaperon (in module cocoon) success

[Gump]

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-chaperon *no longer* has an issue.
The current state of this project is 'Success'.

Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-chaperon/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [chaperon-block.jar] identifier set to project name
 -INFO- No license on redistributable project with outputs.



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-chaperon/gump_work/build_cocoon_cocoon-block-chaperon.html
Work Name: build_cocoon_cocoon-block-chaperon (Type: Build)
Work ended in a state of : Success
Elapsed: 10 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=03112004 -Dblock-name=chaperon gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/blocks/chaperon/dest:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/blocks/chaperon/test:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-03112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-03112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-03112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-03112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-03112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-03112004.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-03112004/checkstyle-03112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-03112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-03112004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-03112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-03112004.jar:/usr/local/gump/public

[Closed] Re: ESQL, Oracle CLOB and encoding

[george georgovassilis]

Thanx a lot!
That was exactly the problem. I looked up the esql.xsl and found a bunch 
of goodies in there, including the esql:get-clob tag which does exactly 
what I want. Unfortunately it either didn't make it into the esql user 
documentation (2.1.5.1) or I need a pair of new glasses, anyhow I 
overlooked it.

On a second notice, esql:get-xml seems to build on the get-ascii tag and 
likewise scrambles UTF-8 data.

Best regards
George Georgovassilis
Torsten Curdt wrote:
george georgovassilis wrote:
Good morning Dear All
This is a re-post from the users list where unluckily I didn't find a 
solution to my question.
So, appologies for cross-posting.

I've run into trouble with my ESQL page. In detail:
I'm running an Oracle database pool and a few tables in there with 
CLOBs which contain UTF-8 strings.
The following code extracts the data quite nicely:

oracle.sql.CLOB body =  (oracle.sql.CLOB);
String xmlbody = (body.length()>0? body.getSubString(1, 
(int)body.length()):"");

which returns correctly

ÎÎ ÎÎÏÏÎÏÎ ÎÏÎÏÎ ÏÏÎÎ ÎÎÏÎÎÎÏÎÎ 'ÎÎÎÏÎ / ÎÎ'

The much more elegant
String stripped = ;
however returns garbage:

ÂÎ ÎÂÎÎÂÎÎ Â ÎΠÎÂÎÂÂÎÎâ 'âÂÎΠ/ âÂÂÂÎÂ'

Is there any way I still can use the esql?

Without looking at the code esql:get-ascii implies
ascii encoding ...but you are talking about uft-8
encoding. maybe that's the problem.
Compare the esql:get-object and esql:get-ascii
implementations in the esql.xsl.
cheers
--
Torsten

Re: [lazyweb] SVN checkout without keyword expansion?

[Sylvain Wallez]

Sylvain Wallez wrote:
The nice thing about SVN is that it doesn't consider as having changed 
a file where "$Id: blah blah$" has been changed to "$Id$". Here's the 
script I use (named "rmkw" for "remove keywords")

I was totally wrong with this statement: I checked it using "svn status" 
on a file that was missing the svn:keywords property...

Mmmh... need to find something else... and also write a script that 
automatically adds svn:keywords where it's missing :-)

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

Re: [lazyweb] SVN checkout without keyword expansion?

[Vadim Gritsenko]

Sylvain Wallez wrote:
Hi all,
A lazyweb question about SVN: is there a way to perform a checkout 
without expanding the $Id$ keyword? I couldn't find one by googling 
around, and that would be so useful for merging branches where many 
files only differ by their revision number.

Currently I used a quickly hacked script that does the job, but that 
would be much cleaner to have it handled directly by svn.

Thanks for any hint,
Hint:
  svn diff http://.../cocoon/trunk http://.../cocoon/branches/BRANCH_2_1_X
compares files without expanding any keywords at all.
Vadim

Re: trunk does not compile

[Torsten Curdt]

Maybe you have some local changes in the file?
I did not
Yep, It is really weird, dude! ;-)
Thanks for your help, mate
..but I just deleted the whole
src dir and then did another
 svn up
That solved the problem.
Still weird :-)
cheers
--
Torsten

Re: trunk does not compile

[Antonio Gallardo]

Torsten Curdt dijo:
> Antonio Gallardo wrote:
>> Hi Torsten:
>>
>> Just a thought:
>>
>> Can you check the local.build.properties and the local.block.properties?
>
> sure ...I recreated them from the non-local ones
>
> but the point is: have a look at the source
>
> src/blocks/forms/java/org/apache/cocoon/forms/binding/JXPathBindingManager.java

What version of the file you have? In the file I see:

 * @version CVS $Id: JXPathBindingManager.java 55174 2004-10-20 18:08:26Z
cziegeler $

And inside is the import statement.

running:

svn blame
src/blocks/forms/java/org/apache/cocoon/forms/binding/JXPathBindingManager.java

I see:

28639sylvain import org.apache.cocoon.components.LifecycleHelper;

Perhaps you can run:

svn diff
src/blocks/forms/java/org/apache/cocoon/forms/binding/JXPathBindingManager.java

Maybe you have some local changes in the file?

If you don't did nothing you can undo all local changes running:

svn revert
src/blocks/forms/java/org/apache/cocoon/forms/binding/JXPathBindingManager.java

>
> it's using the LifecycleHelper ...but there is
> no import statement and it's not inside the same
> package. so it should not compile. like it does
> for me. why is it compiling for you?
>
> weird!

Yep, It is really weird, dude! ;-)

Best Regards,

Antonio Gallardo

Re: [RT] Attribute Rendering and CForms Convertors

[Jonas Ekstedt]

On Wed, 2004-11-03 at 21:46 +0100, Daniel Fagerstrom wrote:
> Jonas Ekstedt wrote:
> > 
> > public interface Model {
> >   public String getValue(String path);
> >   public void setValue(String path, String value);
> > }
> > 
> IMO, such an interface is a good starting point, although it needs 
> exceptions for cases when conversion fails. 

True

> In some cases like when you 
> can build lists or trees in the user interface, a more traversal based 
> interface is needed.

I agree that I haven't really thought this issue through thoroughly. In
the widget framework there is a "public int size(String path)" method
that returns the size of whatever object is present at that path. But
there could certainly be more stuff thrown in such as support for
pointers similar to JXPath that can run around in your model data.

> Also, like everyone else that has commented your proposal, I think that 
> it often is a bad idea to write directly to your model. Even if you are 
> able to solve the security problems, the model will still need to be 
> able to store partially invalid input data and missing data. IMO it is 
> better SoC to have a form model in front of the real model. This 
> decreases the complexity of the model as it always can get data in a 
> more transactinal way in complete chunks.

Protecting the application object is partly what the Model interface is
all about. In the getValue/setValue functions you can implement any
measures to protect the application object you'd like. The point is that
the user should decide what type of shielding should be used. 

Eg. the project I'm working on is dependant on letting the view access
derived values from the bean model. That means I need to populate the
beans directly. I do not really care if the beans are inconsistent as I
won't hibernate them if they are (in a sense the database is my
"application object" that I need to shield). So in my case it makes
sense to operate directly on the application object.

However, as a different example, should I start using beans with
properties like ints or Dates then I would choose some other strategy as
I need to be able to save values even when they are not convertible. In
this case the wrapping model could store illegal values in a separate
map. getValue() would then return values from the map if they exist or
from the bean otherwise.

The second approach is similar to how CForm widgets works. What I think
is the benefit of the Model interface is that it is up to the user to
decide what type of shielding should take place.

> I prefer the request processor idea to the current form population where 
> each widget reads it data from the request object. The current scheme 
> makes CForms unecesarily bound to the request parameter model of input 
> data. With a request processor that is reponsible to write input data 
> into the form model, it would be easy to plug in a different request 
> processor if one gets xml input from a browser that implements XForms, e.g.

I think it would be quite easy to make this change to CForm.

Cheers Jonas

Apache account request: Leszek Gawron

[Torsten Curdt]

Dear root,
please create an account for a new cocoon commiter:
Full name:Leszek Gawron
Preferred userid: lgawron
Forwarding email address: lgawron AT mobilebox.pl
Requested karma:  cocoon, lenya, xml-commons, xml-site
Vote: 23 positive and no negative votes
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109897567832744&w=2

Apache account request: Ralph Goers

[Torsten Curdt]

Dear root,
please create an account for a new cocoon commiter:
Full name:Ralph Goers
Preferred userid: rgoers
Forwarding email address: Ralph.Goers AT dslextreme.com
Requested karma:  cocoon, lenya, xml-commons, xml-site
Vote: 23 positive and no negative votes
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109897567832744&w=2

Re: [RT] Attribute Rendering and CForms Convertors

[Daniel Fagerstrom]

Jonas Ekstedt wrote:
On Tue, 2004-11-02 at 19:21 +0100, Daniel Fagerstrom wrote: 
Ok, the idea is as follows: we have a converter component, that is like 
the renderer component above, but bidirectional. I.e. both rendering: 
data type -> displayable string and input conversion: input string -> 
data type. The converter is configured in the same way as described for 
the renderer above.
I've been working along the same line [1] (it's about a widget framework
but contains elements that are relevant to your idea as well). The idea
is that data is wrapped by a model that works directly on my data but
that can perform any conversions, validations etc through its
getValue/setValue functions:
public interface Model {
  public String getValue(String path);
  public void setValue(String path, String value);
}
IMO, such an interface is a good starting point, although it needs
exceptions for cases when conversion fails. In some cases like when you
can build lists or trees in the user interface, a more traversal based
interface is needed.
Also, like everyone else that has commented your proposal, I think that
it often is a bad idea to write directly to your model. Even if you are
able to solve the security problems, the model will still need to be
able to store partially invalid input data and missing data. IMO it is
better SoC to have a form model in front of the real model. This
decreases the complexity of the model as it always can get data in a
more transactinal way in complete chunks.
I prefer the request processor idea to the current form population where
each widget reads it data from the request object. The current scheme
makes CForms unecesarily bound to the request parameter model of input
data. With a request processor that is reponsible to write input data
into the form model, it would be easy to plug in a different request
processor if one gets xml input from a browser that implements XForms, e.g.
For example if my data is a bean containing a Date then a
ConvertingBeanModel wrapping my bean would have a getValue function
performing the Date->String conversion (according to whatever locale is
chosen). And vice versa with setValue. The benefit with having an
abstract view of the model would be that you can implement any type of
conversion in the setValue/getValue functions. You could have a generic
set of conversions for the basic types as well as special conversions
unique to your application. Eg. if your underlying data is a resultset
then you can convert values to SQL types rather than java types. 
If we translate this to the CForms case, generic sets of convertors,
would not only be useful for rendering and handling input to the widget
hierarchy, they would be useful in the binding step also.
/Daniel

Re: [RT] Attribute Rendering and CForms Convertors

[Tim Larson]

On Wed, Nov 03, 2004 at 09:46:27PM +0100, Daniel Fagerstrom wrote:
> I prefer the request processor idea to the current form population where 
> each widget reads it data from the request object. The current scheme 
> makes CForms unecesarily bound to the request parameter model of input 
> data. With a request processor that is reponsible to write input data 
> into the form model, it would be easy to plug in a different request 
> processor if one gets xml input from a browser that implements XForms, e.g.

This change would also be good for xmlhttprequest support.

--Tim Larson

Re: [RT] Attribute Rendering and CForms Convertors

[Daniel Fagerstrom]

Jonas Ekstedt wrote:
On Tue, 2004-11-02 at 19:21 +0100, Daniel Fagerstrom wrote: 
Ok, the idea is as follows: we have a converter component, that is like 
the renderer component above, but bidirectional. I.e. both rendering: 
data type -> displayable string and input conversion: input string -> 
data type. The converter is configured in the same way as described for 
the renderer above.
I've been working along the same line [1] (it's about a widget framework
but contains elements that are relevant to your idea as well). The idea
is that data is wrapped by a model that works directly on my data but
that can perform any conversions, validations etc through its
getValue/setValue functions:
public interface Model {
  public String getValue(String path);
  public void setValue(String path, String value);
}
IMO, such an interface is a good starting point, although it needs 
exceptions for cases when conversion fails. In some cases like when you 
can build lists or trees in the user interface, a more traversal based 
interface is needed.

Also, like everyone else that has commented your proposal, I think that 
it often is a bad idea to write directly to your model. Even if you are 
able to solve the security problems, the model will still need to be 
able to store partially invalid input data and missing data. IMO it is 
better SoC to have a form model in front of the real model. This 
decreases the complexity of the model as it always can get data in a 
more transactinal way in complete chunks.

I prefer the request processor idea to the current form population where 
each widget reads it data from the request object. The current scheme 
makes CForms unecesarily bound to the request parameter model of input 
data. With a request processor that is reponsible to write input data 
into the form model, it would be easy to plug in a different request 
processor if one gets xml input from a browser that implements XForms, e.g.

For example if my data is a bean containing a Date then a
ConvertingBeanModel wrapping my bean would have a getValue function
performing the Date->String conversion (according to whatever locale is
chosen). And vice versa with setValue. The benefit with having an
abstract view of the model would be that you can implement any type of
conversion in the setValue/getValue functions. You could have a generic
set of conversions for the basic types as well as special conversions
unique to your application. Eg. if your underlying data is a resultset
then you can convert values to SQL types rather than java types. 
If we translate this to the CForms case, generic sets of convertors, 
would not only be useful for rendering and handling input to the widget 
hierarchy, they would be useful in the binding step also.

/Daniel

Re: Bug in forms-lib.js when adding @id to submit buttons?

[Joerg Heinicke]

On 03.11.2004 18:49, Sylvain Wallez wrote:
Don't know, as "action" is an attribute.
Though this part is not translated into English yet, the JS api of the 
forms object:
http://en.selfhtml.org/javascript/objekte/forms.htm
The French are somewhat faster:
http://fr.selfhtml.org/javascript/objets/forms.htm

It's a problem of HTML, so we should not fix it in CForms IMO. 
Otherwise it will be a never ending story. It's a 'feature' that 
should made it into the FAQ.
Ok for the FAQ, but if several people fall into that trap, we may add 
some checks into the HMTL styling part of CForms for some well-known 
cases like "submit".
OK.
Joerg

DO NOT REPLY [Bug 27598] - add the possibility to prevent widgets from reading value from request

[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=27598

add the possibility to prevent widgets from reading value from request

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

DO NOT REPLY [Bug 25110] - [Roadmap] CocoonForms - release 1.0

[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=25110

[Roadmap] CocoonForms - release 1.0

This bug depends on bug 27598, which changed state:

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

DO NOT REPLY [Bug 27598] - add the possibility to prevent widgets from reading value from request

[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=27598

add the possibility to prevent widgets from reading value from request

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-11-03 20:41 ---
This possibility has been added with the widget states by Sylvain. A widget can
now be configured to be in 'disabled' state to prevent it from reading request
value.

http://marc.theaimsgroup.com/?t=10993904612&r=1&w=4

Thanks, Sylvain.

[GUMP@brutus]: Project cocoon-block-faces (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-faces has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-faces :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-faces/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [faces-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-faces/gump_work/build_cocoon_cocoon-block-faces.html
Work Name: build_cocoon_cocoon-block-faces (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 sec
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=03112004 -Dblock-name=faces faces-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-03112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-03112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-03112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-03112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-03112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-1.2.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-03112004/checkstyle-03112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-03112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-03112004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-03112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/ava

[GUMP@brutus]: Project cocoon-block-proxy (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-proxy has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-proxy :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-proxy/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [proxy-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-proxy/gump_work/build_cocoon_cocoon-block-proxy.html
Work Name: build_cocoon_cocoon-block-proxy (Type: Build)
Work ended in a state of : Failed
Elapsed: 4 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=03112004 -Dblock-name=proxy gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-03112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-03112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-03112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-03112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-03112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-1.2.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-03112004/checkstyle-03112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-03112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-03112004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-03112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/ava

[GUMP@brutus]: Project cocoon-block-jms (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-jms has an issue affecting its community integration.
This issue affects 3 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-repository :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-jms/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [jms-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-jms/gump_work/build_cocoon_cocoon-block-jms.html
Work Name: build_cocoon_cocoon-block-jms (Type: Build)
Work ended in a state of : Failed
Elapsed: 4 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=03112004 -Dblock-name=jms gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-03112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-03112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-03112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-03112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-03112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-1.2.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-03112004/checkstyle-03112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-03112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-03112004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-03112004.jar:/

[GUMP@brutus]: Project cocoon-block-forms (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-forms has an issue affecting its community integration.
This issue affects 9 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-apples :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-mail :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-scratchpad :  Java XML Framework
- cocoon-block-tour :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-forms/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [forms-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-forms/gump_work/build_cocoon_cocoon-block-forms.html
Work Name: build_cocoon_cocoon-block-forms (Type: Build)
Work ended in a state of : Failed
Elapsed: 11 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=03112004 -Dblock-name=forms gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/blocks/forms/test:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-03112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-03112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-03112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-03112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-03112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-1.2.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-03112004/checkstyle-03112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-03112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-03112004.jar:/usr/local/gump/publ

[GUMP@brutus]: Project cocoon-block-woody (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-woody has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-woody :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-woody/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [woody-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-woody/gump_work/build_cocoon_cocoon-block-woody.html
Work Name: build_cocoon_cocoon-block-woody (Type: Build)
Work ended in a state of : Failed
Elapsed: 10 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=03112004 -Dblock-name=woody gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/blocks/woody/test:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-03112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-03112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-03112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-03112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-03112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-1.2.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-03112004/checkstyle-03112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-03112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-03112004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-03112004.jar:/usr/loc

[GUMP@brutus]: Project cocoon-block-midi (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-midi has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-midi :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-midi/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [midi-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-midi/gump_work/build_cocoon_cocoon-block-midi.html
Work Name: build_cocoon_cocoon-block-midi (Type: Build)
Work ended in a state of : Failed
Elapsed: 5 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=03112004 -Dblock-name=midi gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-03112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-03112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-03112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-03112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-03112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-1.2.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-03112004/checkstyle-03112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-03112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-03112004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-03112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logk

[GUMP@brutus]: Project cocoon-block-chaperon (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-chaperon has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-chaperon :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-chaperon/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [chaperon-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-chaperon/gump_work/build_cocoon_cocoon-block-chaperon.html
Work Name: build_cocoon_cocoon-block-chaperon (Type: Build)
Work ended in a state of : Failed
Elapsed: 5 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=03112004 -Dblock-name=chaperon gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/blocks/chaperon/dest:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/blocks/chaperon/test:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-03112004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-03112004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-03112004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-03112004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-03112004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-03112004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-1.2.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-03112004/checkstyle-03112004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-03112004.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-03112004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-03112004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/works

Re: [rant] please backport bugfixes to 2.1!

[Tim Larson]

On Wed, Nov 03, 2004 at 07:05:49PM +0100, Sylvain Wallez wrote:
> Tim Larson wrote:
> >On Wed, Nov 03, 2004 at 06:29:46PM +0100, Sylvain Wallez wrote:
> >>Tim Larson wrote:
> >>>On Tue, Nov 02, 2004 at 11:29:28AM +0100, Sylvain Wallez wrote:
> >>I had a bug while writing widget states because Repeater.RepeaterRow was 
> >>redefining getParent() while I was using this.parent. So I made it final 
> >>in order to be able to use this.parent throughout AbstractWidget.
> >
> >Ok, but I predict Marc will be unhappy ;)
> 
> Why? Does he have special widgets that redefine getParent(). If that's 
> the case, we can remove the "final" and replace "this.parent" by 
> "getParent()".

Just the general rule of preventing the possibility of
making changes to things that should not be changed, such
as a RepeaterRow's parent, but maybe someone will find
a usecase to justify it :)

> Ok. Something that's seem more and more necessary to me is an "output" 
> state that would sit between "disabled" and "invisible", in order to 
> render widgets as text and not as disabled inputs without having to use 
> styling type="output".

Yes, lets start by adding that, and see where that gets us.

> You already told us about this idea, and it seems to me much more 
> general than CForms. However, I also understand that you may want to use 
> CForms as a playground for this experiment. But doing it in the main dev 
> line when we are trying to achieve stable state for CForms is IMO dangerous.
> 
> So whiteboard/scratchpad seems a good idea. Remember: flowscript started 
> there ;-)

I have no problem with this, as long as it is ok with others
for me to clone cforms in the whiteboard for this purpose.

--Tim Larson

Re: CForms work to do before marking it stable

[Sylvain Wallez]

Reinhard Poetz wrote:
Sylvain Wallez wrote:
Hi all,
Here's the result of the discussion at the GT about the work needed 
for CForms to reach stable state. Thanks to Pier for being the 
secretary. He did it so well ;-P

Flowscript integration:
- don't use JS wrapping classes for widgets: they introduce 
yet-another-API which is sometimes confusing.
- update the widgets' java public API so that it's more 
"Rhino-friendly" (check JavaBean conformance and add accessors where 
needed)
- implement an equivalent to the bookmark feature of V2, by a 
function property of the form that gets called at each request roundtrip
- add helper methods to the Form class to create event listeners from 
JS functions
- restrict the "cocoon" object that's available in the event handlers 
so that it does not provide response-related methods (sendPage etc)

Java code:
- ignore the "action-command" attribute which is currently useless 
except for repeater-actions and row-actions
- implement widget states (a patch has been provided for this which I 
will take care of)

Misc:
- write a form definition schema so that definitions can be 
optionally validated.
- flatten the CForm-related component in cocoon.xconf. This will ease 
the transition to a non-Avalon container

There was also a discussion also after my presentation on union & 
class about renaming these widgets to something more meaningful to 
people having no C knowledge. The renaming we came up to is as follows:
-  --> 
-  --> 
-  --> 
-  --> 
-  --> 

The renaming of class/new to macro/expand is mandated by the fact 
that a  inlines the contents of the class definition without 
an enclosing container.

Sylvain

What's the status of the binding framework? Found these mails from 
march: http://marc.theaimsgroup.com/?t=10805991634&r=1&w=2

At least, on-delete-bean is missing, isn't it?

Maybe :-) (I'll have to look at this in deeper detail)
About the repeater binding, I had an simple idea that could tremendously 
simplify the binding job: a repeater could have a row creation counter, 
each row holding it's own counter value.

Upon load, rows would be numbered e.g. 1, 2, 3, 4. On save, if we find 
e.g. rows 4, 1, 5, 13, we can determine that rows 4&1 were moved, rows 
2&3 deleted and rows 5&13 are new. That may avoid that complicated (and 
difficult to understand) unique-id stuff that is currently needed in the 
repeater binding.

Another option to ease repeater binding could be to attach the loaded 
data as attributes in the widget row, thus giving instant access to that 
data at save time. And if some rows don't have that attribute, we know 
that these are new ones.

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

Re: [rant] please backport bugfixes to 2.1!

[Sylvain Wallez]

Tim Larson wrote:
On Wed, Nov 03, 2004 at 06:29:46PM +0100, Sylvain Wallez wrote:
 

Tim Larson wrote:
   

On Tue, Nov 02, 2004 at 11:29:28AM +0100, Sylvain Wallez wrote:
I am working on the port now and have it almost finished,
 

Buhooo... I missed your post and am also almost finished :-(((
   

:(
 

but I have a few questions about some recent changes that
the commit comments did not make clear to me:
AbstractWidget.java
 From: public Widget getParent()
 To:   public final Widget geParent()
 

I had a bug while writing widget states because Repeater.RepeaterRow was 
redefining getParent() while I was using this.parent. So I made it final 
in order to be able to use this.parent throughout AbstractWidget.
   

Ok, but I predict Marc will be unhappy ;)
 

Why? Does he have special widgets that redefine getParent(). If that's 
the case, we can remove the "final" and replace "this.parent" by 
"getParent()".

Could you explain what these changes are for, and then
I can finish the porting.
 

Mmmh... I nearly finished it on my side... how do we proceed? I'm ready 
to finish that job if you don't mind.
   

Please go ahead and commit, then I will comment if necessary.
 

Okay!
Note that there are some new features in 2.2 that I wouldn't like to be 
ported now to 2.1 as I'm not very happy with them and would like some 
discussion about them:
- the get/setProcessRequest() stuff which seems to overlap with widget 
states
   

Yeah, I did not think that design was ready either...but we may need
to expand widget states (tm) a little bit, but I will see after your
commit.
 

Ok. Something that's seem more and more necessary to me is an "output" 
state that would sit between "disabled" and "invisible", in order to 
render widgets as text and not as disabled inputs without having to use 
styling type="output".

- the new "choose/when" statement in EffectWidgetReplacingPipe: for 
complex control structures, we have template languages like JTXG and 
XSP. It doesn't seem good to me that every transformer reinvents it's 
own control structure language.
   

There is reason to this madness, if you will just bear with me
for a bit.  I will hold off on porting that to BRANCH_2_1_X.
I have a plan, an experiment, but if it is too disruptive for
the dev line (svn trunk) then I could move it to the whiteboard.
It involves compiled templates and transformers (yes, I figured
out an efficient way to compile and cache transformer-templates)
with fairly human-friendly syntax, view "widgets", and parallel
structure between the binding, model, and templates, including
things like having choose/when being in all three (as a more
functional, flexible replacement for union/case).  WDYT, do I
need to move this effort to the whiteboard? (not a vote ;)
 

You already told us about this idea, and it seems to me much more 
general than CForms. However, I also understand that you may want to use 
CForms as a playground for this experiment. But doing it in the main dev 
line when we are trying to achieve stable state for CForms is IMO dangerous.

So whiteboard/scratchpad seems a good idea. Remember: flowscript started 
there ;-)

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

Re: CForms: widget states added

[Sylvain Wallez]

Joerg Heinicke wrote:
On 03.11.2004 11:51, Sylvain Wallez wrote:
Does it fix this one?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27598

Mmmh... not sure, although you can prevent a widget from reading 
its value from the request by setting it's state do "disabled". 
This bug is more likely to be fixed by having widgets only changing 
their values *if* the corresponding request parameter is present, 
as proposed by Tim in the "[lazy vote] cforms request processing 
thread".

I don't think so. The bug was about an analogy to @direction="load" 
in binding. Having a widget with output styling does not prevent it 
from reading from request though there will not be request parameter 
of it.

That's exactly what the request processing thread is all about: don't 
change a widget's value if the corresponding request parameter 
doesn't exist. That's exactly the case of output styling.

When re-reading my written comment above I see I was not clear enough. 
It must read:

Having a widget with output styling does not prevent it from reading 
from request though there will not be request parameter of it by 
default. This means you can hack the URL to change the value but you 
should not be able to change the value of the widget at all as it is 
set to 'do not read the value from request' (the analogy to binding's 
@direction='load').

Ah, ok. So then instead of using type="output", the widget's state 
should be set to "disabled". That way, the value will never be read.

So I'm about to close the bug if the widget states work - what I 
assume ;-)

I would wait for this do-not-reset-value-if-parameter-is-not-present 
thing to be implemented.

Also after my clarification?

I leave this to your judgment ;-)
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Bug in forms-lib.js when adding @id to submit buttons?

[Sylvain Wallez]

Joerg Heinicke wrote:
On 03.11.2004 11:56, Sylvain Wallez wrote:
The problem is not in CForms, but in HTML: each form element (input, 
button, etc) is added as a property of the form it belongs to. 
Problem is that these new properties hide those that may already 
exist with the same name on the form.

And a form already has a "submit" property which is a function, which 
means that if you have an , we can no more 
programmatically submit the form using "form.submit()"...

Indeed a nice one ...
So the solution is to avoid naming CForms widget "submit"... Maybe we 
could enforce this at the form definition parsing level?

Hmm, I would not do it. On the one hand you can not check the code 
added in the templates as Bart did it. On the other hand form has more 
properties though submit is probably the most used one. What about a 
property 'action'? It would also break the form.

Don't know, as "action" is an attribute.
It's a problem of HTML, so we should not fix it in CForms IMO. 
Otherwise it will be a never ending story. It's a 'feature' that 
should made it into the FAQ.

Ok for the FAQ, but if several people fall into that trap, we may add 
some checks into the HMTL styling part of CForms for some well-known 
cases like "submit".

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

Re: [rant] please backport bugfixes to 2.1!

[Tim Larson]

On Wed, Nov 03, 2004 at 06:29:46PM +0100, Sylvain Wallez wrote:
> Tim Larson wrote:
> >On Tue, Nov 02, 2004 at 11:29:28AM +0100, Sylvain Wallez wrote:
> >I am working on the port now and have it almost finished,
> 
> Buhooo... I missed your post and am also almost finished :-(((

:(

> >but I have a few questions about some recent changes that
> >the commit comments did not make clear to me:
> >
> > AbstractWidget.java
> >   From: public Widget getParent()
> >   To:   public final Widget geParent()
> > 
> >
> 
> I had a bug while writing widget states because Repeater.RepeaterRow was 
> redefining getParent() while I was using this.parent. So I made it final 
> in order to be able to use this.parent throughout AbstractWidget.

Ok, but I predict Marc will be unhappy ;)

> > Field.java
> >   From: super validate
> >   To:   super validate && widget != null
> > 
> >
> 
> That's "value != null". This check is required as "old-style validators" 
> (the ones that were inside fd:datatype) assume a non-null value and this 
> was therefore leading to NPEs.

Ok, thanks for explaining.

> >Could you explain what these changes are for, and then
> >I can finish the porting.
> 
> Mmmh... I nearly finished it on my side... how do we proceed? I'm ready 
> to finish that job if you don't mind.

Please go ahead and commit, then I will comment if necessary.

> Note that there are some new features in 2.2 that I wouldn't like to be 
> ported now to 2.1 as I'm not very happy with them and would like some 
> discussion about them:
> - the get/setProcessRequest() stuff which seems to overlap with widget 
> states

Yeah, I did not think that design was ready either...but we may need
to expand widget states (tm) a little bit, but I will see after your
commit.

> - the new "choose/when" statement in EffectWidgetReplacingPipe: for 
> complex control structures, we have template languages like JTXG and 
> XSP. It doesn't seem good to me that every transformer reinvents it's 
> own control structure language.

There is reason to this madness, if you will just bear with me
for a bit.  I will hold off on porting that to BRANCH_2_1_X.

I have a plan, an experiment, but if it is too disruptive for
the dev line (svn trunk) then I could move it to the whiteboard.
It involves compiled templates and transformers (yes, I figured
out an efficient way to compile and cache transformer-templates)
with fairly human-friendly syntax, view "widgets", and parallel
structure between the binding, model, and templates, including
things like having choose/when being in all three (as a more
functional, flexible replacement for union/case).  WDYT, do I
need to move this effort to the whiteboard? (not a vote ;)

--Tim Larson

Re: CForms work to do before marking it stable

[Reinhard Poetz]

Sylvain Wallez wrote:
Hi all,
Here's the result of the discussion at the GT about the work needed for 
CForms to reach stable state. Thanks to Pier for being the secretary. He 
did it so well ;-P

Flowscript integration:
- don't use JS wrapping classes for widgets: they introduce 
yet-another-API which is sometimes confusing.
- update the widgets' java public API so that it's more "Rhino-friendly" 
(check JavaBean conformance and add accessors where needed)
- implement an equivalent to the bookmark feature of V2, by a function 
property of the form that gets called at each request roundtrip
- add helper methods to the Form class to create event listeners from JS 
functions
- restrict the "cocoon" object that's available in the event handlers so 
that it does not provide response-related methods (sendPage etc)

Java code:
- ignore the "action-command" attribute which is currently useless 
except for repeater-actions and row-actions
- implement widget states (a patch has been provided for this which I 
will take care of)

Misc:
- write a form definition schema so that definitions can be optionally 
validated.
- flatten the CForm-related component in cocoon.xconf. This will ease 
the transition to a non-Avalon container

There was also a discussion also after my presentation on union & class 
about renaming these widgets to something more meaningful to people 
having no C knowledge. The renaming we came up to is as follows:
-  --> 
-  --> 
-  --> 
-  --> 
-  --> 

The renaming of class/new to macro/expand is mandated by the fact that a 
 inlines the contents of the class definition without an 
enclosing container.

Sylvain

What's the status of the binding framework? Found these mails from march: 
http://marc.theaimsgroup.com/?t=10805991634&r=1&w=2

At least, on-delete-bean is missing, isn't it?
--
Reinhard

Re: [rant] please backport bugfixes to 2.1!

[Sylvain Wallez]

Tim Larson wrote:
On Tue, Nov 02, 2004 at 11:29:28AM +0100, Sylvain Wallez wrote:
 

Unusual for me, but time for a rant: I wrote the new CForms widget state 
feature in 2.1 and tried to port it to 2.2.

WHAT A PITA!
There are a number or *bug fixes* or minor new features that only exist 
in 2.2. Why aren't they ported also to 2.1?

Please, please, consider upgrading both branches at the same time. There 
will be some time before 2.2 is out and not everybody runs a snapshot of 
trunk.
   


 

Grmbl... lost 2 hours this morning to do the merge, and finally reverted 
all :-(
   

Very sorry that you lost time :(  I had not ported my changes
to 2_1_x yet because I was not sure they were ready, but
addmittedly there were some bugfixes included that I should
have ported immediately.
I am working on the port now and have it almost finished,
 

Buhooo... I missed your post and am also almost finished :-(((
but I have a few questions about some recent changes that
the commit comments did not make clear to me:
 AbstractWidget.java
   From: public Widget getParent()
   To:   public final Widget geParent()
 

I had a bug while writing widget states because Repeater.RepeaterRow was 
redefining getParent() while I was using this.parent. So I made it final 
in order to be able to use this.parent throughout AbstractWidget.

 Field.java
   From: super validate
   To:   super validate && widget != null
 

That's "value != null". This check is required as "old-style validators" 
(the ones that were inside fd:datatype) assume a non-null value and this 
was therefore leading to NPEs.

 Repeater.java
   In inner class RepeaterRow
 From: getParent() returns Repeater.this and
   setParent() throws a RuntimeException
 To:   setParent(Repeater.this)
 (This seems to be caused by the AbstractWidget
 change above.)
 

Exactly.
Could you explain what these changes are for, and then
I can finish the porting.
 

Mmmh... I nearly finished it on my side... how do we proceed? I'm ready 
to finish that job if you don't mind.

Note that there are some new features in 2.2 that I wouldn't like to be 
ported now to 2.1 as I'm not very happy with them and would like some 
discussion about them:
- the get/setProcessRequest() stuff which seems to overlap with widget 
states
- the new "choose/when" statement in EffectWidgetReplacingPipe: for 
complex control structures, we have template languages like JTXG and 
XSP. It doesn't seem good to me that every transformer reinvents it's 
own control structure language.

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

Re: trunk does not compile

[Stefano Mazzocchi]

Torsten Curdt wrote:
will do that... strange!

works now
...weird ...weird ...weird
bug in svn? update your svn client to the latest 1.0.x version.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [GUMP@brutus]: Project cocoon-block-proxy (in module cocoon) failed

[Stefano Mazzocchi]

Antonio Gallardo wrote:
Stefano Mazzocchi dijo:
Antonio Gallardo wrote:

Stefano Mazzocchi dijo:

Antonio Gallardo wrote:

Stefano Mazzocchi dijo:

Gump wrote:


cocoon-block-proxy-compile:
 [javac] Compiling 4 source files to
/home/gump/workspaces2/public/workspace/cocoon/build/cocoon-02112004/blocks/proxy/dest
 [javac]
/home/gump/workspaces2/public/workspace/cocoon/src/blocks/proxy/java/org/apache/cocoon/generation/HttpProxyGenerator.java:294:
cannot resolve symbol
 [javac] symbol  : method getRequestBodyAsString ()
 [javac] location: class
org.apache.commons.httpclient.methods.PostMethod
 [javac] String body = ((PostMethod)
this.method).getRequestBodyAsString();
 [javac]   ^
 [javac] 1 error
I don't know how to fix this one from the gump side, it needs some
code
changes since httpclient change a lot since this code was created.
Any ideas?

I saw the code of httpclient 2.0.x and 3.0 and it is quite diferent.
They
are changing a lot in the new 3.0.x release. If we want gump compile
this
block, we need to add a dependency to our own distributed jar version
2.0.2.
I know this is a hack. The other way is to see more in depth and find a
way to compile code using both httpclient 2.0.2 and 3.0 too.
WDYT?
That build is against the 2.0.x branch.

Its posible in the CVS version.
In the javadocs for release 2.0.2, the PostMethod. Because is direct
derived from EntityEnclosingMethod:
http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/methods/PostMethod.html
Now go to the CVS. in the HTTPCLIENT_2_0_BRANCH We still see the
method getRequestBodyAsString() inside:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/EntityEnclosingMethod.java?rev=1.18.2.5&only_with_tag=HTTPCLIENT_2_0_BRANCH&view=markup
...
I am not a CVS guru, but in the HEAD (3.0 release) there is not the
method.
Seems like they broke a contract? I mean removing a method without
deprecate it first?
yeah, they did, but what I don't  understand is why we didn't build
against HTTPCLIENT_2_0_BRANCH.

I think we are not using the HTTPCLIENT_2_0_BRANCH. See:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/PostMethod.java?only_with_tag=HTTPCLIENT_2_0_BRANCH&view=markup
And in the EntityEnclisingMethod:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/EntityEnclosingMethod.java?rev=1.18.2.5&only_with_tag=HTTPCLIENT_2_0_BRANCH&view=auto
Is gump using the right branch?
great question, I'll check it out on the gump end, thanks.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: ESQL, Oracle CLOB and encoding

[Torsten Curdt]

george georgovassilis wrote:
Good morning Dear All
This is a re-post from the users list where unluckily I didn't find a 
solution to my question.
So, appologies for cross-posting.

I've run into trouble with my ESQL page. In detail:
I'm running an Oracle database pool and a few tables in there with CLOBs 
which contain UTF-8 strings.
The following code extracts the data quite nicely:

oracle.sql.CLOB body =  (oracle.sql.CLOB);
String xmlbody = (body.length()>0? body.getSubString(1, 
(int)body.length()):"");

which returns correctly

ÎÎ ÎÎÏÏÎÏÎ ÎÏÎÏÎ ÏÏÎÎ ÎÎÏÎÎÎÏÎÎ 'ÎÎÎÏÎ / ÎÎ'

The much more elegant
String stripped = ;
however returns garbage:

ÂÎ ÎÂÎÎÂÎÎ Â ÎΠÎÂÎÂÂÎÎâ 'âÂÎΠ/ âÂÂÂÎÂ'

Is there any way I still can use the esql?
Without looking at the code esql:get-ascii implies
ascii encoding ...but you are talking about uft-8
encoding. maybe that's the problem.
Compare the esql:get-object and esql:get-ascii
implementations in the esql.xsl.
cheers
--
Torsten

Re: [rant] please backport bugfixes to 2.1!

[Tim Larson]

On Tue, Nov 02, 2004 at 09:12:28PM +, Tim Larson wrote:
> I am working on the port now and have it almost finished,
> but I have a few questions about some recent changes that
> the commit comments did not make clear to me:
> 
>   AbstractWidget.java
> From: public Widget getParent()
> To:   public final Widget geParent()
>   Field.java
> From: super validate
> To:   super validate && widget != null
>   Repeater.java
> In inner class RepeaterRow
>   From: getParent() returns Repeater.this and
> setParent() throws a RuntimeException
>   To:   setParent(Repeater.this)
>   (This seems to be caused by the AbstractWidget
>   change above.)
> 
> Could you explain what these changes are for, and then
> I can finish the porting.

Sorry for the quick, unformatted email; I had to rush out to vote.
(hmm, perhaps not "early and often" enough to have an effect ;(

What I was wondering was why getParent was made final in
AbstractWidget, thus causing RepeaterRow to not be able
to enforce that its parent cannot be changed.

And I was wondering if this from Field.java in BRANCH_2_1_X:
   
  if (super.validate() && value != null) {
  // New-style validators were successful. Check the old-style ones.
  this.validationError = getDatatype().validate(value, new 
ExpressionContextImpl(this));
  }

...needs to be ported to the trunk?  I think so, but my mind is
a little cloudy from all the porting and I wanted to doublecheck.

--Tim Larson

Re: [lazy vote] cforms request processing

[Joerg Heinicke]

On 03.11.2004 00:21, Sylvain Wallez wrote:
As I told before I am not sure. I really want to see what the other 
people
will said here. I also already saw that Sylvain voted +1 for the changes.
But I am not sure if this is correct or not. That is all.
Yes, I'm +1. Or +10, +100 and even +1000 :-)
This issue has raised a number of questions from users seeing some 
fields unexpectedly loosing their values, and has been discussed at length.

The only visible change, as stated by Tim, is the need for boolean 
fields to be accompanied by a "presence notifier" input, whose purpose 
is to indicate that a boolean field is present in the form. This is 
required to circumvent the fact that HTML sends nothing for an unchecked 
checkbox, and therefore doesn't allow to know if the chekbox is present 
but unchecked, or is absent in the page.

This has absolutely no impact on the fact that only widgets present in 
the form read request parameters, and that therefore no one can input 
value that doesn't match a widget.
Exactly, I see no possible negative consequences besides the additional 
"presence notifiers" as Sylvain called them.

So +1 from here too.
Joerg

Re: model update after repeater change

[Joerg Heinicke]

On 19.10.2004 18:42, Jorg Heymans wrote:
Is there a reason why the model is not updated after nodes are 
added/removed to a repeater?

I have 2 frames, one with a repeater, the other with an applet. The 
applet gets its data from the model and is refreshed using an on-load 
event on the repeater frame. However, when rows are added or removed, 
the model bean is not updated yet. Only after the actual submit it gets 
updated and my applet is "synced" again.
Just for the record: Answered at 
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=109949546618166&w=4.

Joerg

Re: [lazy vote] cforms request processing

[Nuno Santos]

What i ment was that if a widget is disabled or not in a view it
shouldn't be processed as opposed to an empty parameter. They both have
the same value when invoking the "Request.getParameter" (null), don't
they? 

On Tue, 2004-11-02 at 23:18, Sylvain Wallez wrote:
> Nuno Santos wrote:
> 
> >The Request interface has a method to get an enumeration of parameter
> >names( getParameterNames), so just check the existence of the widget
> >Request parameter name and process only if exist!
> >  
> >
> 
> We don't need to enumerate parameters, as each widget knows which 
> parameters it should consider. The discussion here is about widgets 
> whose request parameters are *not* present, and who therefore see their 
> value reset to null. We want to avoid this.
> 
> Sylvain
-- 
Nuno Santos <[EMAIL PROTECTED]>
Electroplus, lda

DO NOT REPLY [Bug 31813] - [Sample] DreamTeam (dependent widgets in a repeater)

[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=31813

[Sample] DreamTeam (dependent widgets in a repeater)





--- Additional Comments From [EMAIL PROTECTED]  2004-11-03 15:20 ---
The form attributes are still set, also in content-view. There is a problem with
event handling because

var position = event.source.lookupWidget("../position").value;

returns null.

Why is eventhandling function "updateCountryWidget" called at all? Maybe a
"leftover" of the previous request? I'm not so familiar with implementation
details of the event framework, maybe somebody else knows more?

DO NOT REPLY [Bug 31992] - [PATCH] CForms DreamTeam Sample, explicitely variable declaration

[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=31992

[PATCH] CForms DreamTeam Sample, explicitely variable declaration

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

DO NOT REPLY [Bug 31992] - [PATCH] CForms DreamTeam Sample, explicitely variable declaration

[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=31992

[PATCH] CForms DreamTeam Sample, explicitely variable declaration

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-11-03 14:56 ---
Thanks, variable scope changed in sample.

Re: trunk does not compile

[Torsten Curdt]

will do that... strange!
works now
...weird ...weird ...weird
--
Torsten

Re: trunk does not compile

[Torsten Curdt]

Because I have the import :)
well, that could explain why :-)
weird! why didn't a "svn up" pick up then?
And if you look at:
http://svn.apache.org/repos/asf/cocoon/trunk/src/blocks/forms/java/org/apach
e/cocoon/forms/binding/JXPathBindingManager.java
it's there as well - so it seems that you have some local problems,
perhaps doing a fresh checkout helps?
will do that... strange!
thanks for the help,
cheers
--
Torsten

RE: trunk does not compile

[Carsten Ziegeler]

Torsten Curdt wrote: 
> 
> but the point is: have a look at the source
> 
> src/blocks/forms/java/org/apache/cocoon/forms/binding/JXPathBi
> ndingManager.java
> 
> it's using the LifecycleHelper ...but there is no import 
> statement and it's not inside the same package. so it should 
> not compile. like it does for me. why is it compiling for you?
> 
Because I have the import :)
And if you look at:

http://svn.apache.org/repos/asf/cocoon/trunk/src/blocks/forms/java/org/apach
e/cocoon/forms/binding/JXPathBindingManager.java

it's there as well - so it seems that you have some local problems,
perhaps doing a fresh checkout helps?

Carsten

Re: trunk does not compile

[Torsten Curdt]

Antonio Gallardo wrote:
Hi Torsten:
Just a thought:
Can you check the local.build.properties and the local.block.properties?
sure ...I recreated them from the non-local ones
but the point is: have a look at the source
src/blocks/forms/java/org/apache/cocoon/forms/binding/JXPathBindingManager.java
it's using the LifecycleHelper ...but there is
no import statement and it's not inside the same
package. so it should not compile. like it does
for me. why is it compiling for you?
weird!
--
Torsten

Re: trunk does not compile

[Antonio Gallardo]

Hi Torsten:

Just a thought:

Can you check the local.build.properties and the local.block.properties?

Best Regards,

Antonio Gallardo

Torsten Curdt dijo:
> Carsten Ziegeler wrote:
>> Hmm, I just tested the latest from SVN and it works...the only
>> difference
>> I see is that I'm using windows... :)
>
> well, the build and/or blocks properties could be another
> difference. AFAICS the forms block should not compile
> without the fix on my disk. (added the import statements)
>
> did you comment out any blocks?
>
>> Now, do you see these lines at the beginning?
>>
>>
>>>compile-core:
>>>Copying 18 files to
>>> D:\dev\workspace\cocoon\build\cocoon-2.2.0-dev\classes
>>>Copied 62 empty directories to 35 empty directories under
>>
>> D:\dev\workspace\cocoo
>>
>
> compile-core:
> Copying 19 files to
> /home/tcurdt/dev/cocoon-trunk/build/cocoon-2.2.0-dev/classes
> Copied 62 empty directories to 33 empty directories under
> /home/tcurdt/dev/cocoon-trunk/build/cocoon-2.2.0-dev/classes
> Compiling Cocoon Core
>
> yepp! (added a class to core)
>
> cheers
> --
> Torsten
>

RE: trunk does not compile

[Carsten Ziegeler]

Torsten Curdt wrote:
> Carsten Ziegeler wrote:
> > Hmm, I just tested the latest from SVN and it works...the only 
> > difference I see is that I'm using windows... :)
> 
> well, the build and/or blocks properties could be another 
> difference. AFAICS the forms block should not compile without 
> the fix on my disk. (added the import statements)
> 
Hmm, I use the standard build/blocks properties and it works.

Carsten

RE: @action-command required for submit widgets?

[Bart Molenkamp]

Oke, thanks, I didn't know that :-)

> -Original Message-
> From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 03, 2004 12:59 PM
> To: [EMAIL PROTECTED]
> Subject: Re: @action-command required for submit widgets?
> 
> On 03.11.2004 12:14, Bart Molenkamp wrote:
> 
> > Why is attribute action-command required for submit widgets? AFAICS,
> > it's only used when firing an event, and in most cases, these events
> > won't be captured (because submit will end processing the form, and
you
> > could see this as the event).
> >
> > If you don't use submit widgets but just add 
to
> > the form template, you'll have the same effect. Is that correct?
> 
> This 'feature' is on the list for stabilizing CForms. The
action-command
> attribute will be made optional as any other attribute too.
> 
> Joerg

Re: trunk does not compile

[Torsten Curdt]

Carsten Ziegeler wrote:
Hmm, I just tested the latest from SVN and it works...the only difference
I see is that I'm using windows... :)
well, the build and/or blocks properties could be another
difference. AFAICS the forms block should not compile
without the fix on my disk. (added the import statements)
did you comment out any blocks?
Now, do you see these lines at the beginning?

compile-core:
Copying 18 files to D:\dev\workspace\cocoon\build\cocoon-2.2.0-dev\classes
Copied 62 empty directories to 35 empty directories under
D:\dev\workspace\cocoo
compile-core:
Copying 19 files to 
/home/tcurdt/dev/cocoon-trunk/build/cocoon-2.2.0-dev/classes
Copied 62 empty directories to 33 empty directories under 
/home/tcurdt/dev/cocoon-trunk/build/cocoon-2.2.0-dev/classes
Compiling Cocoon Core

yepp! (added a class to core)
cheers
--
Torsten

Re: @action-command required for submit widgets?

[Joerg Heinicke]

On 03.11.2004 12:14, Bart Molenkamp wrote:
Why is attribute action-command required for submit widgets? AFAICS,
it's only used when firing an event, and in most cases, these events
won't be captured (because submit will end processing the form, and you
could see this as the event).
If you don't use submit widgets but just add  to
the form template, you'll have the same effect. Is that correct?
This 'feature' is on the list for stabilizing CForms. The action-command 
attribute will be made optional as any other attribute too.

Joerg

Re: CForms: widget states added

[Joerg Heinicke]

On 03.11.2004 11:51, Sylvain Wallez wrote:
Does it fix this one?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27598
Mmmh... not sure, although you can prevent a widget from reading its 
value from the request by setting it's state do "disabled". This bug 
is more likely to be fixed by having widgets only changing their 
values *if* the corresponding request parameter is present, as 
proposed by Tim in the "[lazy vote] cforms request processing thread".
I don't think so. The bug was about an analogy to @direction="load" in 
binding. Having a widget with output styling does not prevent it from 
reading from request though there will not be request parameter of it.
That's exactly what the request processing thread is all about: don't 
change a widget's value if the corresponding request parameter doesn't 
exist. That's exactly the case of output styling.
When re-reading my written comment above I see I was not clear enough. 
It must read:

Having a widget with output styling does not prevent it from reading 
from request though there will not be request parameter of it by 
default. This means you can hack the URL to change the value but you 
should not be able to change the value of the widget at all as it is set 
to 'do not read the value from request' (the analogy to binding's 
@direction='load').

So I'm about to close the bug if the widget states work - what I 
assume ;-)
I would wait for this do-not-reset-value-if-parameter-is-not-present 
thing to be implemented.
Also after my clarification?
Joerg

RE: trunk does not compile

[Carsten Ziegeler]

Hmm, I just tested the latest from SVN and it works...the only difference
I see is that I'm using windows... :)

Now, do you see these lines at the beginning?

>compile-core:
>Copying 18 files to D:\dev\workspace\cocoon\build\cocoon-2.2.0-dev\classes
>Copied 62 empty directories to 35 empty directories under
D:\dev\workspace\cocoo
>n\build\cocoon-2.2.0-dev\classes
>Compiling Cocoon Core
>Compiling 12 source files to
D:\dev\workspace\cocoon\build\cocoon-2.2.0-dev\clas
>ses
>Created dir: D:\dev\workspace\cocoon\build\cocoon-2.2.0-dev\mocks
>Compiling 1 source file to
D:\dev\workspace\cocoon\build\cocoon-2.2.0-dev\mocks
>Compiling 520 source files to
D:\dev\workspace\cocoon\build\cocoon-2.2.0-dev\cla
>sses 

Carsten

> -Original Message-
> From: Torsten Curdt [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 03, 2004 10:48 AM
> To: [EMAIL PROTECTED]
> Subject: Re: trunk does not compile
> 
> here we go
> 
> --8<--
> cocoon-block-forms-compile:
> Compiling 271 source files to
> /home/tcurdt/dev/cocoon-trunk/build/cocoon-2.2.0-dev/blocks/forms/dest
> /home/tcurdt/dev/cocoon-trunk/src/blocks/forms/java/org/apache
/cocoon/forms/util/SimpleServiceSelector.java:81: 
> cannot resolve symbol
> symbol  : variable LifecycleHelper
> location: class org.apache.cocoon.forms.util.SimpleServiceSelector
>  LifecycleHelper.setupComponent(
>  ^
> /home/tcurdt/dev/cocoon-trunk/src/blocks/forms/java/org/apache
/cocoon/forms/acting/HandleFormSubmitAction.java:74: 
> cannot resolve symbol
> symbol  : variable LifecycleHelper
> location: class org.apache.cocoon.forms.acting.HandleFormSubmitAction
>  LifecycleHelper.setupComponent(formHandler, 
> null, null, manager, null);
>  ^
> /home/tcurdt/dev/cocoon-trunk/src/blocks/forms/java/org/apache
/cocoon/forms/binding/JXPathBindingManager.java:84: 
> cannot resolve symbol
> symbol  : variable LifecycleHelper
> location: class org.apache.cocoon.forms.binding.JXPathBindingManager
>  LifecycleHelper.setupComponent(bindingBuilderSelector,
>  ^
> /home/tcurdt/dev/cocoon-trunk/src/blocks/forms/java/org/apache
/cocoon/forms/datatype/JavaSelectionListBuilder.java:55: 
> cannot resolve symbol
> symbol  : variable LifecycleHelper
> location: class 
> org.apache.cocoon.forms.datatype.JavaSelectionListBuilder
>  LifecycleHelper.setupComponent(list,
> getLogger(), null,
>  ^
> 4 errors
> --8<--
> 
> 
> find -name LifecycleHelper.java
> 
> revealed imports were missing
> 
> Then I got this
> 
> --8<--
> cocoon-block-eventcache-compile:
> Compiling 17 source files to
> /home/tcurdt/dev/cocoon-trunk/build/cocoon-2.2.0-dev/blocks/ev
entcache/dest
> /home/tcurdt/dev/cocoon-trunk/src/blocks/eventcache/java/org/a
pache/cocoon/caching/impl/JMSEventMessageListener.java:53: 
> cannot resolve symbol
> symbol  : class AbstractMessageListener
> location: class org.apache.cocoon.caching.impl.JMSEventMessageListener
> public class JMSEventMessageListener extends 
> AbstractMessageListener implements ThreadSafe {
>   ^
> /home/tcurdt/dev/cocoon-trunk/src/blocks/eventcache/java/org/a
pache/cocoon/caching/impl/JMSEventMessageListener.java:71: 
> cannot resolve symbol
> symbol  : variable super
> location: class org.apache.cocoon.caching.impl.JMSEventMessageListener
>  super.parameterize(parameters);
>  ^
> /home/tcurdt/dev/cocoon-trunk/src/blocks/eventcache/java/org/a
pache/cocoon/caching/impl/JMSEventMessageListener.java:76: 
> cannot resolve symbol
> symbol  : variable super
> location: class org.apache.cocoon.caching.impl.JMSEventMessageListener
>  super.initialize();
>  ^
> /home/tcurdt/dev/cocoon-trunk/src/blocks/eventcache/java/org/a
pache/cocoon/caching/impl/JMSEventMessageListener.java:77: 
> cannot resolve symbol
> symbol  : variable m_manager
> location: class org.apache.cocoon.caching.impl.JMSEventMessageListener
>  m_eventCache = (EventAware) 
> m_manager.lookup(m_eventAwareRole);
>  ^
> /home/tcurdt/dev/cocoon-trunk/src/blocks/eventcache/java/org/a
pache/cocoon/caching/impl/JMSEventMessageListener.java:81: 
> cannot resolve symbol
> symbol  : variable super
> location: class org.apache.cocoon.caching.impl.JMSEventMessageListener
>  super.dispose();
>  ^
> /home/tcurdt/dev/cocoon-trunk/src/blocks/eventcache/java/org/a
pache/cocoon/caching/impl/JMSEventMessageListener.java:82: 
> cannot resolve symbol
> symbol  : variable m_manager
> location: class org.apache.cocoon.caching.impl.JMSEventMessageListener
>  this.m_manager.release(m_eventCache);
>  ^
> /home/tcurdt/dev/cocoon-trunk/src/blocks/eventcache/java/org/a
pache/cocoon/caching/impl/JMSEventMessageListener.java:89: 
> cannot resolve symbol
> symbol  : method getLogger ()
> 

Re: Bug in forms-lib.js when adding @id to submit buttons?

[Joerg Heinicke]

On 03.11.2004 11:56, Sylvain Wallez wrote:
The problem is not in CForms, but in HTML: each form element (input, 
button, etc) is added as a property of the form it belongs to. Problem 
is that these new properties hide those that may already exist with the 
same name on the form.

And a form already has a "submit" property which is a function, which 
means that if you have an , we can no more 
programmatically submit the form using "form.submit()"...
Indeed a nice one ...
So the solution is to avoid naming CForms widget "submit"... Maybe we 
could enforce this at the form definition parsing level?
Hmm, I would not do it. On the one hand you can not check the code added 
in the templates as Bart did it. On the other hand form has more 
properties though submit is probably the most used one. What about a 
property 'action'? It would also break the form. It's a problem of HTML, 
so we should not fix it in CForms IMO. Otherwise it will be a never 
ending story. It's a 'feature' that should made it into the FAQ.

Joerg

@action-command required for submit widgets?

[Bart Molenkamp]

Hi all,

Why is attribute action-command required for submit widgets? AFAICS,
it's only used when firing an event, and in most cases, these events
won't be captured (because submit will end processing the form, and you
could see this as the event).

If you don't use submit widgets but just add  to
the form template, you'll have the same effect. Is that correct?

Bart.

RE: Bug in forms-lib.js when adding @id to submit buttons?

[Bart Molenkamp]

> 
> Hehe, I ran into this one several times :-)
> 
> The problem is not in CForms, but in HTML: each form element (input,
> button, etc) is added as a property of the form it belongs to. Problem
> is that these new properties hide those that may already exist with
the
> same name on the form.
> 
> And a form already has a "submit" property which is a function, which
> means that if you have an , we can no more
> programmatically submit the form using "form.submit()"...
> 
> So the solution is to avoid naming CForms widget "submit"... Maybe we
> could enforce this at the form definition parsing level?
> 
> Sylvain

Good idea. Then users get better informed about the possible errors with
submit-on-change. I'll look if I have some time to provide a patch, OK?

Bart.

Re: Bug in forms-lib.js when adding @id to submit buttons?

[Sylvain Wallez]

Bart Molenkamp wrote:
Hi all,
I was wondering if I found a bug in CForms. I have a union widget, with
. At the bottom of my form, I have
a submit button. When the button looks like this:

Then the form is submitted when the union has changed (which is the
correct and expected behaviour). But when I add the id attribute to the
submit button, it doesn't work anymore:

The reason to add the id is because I want more submit buttons with
different behaviour (e.g. a cancel button and a submit button). Looking
in the JavaScript console of Mozilla, I get the errors:
Error: form.submit is not a function (http:///forms-lib.js, line
67).
and
Error: uncaught exception: Permission denied to get property
HTMLDivElement.parentNode (line 44). This is in forms_getForm(), where a
recursive loop searches for the "FORM" tag.
 

Hehe, I ran into this one several times :-)
The problem is not in CForms, but in HTML: each form element (input, 
button, etc) is added as a property of the form it belongs to. Problem 
is that these new properties hide those that may already exist with the 
same name on the form.

And a form already has a "submit" property which is a function, which 
means that if you have an , we can no more 
programmatically submit the form using "form.submit()"...

So the solution is to avoid naming CForms widget "submit"... Maybe we 
could enforce this at the form definition parsing level?

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

Re: CForms: widget states added

[Sylvain Wallez]

Joerg Heinicke wrote:
On 03.11.2004 09:06, Sylvain Wallez wrote:
Does it fix this one?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27598

Mmmh... not sure, although you can prevent a widget from reading its 
value from the request by setting it's state do "disabled". This bug 
is more likely to be fixed by having widgets only changing their 
values *if* the corresponding request parameter is present, as 
proposed by Tim in the "[lazy vote] cforms request processing thread".

I don't think so. The bug was about an analogy to @direction="load" in 
binding. Having a widget with output styling does not prevent it from 
reading from request though there will not be request parameter of it.

That's exactly what the request processing thread is all about: don't 
change a widget's value if the corresponding request parameter doesn't 
exist. That's exactly the case of output styling.

So I'm about to close the bug if the widget states work - what I 
assume ;-)

I would wait for this do-not-reset-value-if-parameter-is-not-present 
thing to be implemented.

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

Re: Templating Engine - Next steps?

[Daniel Fagerstrom]

Carsten Ziegeler wrote:
Daniel Fagerstrom wrote: 
 

I have done some work on implementing a Jelly generator. 
Basically my own versions of the JellyGenerator in scratchpad 
and your TemplateObjectModelHelper, didn't know the existence 
of either of them :/

The most irritating problem that I have found this far is 
that it uses java.net.URL for uri handling which doesn't work 
that well together with the Excialibur Sources in Cocoon.

   

Yepp, that's one problem.
 

After some searching I found that you didn't find it suitable 
for multi threaded environment: 
http://www.osoco.net/weblogs/rael/archives/000202.html, do 
you remember what was the problem? Other problems?
   

I'm not that sure (it's sooo long ago),
Yes, nearly 10 months ;)
but I think the template
generated by Jelly is tied to the context - so this means you
have to use your own "compiled template" for each invokation.
HTH
Carsten
 

Ok, it is usually a frustrating experience trying to work around design 
problems in software that you cannot change. So I guess I join the 
NIH-camp ;) and start thinking about the refactoring of  the 
JXTemplateGenerator.

/Daniel

Bug in forms-lib.js when adding @id to submit buttons?

[Bart Molenkamp]

Hi all,

I was wondering if I found a bug in CForms. I have a union widget, with
. At the bottom of my form, I have
a submit button. When the button looks like this:



Then the form is submitted when the union has changed (which is the
correct and expected behaviour). But when I add the id attribute to the
submit button, it doesn't work anymore:



The reason to add the id is because I want more submit buttons with
different behaviour (e.g. a cancel button and a submit button). Looking
in the JavaScript console of Mozilla, I get the errors:
Error: form.submit is not a function (http:///forms-lib.js, line
67).
and
Error: uncaught exception: Permission denied to get property
HTMLDivElement.parentNode (line 44). This is in forms_getForm(), where a
recursive loop searches for the "FORM" tag.

When I add the buttons to the form definition, it also works like
expected. So not really a problem, I was just wondering what was going
on (due to the strange exceptions reported by Mozilla).

Bart.

Re: CForms: widget states added

[Joerg Heinicke]

On 03.11.2004 09:06, Sylvain Wallez wrote:
Does it fix this one?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27598
Mmmh... not sure, although you can prevent a widget from reading its 
value from the request by setting it's state do "disabled". This bug is 
more likely to be fixed by having widgets only changing their values 
*if* the corresponding request parameter is present, as proposed by Tim 
in the "[lazy vote] cforms request processing thread".
I don't think so. The bug was about an analogy to @direction="load" in 
binding. Having a widget with output styling does not prevent it from 
reading from request though there will not be request parameter of it. 
So I'm about to close the bug if the widget states work - what I assume ;-)

Joerg

Re: [lazyweb] SVN checkout without keyword expansion?

[Sylvain Wallez]

Giacomo Pati wrote:
On Wed, 3 Nov 2004, Sylvain Wallez wrote:
Hi all,
A lazyweb question about SVN: is there a way to perform a checkout 
without expanding the $Id$ keyword? I couldn't find one by googling 
around, and that would be so useful for merging branches where many 
files only differ by their revision number.

Currently I used a quickly hacked script that does the job, but that 
would be much cleaner to have it handled directly by svn.

I usually compare different branches by use of the following gnu diff 
command in a script:

diff -rubBd -x CVS -x target -x .svn -x .cvsignore -x .settings \
-x .project \
--ignore-matching-lines=\\\$Author: \
--ignore-matching-lines=\\\$Date: \
--ignore-matching-lines=\\\$Header: \
--ignore-matching-lines=\\\$Id: \
--ignore-matching-lines=\\\$Locker: \
--ignore-matching-lines=\\\$Name: \
--ignore-matching-lines=\\\$RCSfile: \
--ignore-matching-lines=\\\$Revision: \
--ignore-matching-lines=\\\$Source: \
--ignore-matching-lines=\\\$State: \
--ignore-matching-lines=\\\$Version: $* $TARGET $SOURCE
It is suitable for CVS as well as for SVN. Hope this helps.

Eeek! Thanks for the tip, but I prefer more graphical front-ends to 
reconcile changes :-)

I use Eclipse's diff utility by selecting the same folder in the two 
branches then "compare with/each other" in the contextual menu.

The nice thing about SVN is that it doesn't consider as having changed a 
file where "$Id: blah blah$" has been changed to "$Id$". Here's the 
script I use (named "rmkw" for "remove keywords")

#!/bin/sh
temp=rmkw.tmp
find . \( -name '*.java' -or -name '*.xml' -or -name '*.xmap' -or -name 
'*.js' -or -name '*.xsl' \) -print | while read file
do
 echo $file
 /usr/bin/sed -e 's/\$Id:.*\$/$Id$/' $file > $temp
 mv $temp $file
done

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

Re: latest Moin

[Reinhard Poetz]

Upayavira wrote:
Reinhard Poetz wrote:
Upayavira wrote:
Reinhard Poetz wrote:
Is the content of the right-side bar customizable so that we get our 
former menu back?


What you mean you want a customisable right side bar? Not just a 
right side bar? Fussy eh? ;-)

More seriously, I believe there is a way to configure the options, 
somewhere behind the scenes, but not via the wiki interface.

Not sure if we speak of the same. What I want is the content of 
http://wiki.apache.org/cocoon/SiteNavigation in the menu. Without a 
menu that leads to all pages I have the sense of a big mess.

I'm afraid it doesn't offer that. We can add our own options to the 
side-bar, but it won't be an editable wiki page. If we can come up with 
a small number of relatively permanant links, 
I think it should be possible. The menu of the JSPWiki at cocoondev.org 
contained following entries

#  About
# People - the personal Wiki pages of various people in the Cocoon community
# CocoonCompetenceCenter
# Tutorials
# HowTos
# BestPractices
# Snippets
# ExampleApps
# FAQs - answers to Frequently Asked Questions
# Links - various links to off-site information about Cocoon
# UserGroups - existing and proposed
# OurWishlists - some enhancements that we would like
# CocoonDocsDrafts - get involved with improving the documentation
# SamplesRefactor - the Cocoon Samples local demo webapp has been re-organised 
many times (please help to fix it)
# RT - various Random Thoughts
# PossibleApplications
# Events

It should be possible to reduce the number of items. Here a proposal:
# Community (People, Usergroups)
# Documentation (Tutorials, HowTos, Snippets, FAQs, Example Apps, Possible
  Applications)
# Links
# CocoonDocsDraft
# RT
# Events
--
Reinhard

Re: trunk does not compile

[Torsten Curdt]

here we go
--8<--
cocoon-block-forms-compile:
Compiling 271 source files to 
/home/tcurdt/dev/cocoon-trunk/build/cocoon-2.2.0-dev/blocks/forms/dest
/home/tcurdt/dev/cocoon-trunk/src/blocks/forms/java/org/apache/cocoon/forms/util/SimpleServiceSelector.java:81: 
cannot resolve symbol
symbol  : variable LifecycleHelper
location: class org.apache.cocoon.forms.util.SimpleServiceSelector
LifecycleHelper.setupComponent(
^
/home/tcurdt/dev/cocoon-trunk/src/blocks/forms/java/org/apache/cocoon/forms/acting/HandleFormSubmitAction.java:74: 
cannot resolve symbol
symbol  : variable LifecycleHelper
location: class org.apache.cocoon.forms.acting.HandleFormSubmitAction
LifecycleHelper.setupComponent(formHandler, null, null, 
manager, null);
^
/home/tcurdt/dev/cocoon-trunk/src/blocks/forms/java/org/apache/cocoon/forms/binding/JXPathBindingManager.java:84: 
cannot resolve symbol
symbol  : variable LifecycleHelper
location: class org.apache.cocoon.forms.binding.JXPathBindingManager
LifecycleHelper.setupComponent(bindingBuilderSelector,
^
/home/tcurdt/dev/cocoon-trunk/src/blocks/forms/java/org/apache/cocoon/forms/datatype/JavaSelectionListBuilder.java:55: 
cannot resolve symbol
symbol  : variable LifecycleHelper
location: class org.apache.cocoon.forms.datatype.JavaSelectionListBuilder
LifecycleHelper.setupComponent(list, 
getLogger(), null,
^
4 errors
--8<--

find -name LifecycleHelper.java
revealed imports were missing
Then I got this
--8<--
cocoon-block-eventcache-compile:
Compiling 17 source files to 
/home/tcurdt/dev/cocoon-trunk/build/cocoon-2.2.0-dev/blocks/eventcache/dest
/home/tcurdt/dev/cocoon-trunk/src/blocks/eventcache/java/org/apache/cocoon/caching/impl/JMSEventMessageListener.java:53: 
cannot resolve symbol
symbol  : class AbstractMessageListener
location: class org.apache.cocoon.caching.impl.JMSEventMessageListener
public class JMSEventMessageListener extends AbstractMessageListener 
implements ThreadSafe {
 ^
/home/tcurdt/dev/cocoon-trunk/src/blocks/eventcache/java/org/apache/cocoon/caching/impl/JMSEventMessageListener.java:71: 
cannot resolve symbol
symbol  : variable super
location: class org.apache.cocoon.caching.impl.JMSEventMessageListener
super.parameterize(parameters);
^
/home/tcurdt/dev/cocoon-trunk/src/blocks/eventcache/java/org/apache/cocoon/caching/impl/JMSEventMessageListener.java:76: 
cannot resolve symbol
symbol  : variable super
location: class org.apache.cocoon.caching.impl.JMSEventMessageListener
super.initialize();
^
/home/tcurdt/dev/cocoon-trunk/src/blocks/eventcache/java/org/apache/cocoon/caching/impl/JMSEventMessageListener.java:77: 
cannot resolve symbol
symbol  : variable m_manager
location: class org.apache.cocoon.caching.impl.JMSEventMessageListener
m_eventCache = (EventAware) m_manager.lookup(m_eventAwareRole);
^
/home/tcurdt/dev/cocoon-trunk/src/blocks/eventcache/java/org/apache/cocoon/caching/impl/JMSEventMessageListener.java:81: 
cannot resolve symbol
symbol  : variable super
location: class org.apache.cocoon.caching.impl.JMSEventMessageListener
super.dispose();
^
/home/tcurdt/dev/cocoon-trunk/src/blocks/eventcache/java/org/apache/cocoon/caching/impl/JMSEventMessageListener.java:82: 
cannot resolve symbol
symbol  : variable m_manager
location: class org.apache.cocoon.caching.impl.JMSEventMessageListener
this.m_manager.release(m_eventCache);
^
/home/tcurdt/dev/cocoon-trunk/src/blocks/eventcache/java/org/apache/cocoon/caching/impl/JMSEventMessageListener.java:89: 
cannot resolve symbol
symbol  : method getLogger ()
location: class org.apache.cocoon.caching.impl.JMSEventMessageListener
if (getLogger().isDebugEnabled()) {
^
/home/tcurdt/dev/cocoon-trunk/src/blocks/eventcache/java/org/apache/cocoon/caching/impl/JMSEventMessageListener.java:90: 
cannot resolve symbol
symbol  : method getLogger ()
location: class org.apache.cocoon.caching.impl.JMSEventMessageListener
getLogger().debug("Receiving message: " + message);
^
/home/tcurdt/dev/cocoon-trunk/src/blocks/eventcache/java/org/apache/cocoon/caching/impl/JMSEventMessageListener.java:94: 
cannot resolve symbol
symbol  : method getLogger ()
location: class org.apache.cocoon.caching.impl.JMSEventMessageListener
if (getLogger().isDebugEnabled()) {
^
/home/tcurdt/dev/cocoon-trunk/src/blocks/eventcache/java/org/apache/cocoon/caching/impl/JMSEventMessageListener.java:95: 
cannot resolve symbol
symbol  : method getLogger ()
location: class org.apache.cocoon.caching.impl.JMSEventMessageListener
getLogger().debug("Notifying " + m_eventAwareRole + " 
of " + events[i]);
^
10 errors

Re: Persisting SimpleLuceneQuery [Long]

[Jeremy Quinn]

On 2 Nov 2004, at 21:45, Antonio Gallardo wrote:
Hi Jeremy:
I was suddenly busy again. Sorry for that.
Please do not apologise !!! :)
But, I don't forgot about this mail. In the last weekend, I tried to 
see
at the Lucene sample, but it was not working. :-(

Fortunately, Sylvain fixed the small bug. Now it working again! I will
update OJB to 1.0.1 and then we will be ready to start this "game". OK?
;-)
I will try to get a new Block working, to put it in.
Many thanks
regards Jeremy

  If email from this address is not signed
IT IS NOT FROM ME
Always check the label, folks !



smime.p7s
Description: S/MIME cryptographic signature

Re: [lazyweb] SVN checkout without keyword expansion?

[Giacomo Pati]

On Wed, 3 Nov 2004, Sylvain Wallez wrote:
Hi all,
A lazyweb question about SVN: is there a way to perform a checkout without 
expanding the $Id$ keyword? I couldn't find one by googling around, and that 
would be so useful for merging branches where many files only differ by their 
revision number.

Currently I used a quickly hacked script that does the job, but that would be 
much cleaner to have it handled directly by svn.
I usually compare different branches by use of the following 
gnu diff command in a script:

diff -rubBd -x CVS -x target -x .svn -x .cvsignore -x .settings \
-x .project \
--ignore-matching-lines=\\\$Author: \
--ignore-matching-lines=\\\$Date: \
--ignore-matching-lines=\\\$Header: \
--ignore-matching-lines=\\\$Id: \
--ignore-matching-lines=\\\$Locker: \
--ignore-matching-lines=\\\$Name: \
--ignore-matching-lines=\\\$RCSfile: \
--ignore-matching-lines=\\\$Revision: \
--ignore-matching-lines=\\\$Source: \
--ignore-matching-lines=\\\$State: \
--ignore-matching-lines=\\\$Version: $* $TARGET $SOURCE
It is suitable for CVS as well as for SVN. Hope this helps.
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

Re: latest Moin

[Upayavira]

Reinhard Poetz wrote:
Upayavira wrote:
Reinhard Poetz wrote:
Is the content of the right-side bar customizable so that we get our 
former menu back?

What you mean you want a customisable right side bar? Not just a 
right side bar? Fussy eh? ;-)

More seriously, I believe there is a way to configure the options, 
somewhere behind the scenes, but not via the wiki interface.
Not sure if we speak of the same. What I want is the content of 
http://wiki.apache.org/cocoon/SiteNavigation in the menu. Without a 
menu that leads to all pages I have the sense of a big mess.
I'm afraid it doesn't offer that. We can add our own options to the 
side-bar, but it won't be an editable wiki page. If we can come up with 
a small number of relatively permanant links, we should be able to put 
them on it.

What it does do is make the normal wiki navigation stuff easier to find 
(search, etc).

Regards, Upayavira

Re: [GUMP@brutus]: Project cocoon-block-proxy (in module cocoon) failed

[Antonio Gallardo]

Stefano Mazzocchi dijo:
> Antonio Gallardo wrote:
>
>> Stefano Mazzocchi dijo:
>>
>>>Antonio Gallardo wrote:
>>>
>>>
Stefano Mazzocchi dijo:


>Gump wrote:
>
>
>
>>cocoon-block-proxy-compile:
>>   [javac] Compiling 4 source files to
>>/home/gump/workspaces2/public/workspace/cocoon/build/cocoon-02112004/blocks/proxy/dest
>>   [javac]
>>/home/gump/workspaces2/public/workspace/cocoon/src/blocks/proxy/java/org/apache/cocoon/generation/HttpProxyGenerator.java:294:
>>cannot resolve symbol
>>   [javac] symbol  : method getRequestBodyAsString ()
>>   [javac] location: class
>>org.apache.commons.httpclient.methods.PostMethod
>>   [javac] String body = ((PostMethod)
>>this.method).getRequestBodyAsString();
>>   [javac]   ^
>>   [javac] 1 error
>
>I don't know how to fix this one from the gump side, it needs some
> code
>changes since httpclient change a lot since this code was created.
>
>Any ideas?


I saw the code of httpclient 2.0.x and 3.0 and it is quite diferent.
They
are changing a lot in the new 3.0.x release. If we want gump compile
this
block, we need to add a dependency to our own distributed jar version
2.0.2.

I know this is a hack. The other way is to see more in depth and find a
way to compile code using both httpclient 2.0.2 and 3.0 too.

WDYT?
>>>
>>>That build is against the 2.0.x branch.
>>
>>
>> Its posible in the CVS version.
>>
>> In the javadocs for release 2.0.2, the PostMethod. Because is direct
>> derived from EntityEnclosingMethod:
>>
>> http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/methods/PostMethod.html
>>
>> Now go to the CVS. in the HTTPCLIENT_2_0_BRANCH We still see the
>> method getRequestBodyAsString() inside:
>>
>> http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/EntityEnclosingMethod.java?rev=1.18.2.5&only_with_tag=HTTPCLIENT_2_0_BRANCH&view=markup
>>
>> ...
>>
>> I am not a CVS guru, but in the HEAD (3.0 release) there is not the
>> method.
>>
>> Seems like they broke a contract? I mean removing a method without
>> deprecate it first?
>
> yeah, they did, but what I don't  understand is why we didn't build
> against HTTPCLIENT_2_0_BRANCH.

I think we are not using the HTTPCLIENT_2_0_BRANCH. See:

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/PostMethod.java?only_with_tag=HTTPCLIENT_2_0_BRANCH&view=markup

And in the EntityEnclisingMethod:

http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/EntityEnclosingMethod.java?rev=1.18.2.5&only_with_tag=HTTPCLIENT_2_0_BRANCH&view=auto

Is gump using the right branch?

Best Regards,

Antonio Gallardo

Re: trunk does not compile

[Antonio Gallardo]

Torsten Curdt dijo:
> Carsten Ziegeler wrote:
>> Works for me :) Are you using the build script? If you're using an IDE
>> you have to add the src/core directory as a source directory
>> (build eclipse-project does this for you).
>
> hm... did a
>
>   sh build.sh clean
>   sh build.sh
>
> do you have all blocks enabled?

Yep. It is working for me too. Can you post the error message you got?

>
> *puzzled*

Don't worry, be happy! ;-)

Best Regards,

Antonio Gallardo

Re: Entity replacement

[Torsten Curdt]

Rokibul Islam Khan wrote:
Hi,
I m trying to output a string which contain a xml node through xsp 
(xsp:expr) .

 

Im using the following code for doing this :
 


String xml = ”hello”;

 

xml
 

 

In cocoon pipeline I set a xslt which output me the html. But the 
problem is xslt failed to transform the entity.

Can u give me any idea that how I can replace the entity from the xsp or 
any way by which I can put actual tag hello from a java string 
directly ?
..if you want to feed this XML string into the pipeline
you have to emit SAX events. Either do that by hand
or use a parser for that.
There are dedicated logicsheet tags for doing this.
Please see the documentation or ask at the users list.
HTH
--
Torsten

RE: trunk does not compile

[Carsten Ziegeler]

Can you append the messages from the build?

Carsten 

> -Original Message-
> From: Torsten Curdt [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 03, 2004 10:08 AM
> To: [EMAIL PROTECTED]
> Subject: Re: trunk does not compile
> 
> Carsten Ziegeler wrote:
> > Works for me :) Are you using the build script? If you're 
> using an IDE 
> > you have to add the src/core directory as a source directory (build 
> > eclipse-project does this for you).
> 
> hm... did a
> 
>   sh build.sh clean
>   sh build.sh
> 
> do you have all blocks enabled?
> 
> *puzzled*
> --
> Torsten
> 

Re: trunk does not compile

[Torsten Curdt]

Carsten Ziegeler wrote:
Works for me :) Are you using the build script? If you're using an IDE
you have to add the src/core directory as a source directory 
(build eclipse-project does this for you).
hm... did a
 sh build.sh clean
 sh build.sh
do you have all blocks enabled?
*puzzled*
--
Torsten

Entity replacement

[Rokibul Islam Khan]

Hi,

I m trying to output a string which contain a xml node
through xsp (xsp:expr) . 

 

Im using the following code for doing this :

 



String xml =
”hello”;



 

xml

 

 

In cocoon pipeline I set a xslt which output me the html.
But the problem is xslt failed to transform the entity. 

Can u give me any idea that how I can replace the entity
from the xsp or any way by which I can put actual tag hello
from a java string directly ?

 

Thanx in advance

 

rokib

Re: trunk does not compile

[Reinhard Poetz]

Torsten Curdt wrote:
...at least for me the "LifecyleHelper" is missing.
Carsten, I assume that's related to the ECM++ stuff.
Does a clean build work for you?
Ant build works for me, haven't tried it with Eclipse for some time.
Do your classes in src/core get compiled?
--
Reinhard

RE: trunk does not compile

[Carsten Ziegeler]

Works for me :) Are you using the build script? If you're using an IDE
you have to add the src/core directory as a source directory 
(build eclipse-project does this for you).

HTH
Carsten

> -Original Message-
> From: Torsten Curdt [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 03, 2004 9:26 AM
> To: Cocoon DEV List
> Subject: trunk does not compile
> 
> ...at least for me the "LifecyleHelper" is missing.
> Carsten, I assume that's related to the ECM++ stuff.
> Does a clean build work for you?
> 
> cheers
> --
> Torsten
> 

trunk does not compile

[Torsten Curdt]

...at least for me the "LifecyleHelper" is missing.
Carsten, I assume that's related to the ECM++ stuff.
Does a clean build work for you?
cheers
--
Torsten

DO NOT REPLY [Bug 31649] - [Patch] Flowscript: Switch to re-implementation of official Rhino

[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=31649

[Patch] Flowscript: Switch to re-implementation of official Rhino

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-11-03 08:16 ---
Thank you. As I checked out rhino yesterday, your change should be part of the
library used in trunk. 

For now I close this issue there aren't any known problems. 

Detailed information on the (small) changes can be found at
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109528520325331&w=2

Adding rhino-1.6 to branch-21 is another issue, see 32036

[lazyweb] SVN checkout without keyword expansion?

[Sylvain Wallez]

Hi all,
A lazyweb question about SVN: is there a way to perform a checkout 
without expanding the $Id$ keyword? I couldn't find one by googling 
around, and that would be so useful for merging branches where many 
files only differ by their revision number.

Currently I used a quickly hacked script that does the job, but that 
would be much cleaner to have it handled directly by svn.

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

DO NOT REPLY [Bug 32036] New: - Use rhino-1.6 in 2.1

[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=32036

Use rhino-1.6 in 2.1

   Summary: Use rhino-1.6 in 2.1
   Product: Cocoon 2
   Version: Current SVN 2.1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Flowscript
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Integrating rhino-1.6 in 2.1 is planned after 2.1.6 has been released. This
gives us more time to test it. See discussion at
http://marc.theaimsgroup.com/?t=10993338336&r=1&w=2

See also issue 31649 to get further information on the new implementation.

Re: Implementation of the Continuations checker

[Giacomo Pati]

On Wed, 3 Nov 2004, Henrik Gustafsson wrote:
And you will never need to cancel a scheduled command, or?
IIRC Excalibur Event didn't have that as well. A ThreadPool can be 
shutdown, sure. But for more use the cron block.

--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

RE: Templating Engine - Next steps?

[Carsten Ziegeler]

 
Daniel Fagerstrom wrote:
>  
> >
> I have done some work on implementing a Jelly generator. 
> Basically my own versions of the JellyGenerator in scratchpad 
> and your TemplateObjectModelHelper, didn't know the existence 
> of either of them :/
> 
> The most irritating problem that I have found this far is 
> that it uses java.net.URL for uri handling which doesn't work 
> that well together with the Excialibur Sources in Cocoon.
> 
Yepp, that's one problem.

> After some searching I found that you didn't find it suitable 
> for multi threaded environment: 
> http://www.osoco.net/weblogs/rael/archives/000202.html, do 
> you remember what was the problem? Other problems?
> 
I'm not that sure (it's sooo long ago), but I think the template
generated by Jelly is tied to the context - so this means you
have to use your own "compiled template" for each invokation.

HTH
Carsten

Re: CForms: widget states added

[Sylvain Wallez]

Bart Molenkamp wrote:
Does it fix this one?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27598
 

Mmmh... not sure, although you can prevent a widget from reading its 
value from the request by setting it's state do "disabled". This bug is 
more likely to be fixed by having widgets only changing their values 
*if* the corresponding request parameter is present, as proposed by Tim 
in the "[lazy vote] cforms request processing thread".

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