date:20050315

David Crossley wrote:
Bertrand Delacretaz wrote:
How about adding another condition: a block can only have "supported" 
status if we have automated tests for all its critical functions?

This might make a big difference in the accountability of supported 
stuff in our releases.

That is a great idea. Then rather than calling them "supported"
we can call them "tested" or "verified". Much better connotation.

I like the connotation of "verified" as well, but I'm not sure if we should 
reflect this status in our directory system. IMHO the release of a block can be 
verified but I'm not sure if a block in SVN can be verified. Think of a block 
that is verified and then it is refactored or a major enhancement is added. Does 
it still meet all requirements (tested, peer-reviewed, ...) afterwards? Maybe, 
but maybe not. If not, do we move it into another directory, although the last 
release was verified?

--
Reinhard Pötz   Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: [cForms] Errors coming from service layer

Sylvain Wallez wrote:
Reinhard Poetz wrote:
Sylvain Wallez wrote:
Reinhard Poetz wrote:
Vilya Harvey wrote:
Reinhard Pötz wrote:
Imagine following scenario: You have a service layer that is 
exposed as web services. cForms already does as much validation as 
possible but some complex checks can only be performed by the 
backend.

If I call a webservice (via Axis client) this webservice can 
return errors (how this is done hasn't been defined yet).

Are there any best practices or experiences how to map errors 
coming from the service or domain layer to cForms widgets? (The 
error has to appear at widget level.)



In your flowscript, you can create your own ValidationError object 
and explicitly set that on the apppropriate widget.

What we did was to define our own type of exception which included 
information about all validation errors that were found, then wrote 
a simple(-ish) flowscript function which handled looking up the 
relevant widgets, creating the error objects and setting them into 
the widgets.


Thank you!
This means that the service layer is aware of which widgets exist? 
I'm not sure if I (and especially my customer) likes this 
bi-directional dependency...


Nono! Your validation code has to catch the exception and translate 
it into a validation error. This means you can have "regular" 
validation errors (i.e. the backend could be reached but detected 
invalid data) and communication-level errors, e.g. "could not 
validate data, try again later".


let's try to express this using some pseudo-code:
var form = new Form(...);
var businessObject = getBusinessObjectFromServiceLayer();
form.load(businessObject);
form.show(...);
form.save(businessObject);
var errorType;
try {
  saveBusinessObjectInBackend(businessObject);
} catch(ex) {
  errorType = ex.getErrorType();
}
if(errorType == "user.already.exists") {
  form.lookupWidget("user").setValidationError("User already exists!");
}
form.show(...);
Do you mean something like this? The problem with this is that the 
service layer
can return *a lot* of different error types and I would have to write 
dozens of
ifs ... :-(

You should enclose this in a while loop :
var success = false;
while (!success) {
 form.showForm();
 form.save(obj);
 try {
   saveBusinessObjectInBackend(obj);
   success = true;
 } catch(ex) {
   ...
 }
}
Now about the particular exception handling, you can also define a 
higher level system to propagate errors with a data structure that 
associates an error code with a widget name and an error message.

If the validation is separated from the saveInBackend operation, don't 
forget that you can define a  on the form object itself.
thank you guys!
--
Reinhard Pötz   Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: [cforms] Widget states in request-scoped forms

Sylvain Wallez wrote:
Reinhard Poetz wrote:
Sylvain Wallez wrote:
Reinhard Poetz wrote:
Sylvain Wallez wrote:
Another idea I had is, that I could work on making the form object 
serializable and save the state in a hidden form field. The price 
to pay would be increased network traffic but the advantage of a 
stateless presentation layer wouldn't get lost. Hmmm the more I 
think about it the more I like this idea  wdot?


You should have a look at the XMLAdapter class in o.a.c.form.util. 
It does handles form serialization/deserialization in XML. AFAIK it 
doesn't keep state, but this could easily be added.


Thanks for the pointer! This should be very helpful, if I go this way.
Is there anything else that is necessary to _completly_ describe the 
state of a form, except the value and the "visibility state"? 
(events, validation errors, ...?)


Events are inherently transient (i.e. they are produced and consumed 
as part of the processing of a request). Validation errors are part 
of the global state of a form, as non-active widgets will loose their 
value and any validation as they don't read their value on the request.

You also have to include  in your form template so 
that the size of repeaters is transmitted back and forth as a hidden 
input.


ok, so we need following information to describe the state of a form:
 1. widget value
 2. widget visibility state
 3. validation errors
 4. repeater size

Yes, that should be ok.
This means that I would have to enhance XMLAdapter to save this 
information too. Then I would extend the FormsTransformer to add a 
hidden input field that contains the compressed and encrypted XML.

Encrypted? Beware of security through obscurity, which is not a good 
solution, especially when the encryption/decryption code is opensource ;-)
yes, but if the encryption key is customizeable (e.g. in cocoon.xconf) this 
shouldn't be a problem


When the request comes back to the server, the controller checks for 
the hidden field and deserializes it.

By 'controller', do you mean FormSubmitAction?
for example, yes.
--
Reinhard Pötz   Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: Supported and unsupported blocks

Le 15 mars 05, à 23:13, Sylvain Wallez a écrit :
...Yep. But this also means the core is currently unsupported ;-P
Even if there are few direct tests of the core functionality, several 
things are indirectly tested, through anteater and some other tests. We 
might not have a precise idea of the coverage but it's probably not 
that bad.

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

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

2005-03-15 Thread 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 has an issue affecting its community integration.
This issue affects 36 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon :  Java XML Framework
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-poi :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-template :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- forrest :  Apache Forrest is an XML standards-oriented documentation fr...
- forrest-test :  Apache Forrest is an XML standards-oriented documentation 
fr...


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

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon]
 -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: 
[cocoon-testcase]
 -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: 
[cocoon-deprecated]
 -DEBUG- Dependency on avalon-framework-api exists, no need to add for property 
avalonapi.jar.
 -INFO- Made directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-15032005/test]
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/cocoon/build/cocoon-15032005/test/output
 -WARNING- No directory 
[/usr/local/gump/public/workspace/cocoon/build/cocoon-15032005/test/output]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html
Work Name: build_cocoon_cocoon (Type: Build)
Work ended in a state of : Failed
Elapsed: 13 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Davalonapi.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-15032005.jar
 
-Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-15032005.jar
 -Dversion=15032005 gump-core 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-15032005/classes:/usr/local/gump/public/workspace/cocoon/build/cocoon-15032005/deprecated:/usr/local/gump/public/workspace/cocoon/build/cocoon-15032005/test:/usr/local/gump/public/workspace/cocoon/build/cocoon-15032005/mocks:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/tools/loader:/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-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspac

DO NOT REPLY [Bug 34025] - i18n transformer does not work when tags are added via XSL

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=34025


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-03-16 03:37 ---
I think I solved it. Problems always seem obvious in retrospect, don't they?
Everything in the pipeline before the i18n tranformation must be outputting xml
or xhtml. Anything labeled html that is passed to i18n goes all wonky, even if
it looks like well formed xml, the html output value affects how the SAX events
are generated, and i18n won't work. But if I make everything in the pipeline
output xml, and then serialize to html at the very end of the pipeline, after
the i18n transformation, it works.

Bess

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 34025] - i18n transformer does not work when tags are added via XSL

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=34025





--- Additional Comments From [EMAIL PROTECTED]  2005-03-16 02:45 ---
Hi, Helma. Thanks for replying. It is matching the correct node, because the
catch-all node would not print anything out, and the contents of /html/body/div
are being printed. Just to be sure, though, I removed the  code from both xsl files, and I get the same
results. So I don't think that is the problem. Good idea to check that, though.
Thanks!

Bess

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: Supported and unsupported blocks

2005-03-15 Thread David Crossley

Bertrand Delacretaz wrote:
> How about adding another condition: a block can only have "supported" 
> status if we have automated tests for all its critical functions?
> 
> This might make a big difference in the accountability of supported 
> stuff in our releases.

That is a great idea. Then rather than calling them "supported"
we can call them "tested" or "verified". Much better connotation.

--David

RE: CONTRIBUTION: forms-calendar-styling defect when widget disabled

2005-03-15 Thread Linden H van der (MI)

Sylvain,

I think he means that adding "readonly='readonly'" as attribute to his
own  tag is passed through the styling XSL files. IIRC there
is a template that deals with extra attributes in the styling tag.

HTH.

Bye, Helma


> -Original Message-
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, 15 March 2005 23:33
> To: dev@cocoon.apache.org; [EMAIL PROTECTED]
> Subject: Re: CONTRIBUTION: forms-calendar-styling defect when 
> widget disabled
> 
> 
> depub2 wrote:
> 
> >
> > 
> >
> > Well actually, the readonly="readonly" works! Try it!!! 
> And there
> > are some cases where disabled="disabled" is problematic
> > (binding/saving) and I think something else I can't 
> remember right
> > now (pulldown selections? calendar selections? - can't 
> remember).
> > (note {at-symbol} above must be translated to @ - seems that
> > symbol is not allowed on the archives.) 
> >
> >
> >
> > Sorry, but I really don't know what you're talking about. Is this 
> > 'readonly' in the binding? If so, what's the relation with 
> the styling 
> > XSLs??
> >  
> > It is in the template file,  tag. I believe that 
> > readonly="readonly" simply gets passed along as an attribute to the 
> > "input" tag and is valid xhtml which the browser then 
> interprets to be 
> > like disabled="disabled", but slightly different. Here's an 
> example usage:
> >  
> > 
> >cols="75" 
> > wrap="hard"
> >  class="DocOrdersStatusMessage"/>
> > 
> 
> 
> Again, I can't find it. If the forms/samples directory:
> $ find . -type f | xargs grep readonly
> ./forms/binding/01value-bind.xml:   ./forms/binding/01value-def.xml:
> 
> The only "readonly" in the whole CForms samples (which 
> include the XSLs) 
> is the name of a widget.
> 
> Can you please give me the URL of the relevant file under 
> http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/s
rc/blocks/forms/
 

> Anyway, inserting that small code segment in the source (see below) 
> and then playing with the samples to disable the calendar widget will 
> show you what I mean - and try readonly as a styling attribute to see 
> that at work too. Then try disabling the calendar without my 
> modifications and you'll notice that the date can be changed, even 
> though the widget is disabled.


Again and again, there is no such "readonly" attribute. You can set the 
state of a widget to "disabled" which leads to something similar to what

you describe: the input is readonly, and the calendar icon is still 
visible but disabled.

Sylvain

-- 
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director

DO NOT REPLY [Bug 34025] - i18n transformer does not work when tags are added via XSL

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=34025





--- Additional Comments From [EMAIL PROTECTED]  2005-03-16 00:00 ---
(In reply to comment #0)

I haven't tested this but...


> bugtest2.xsl:
>  xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
> xmlns:i18n="http://apache.org/cocoon/i18n/2.1";
> xmlns:dir="http://apache.org/cocoon/directory/2.0"; 
> exclude-result-prefixes="dir">
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Am I missing something? I can reproduce this in many places, but I've tried to
> boil it down to the simplest case I can. Thanks in advance for any advice!

XSL templates match in order of appearance in the file, so I assume your
catch-all template (node()|@*) matches before the correct (/html/body/div) one 
does.

Do report back here if that's the case.

Bye, Helma

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: Supported and unsupported blocks

2005-03-15 Thread Torsten Curdt

>>> ...Where shall we draw the line between "supported" and
>>> "unsupported"? Is it really the "two committers rule" that I applied
>>> above?...
>>
>>
>>
>> How about adding another condition: a block can only have "supported"
>> status if we have automated tests for all its critical functions?
> 
> 
> 
> That's a very interesting point.
> +1, even if I'm not the most productive test writer :-)
>
>> This might make a big difference in the accountability of supported
>> stuff in our releases.
> 
> 
> 
> Yep. But this also means the core is currently unsupported ;-P

Hehe... Well, time to write some test then ;-P

Actually I somehow like the idea of required tests!
And it would also clearly draw the line. Much better
than the two-committer rule.

...but a lot of work :-/

cheers
--
Torsten


signature.asc
Description: OpenPGP digital signature

Re: Supported and unsupported blocks

2005-03-15 Thread Vadim Gritsenko

Sylvain Wallez wrote:
Bertrand Delacretaz wrote:
Le 15 mars 05, à 10:14, Reinhard Poetz a écrit :
...Where shall we draw the line between "supported" and 
"unsupported"? Is it really the "two committers rule" that I applied 
above?...

How about adding another condition: a block can only have "supported" 
status if we have automated tests for all its critical functions?
Presense of the tests is enough, or you want to require that tests must run 
without failures? ;-P


That's a very interesting point.
+1, even if I'm not the most productive test writer :-)
This might make a big difference in the accountability of supported 
stuff in our releases.

Yep. But this also means the core is currently unsupported ;-P
Including all of the blocks, as well.
Vadim

Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled

depub2 wrote:

Well actually, the readonly="readonly" works! Try it!!! And there
are some cases where disabled="disabled" is problematic
(binding/saving) and I think something else I can't remember right
now (pulldown selections? calendar selections? - can't remember).
(note {at-symbol} above must be translated to @ - seems that
symbol is not allowed on the archives.) 


Sorry, but I really don't know what you're talking about. Is this 
'readonly' in the binding? If so, what's the relation with the styling 
XSLs??
 
It is in the template file,  tag. I believe that 
readonly="readonly" simply gets passed along as an attribute to the 
"input" tag and is valid xhtml which the browser then interprets to be 
like disabled="disabled", but slightly different. Here's an example usage:
 

  
 class="DocOrdersStatusMessage"/>


Again, I can't find it. If the forms/samples directory:
$ find . -type f | xargs grep readonly
./forms/binding/01value-bind.xml:  

The only "readonly" in the whole CForms samples (which include the XSLs) 
is the name of a widget.

Can you please give me the URL of the relevant file under 
http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/blocks/forms/


Anyway, inserting that small code segment in the source (see below) 
and then playing with the samples to disable the calendar widget will 
show you what I mean - and try readonly as a styling attribute to see 
that at work too. Then try disabling the calendar without my 
modifications and you'll notice that the date can be changed, even 
though the widget is disabled.

Again and again, there is no such "readonly" attribute. You can set the 
state of a widget to "disabled" which leads to something similar to what 
you describe: the input is readonly, and the calendar icon is still 
visible but disabled.

Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: Supported and unsupported blocks

Bertrand Delacretaz wrote:
Le 15 mars 05, à 10:14, Reinhard Poetz a écrit :
...Where shall we draw the line between "supported" and 
"unsupported"? Is it really the "two committers rule" that I applied 
above?...

How about adding another condition: a block can only have "supported" 
status if we have automated tests for all its critical functions?

That's a very interesting point.
+1, even if I'm not the most productive test writer :-)
This might make a big difference in the accountability of supported 
stuff in our releases.

Yep. But this also means the core is currently unsupported ;-P
Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director

RE: Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled WAS repeater-widget (insert row): InsertRowsActionDefinition

2005-03-15 Thread Linden H van der (MI)

Title: Message

Sounds
like a good idea. Since I'm working on the styling XSL sheets anyway, should I
include this?
Bye,
Helma

-Original Message-From: depub2
[mailto:[EMAIL PROTECTED] Sent: Tuesday, 15 March 2005
19:58To: CocoonDev; [EMAIL PROTECTED]Subject: RE: Re:
CONTRIBUTION: forms-calendar-styling defect when widget disabled WAS
repeater-widget (insert row):
InsertRowsActionDefinition
Well actually, the readonly="readonly" works! Try it!!! And there are
some cases where disabled="disabled" is problematic (binding/saving) and I
think something else I can't remember right now (pulldown selections?
calendar selections? - can't remember). (note {at-symbol} above must be
translated to @ - seems that symbol is not allowed on the archives.)

Sorry, but I really don't know what you're talking about. Is this
'readonly' in the binding? If so, what's the relation with the styling
XSLs??
It is in the template file,
tag. I believe that readonly="readonly" simply gets passed
along as an attribute to the "input" tag and is valid xhtml which the browser
then interprets to be like disabled="disabled", but slightly different. Here's
an example usage:
class="DocOrdersStatusMessage"/>
Anyway, inserting that small code
segment in the source (see below) and then playing with the samples to disable
the calendar widget will show you what I mean - and try readonly as a styling
attribute to see that at work too. Then try disabling the calendar without my
modifications and you'll notice that the date can be changed, even though the
widget is disabled.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Also, I have a "2 line" minor tweak to the forms-calendar-styling.xsl that
disables the "calendar icon/popup" when a datetype="date" widget is set to
readonly, disabled, or hidden (in these cases, we don't want an icon or
popup - ESPECIALLY when the widget is supposed to be "hidden").The change was simple, in
cocoon/samples/blocks/forms/resources/forms-calendar-styling.xslI added:

around the calendar HTML anchor.The modified code segment in that file now reads:

All that I added was the surrounding block. It works great!!Should I move this to a separate CONTRIBUTION thread or is this simpleenough that you would just get it into the cvs archive??

Re: Supported and unsupported blocks

Le 15 mars 05, à 10:14, Reinhard Poetz a écrit :
...Where shall we draw the line between "supported" and "unsupported"? 
Is it really the "two committers rule" that I applied above?...
How about adding another condition: a block can only have "supported" 
status if we have automated tests for all its critical functions?

This might make a big difference in the accountability of supported 
stuff in our releases.

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

DO NOT REPLY [Bug 34025] New: - i18n transformer does not work when tags are added via XSL

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=34025

   Summary: i18n transformer does not work when  tags are
added via XSL
   Product: Cocoon 2
   Version: Current SVN 2.2
  Platform: Macintosh
OS/Version: Mac OS X 10.3
Status: NEW
  Severity: normal
  Priority: P2
 Component: blocks
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


I have reproduced this in both Cocoon 2.1.5 and 2.2.0-dev. If  tags
are included in the initial file of a pipeline, the i18n transformer works
great. But if they are added via an XSL transformation, the i18n transfomer no
longer works. In this case, when the  tags are added via an XSL
transform, the logs are recording unbalanced SAX events, and the end output is
not well formed XML. I can reproduce this behavior with  and
 tags. Passing i18n attributes works fine.

An example of the unbalanced SAX events are that when the i18nTransformer is
processing the  elements, the SAX events look like this in the log:

[startElement] uri=,local=i18n:text,raw=i18n:text
[characters] MPT
[endElement] uri=http://apache.org/cocoon/i18n/2.1,local=text,raw=i18n:text

I'm not a SAX expert, but all the other SAX events in my log have the same thing
for startElement and endElement. Further, when it outputs, it looks like this:
MPT
This is not well-formed XML. The i18nTransformer has removed the second
 tag, but not the first, and of course it hasn't translated anything
either.

Here is a test case, so you can reproduce this:

The pipelines:




































Files:

simple.xml:

http://apache.org/cocoon/i18n/2.1";>

  
titletext
  



  MPT

  


simple2.xml

http://apache.org/cocoon/i18n/2.1";>

  
titletext
  



  MPT

  


bugtest.xsl:

http://www.w3.org/1999/XSL/Transform";
xmlns:i18n="http://apache.org/cocoon/i18n/2.1";
xmlns:dir="http://apache.org/cocoon/directory/2.0"; 
exclude-result-prefixes="dir">
























bugtest2.xsl:
http://www.w3.org/1999/XSL/Transform";
xmlns:i18n="http://apache.org/cocoon/i18n/2.1";
xmlns:dir="http://apache.org/cocoon/directory/2.0"; 
exclude-result-prefixes="dir">

























Am I missing something? I can reproduce this in many places, but I've tried to
boil it down to the simplest case I can. Thanks in advance for any advice!

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: Supported and unsupported blocks

Le 15 mars 05, à 18:39, Sylvain Wallez a écrit :
...But the word "unsupported" conveys IMO a negative meaning that may 
not be adequate
How about "contributed" instead? It's much more positive: a 
contribution is something that we appreciate, even though we might not 
be able to fully support it ourselves.

We could then have:
-supported blocks: essential to many Cocoon applications, fully 
supported and tested

-samples blocks: example blocks, mini-apps, fully supported and tested
-contributed blocks: not officially supported, might not even work as 
distributed, one-man shows, experimental stuff, etc.

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: iText.dtd place http://itext.sourceforge.net/itext.dtd

Le 15 mars 05, à 20:54, Antonio Gallardo a écrit :
...I found iText.dtd being hosted at sourceforge iText project:
http://itext.sourceforge.net/itext.dtd
Hi Antonio, thanks - but I think I'll leave it switched off for now, it 
doesn't bring much and could break from time to time..

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

iText.dtd place http://itext.sourceforge.net/itext.dtd

2005-03-15 Thread Antonio Gallardo

Hi Bertrand:

I found iText.dtd being hosted at sourceforge iText project:

http://itext.sourceforge.net/itext.dtd

Hope this helps. ;-)

Best Regards,

Antonio Gallardo.

RE: Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled WAS repeater-widget (insert row): InsertRowsActionDefinition

2005-03-15 Thread depub2

Well actually, the readonly="readonly" works! Try it!!! And there are
some cases where disabled="disabled" is problematic (binding/saving) and I
think something else I can't remember right now (pulldown selections? calendar
selections? - can't remember). (note {at-symbol} above must be translated to @
- seems that symbol is not allowed on the archives.)
Sorry,
but I really don't know what you're talking about. Is this 'readonly' in the
binding? If so, what's the relation with the styling XSLs??
It is in the template file,
tag. I believe that readonly="readonly" simply gets passed
along as an attribute to the "input" tag and is valid xhtml which the browser
then interprets to be like disabled="disabled", but slightly different. Here's
an example usage:
class="DocOrdersStatusMessage"/>
Anyway, inserting that small code
segment in the source (see below) and then playing with the samples to disable
the calendar widget will show you what I mean - and try readonly as a styling
attribute to see that at work too. Then try disabling the calendar without my
modifications and you'll notice that the date can be changed, even though the
widget is disabled.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Also, I have a "2 line" minor tweak to the forms-calendar-styling.xsl that
disables the "calendar icon/popup" when a datetype="date" widget is set to
readonly, disabled, or hidden (in these cases, we don't want an icon or
popup - ESPECIALLY when the widget is supposed to be "hidden").The change was simple, in
cocoon/samples/blocks/forms/resources/forms-calendar-styling.xslI added:

around the calendar HTML anchor.The modified code segment in that file now reads:

All that I added was the surrounding block. It works great!!Should I move this to a separate CONTRIBUTION thread or is this simpleenough that you would just get it into the cvs archive??

Re: Supported and unsupported blocks

2005-03-15 Thread Torsten Curdt

>>>The following blocks either have only one committer who supports them
>>>or they aren't supported by an active committer at all.
>>>
>>>javaflow
>>>
>>
>>It seems weird that noone has put their name by javaflow.  Am I the only
>>one using it?
> 
> 
> :-D
> 
> I hope Torsten Curdt and the "Australian connection" will support it. ;-)

Ups! I have missed this poll as well.
Sure there is some stuff I am going to
support :)

cheers
--
Torsten


signature.asc
Description: OpenPGP digital signature

Re: Supported and unsupported blocks

Reinhard Poetz wrote:
Where shall we draw the line between "supported" and "unsupported"? Is 
it really the "two committers rule" that I applied above?

Another thought: maybe we should add another "state" called "sample". 
"tour" and "petstore" could be "sample" blocks,  as well as a future 
block that contains all samples.

Yes. And as stated by Jeremy, samples could also include "mini-apps".
But the word "unsupported" conveys IMO a negative meaning that may not 
be adequate. Some blocks have no attached names but contain 
straightforward code (or even no code at all like the STX block!). And 
although their initial developers may have left, acquiring the knowledge 
of how these blocks work may not be that complicated.

So what we should do is have a closer look at those blocks we may be 
interested in, and indicate if we consider them to be end-of-life or 
dead-end of if we believe they could attract interest and people again 
if we promote them a bit.

For this purpose, I suggest to add name in parenthesis to blocks we 
believe in even if we don't have an intimate knowledge of their code.

Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: Supported and unsupported blocks

2005-03-15 Thread Jeremy Quinn

On 15 Mar 2005, at 09:14, Reinhard Poetz wrote:
Where shall we draw the line between "supported" and "unsupported"? Is 
it really the "two committers rule" that I applied above?
Don't get me wrong, I am happy you are being pro-active about this.
However, I see several items on the "unsupported" list which are IMHO 
important components of Cocoon, or are blocks that I use regularly in 
my work. eg. chaperon, jms, naming, repository, webdav, xmldb (and 
others). In most cases, the fact that they do not currently have >2 
supporters does not effect their quality and usefulness.

On reviewing this list again, I see several blocks that I have worked 
on that I probably should have put my name to, and I notice several 
blocks that I know people actively care about, that they have not put 
their name to.

Maybe I misunderstand the purpose of having "supported" and 
"unsupported" blocks, but I would hate to useful work being sidelined 
by not attracting usage or new contributions.

Another thought: maybe we should add another "state" called "sample". 
"tour" and "petstore" could be "sample" blocks,  as well as a future 
block that contains all samples.
It is possible that querybean is a candidate for the sample block. My 
aim for it is that it will become a really simple way to plug searching 
into any project. Something I raised before, was that I think we will 
see more and more reusable "mini-apps" built with Cocoon and these may 
require a new classification.

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: Supported and unsupported blocks

2005-03-15 Thread Antonio Gallardo

On Mar, 15 de Marzo de 2005, 9:50, Ralph Goers dijo:
> Reinhard Poetz wrote:
>
>>
>> The following blocks either have only one committer who supports them
>> or they aren't supported by an active committer at all.
>>
>> javaflow
>>
> It seems weird that noone has put their name by javaflow.  Am I the only
> one using it?

:-D

I hope Torsten Curdt and the "Australian connection" will support it. ;-)

Best Regards,

Antonio Gallardo

Re: Supported and unsupported blocks

2005-03-15 Thread Ralph Goers

Reinhard Poetz wrote: 

The following blocks either have only one committer who supports them 
or they aren't supported by an active committer at all.

javaflow   

It seems weird that noone has put their name by javaflow.  Am I the only 
one using it?

Ralph

Re: Supported and unsupported blocks

2005-03-15 Thread Antonio Gallardo

On Mar, 15 de Marzo de 2005, 8:36, Ralph Goers dijo:
> Reinhard Poetz wrote:
>> These blocks have at least two committers that support them. I added
>> "portal" as I know that there are many users out there (regular bug
>> fixes via bugzilla) and Ralph hasn't added his name for some reason
>> (although he works regualarly on fixing bugs and applying patches.)
>>
> Sorry, I must have been asleep. Actually, I've been overloaded with
> stuff the past month or so.  Where do I add my name to the portal block?

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

Best Regards,

Antonio

Re: Supported and unsupported blocks

2005-03-15 Thread Ralph Goers

Reinhard Poetz wrote:

These blocks have at least two committers that support them. I added 
"portal" as I know that there are many users out there (regular bug 
fixes via bugzilla) and Ralph hasn't added his name for some reason 
(although he works regualarly on fixing bugs and applying patches.)

Sorry, I must have been asleep. Actually, I've been overloaded with 
stuff the past month or so.  Where do I add my name to the portal block?

Ralph

Re: [VOTE] Internal Pipelines Error Handling

2005-03-15 Thread Vadim Gritsenko

Sylvain Wallez wrote:
Yep. And that shows that it's really a feature of  and 
not of .
Ok, deal! :-) Patch landed in SVN, includes samples - take a look...
Vadim

Re: [cforms] Widget states in request-scoped forms

Reinhard Poetz wrote:
Sylvain Wallez wrote:
Reinhard Poetz wrote:
Sylvain Wallez wrote:
Another idea I had is, that I could work on making the form object 
serializable and save the state in a hidden form field. The price 
to pay would be increased network traffic but the advantage of a 
stateless presentation layer wouldn't get lost. Hmmm the more I 
think about it the more I like this idea  wdot?


You should have a look at the XMLAdapter class in o.a.c.form.util. 
It does handles form serialization/deserialization in XML. AFAIK it 
doesn't keep state, but this could easily be added.


Thanks for the pointer! This should be very helpful, if I go this way.
Is there anything else that is necessary to _completly_ describe the 
state of a form, except the value and the "visibility state"? 
(events, validation errors, ...?)


Events are inherently transient (i.e. they are produced and consumed 
as part of the processing of a request). Validation errors are part 
of the global state of a form, as non-active widgets will loose their 
value and any validation as they don't read their value on the request.

You also have to include  in your form template so 
that the size of repeaters is transmitted back and forth as a hidden 
input.

ok, so we need following information to describe the state of a form:
 1. widget value
 2. widget visibility state
 3. validation errors
 4. repeater size

Yes, that should be ok.
This means that I would have to enhance XMLAdapter to save this 
information too. Then I would extend the FormsTransformer to add a 
hidden input field that contains the compressed and encrypted XML.

Encrypted? Beware of security through obscurity, which is not a good 
solution, especially when the encryption/decryption code is opensource ;-)

When the request comes back to the server, the controller checks for 
the hidden field and deserializes it.

By 'controller', do you mean FormSubmitAction?
Does this sound reasonable?

Absolutely!
Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: [cforms] Widget states in request-scoped forms

Tim Larson wrote:
On Mon, Mar 14, 2005 at 09:44:44PM +0100, Reinhard Poetz wrote:
 

Today I've tried to run a form that uses the widget state "INVISIBLE" and 
when the form state is saved in the request. (my experiments are based on 
the form1 action example)

If I use the event framework to change the state from ACTIVE to INVISIBLE, 
toggling works, but the value of the changed widget gets lost.

Looking at the samples I can't figure out ...
- How can a widget have the state "INVISIBLE"? Where is this information 
stored, or better from where is it read?

- If I'm right and the described behavior (losing the values of INVISIBLE 
widgets) is a bug, how can it be fixed? Any ideas?
   

I do not know if it is the same bug or not, but I re-encountered the bug
that made me temporarily change fireEvents to be public so it could be
called from flowscript (iirc it was reverted when I forgot how to trigger
the bug.)
That's me who reverted this as I did not understood the need for making 
it public.

The bug is that the firing of events sometimes get delayed
until after showForm returns, causing very strange behavior.  Sorry I
have not had time yet to track down the source of the problem.
 

Ok. Let's wait until 2.1.7 is out and we will then add some code to 
check if there are some buffered when there normally should be none, and 
throw an exception in that case. That should quickly show where the 
problem is :-)

Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: [cforms] Widget states in request-scoped forms

Sylvain Wallez wrote:
Reinhard Poetz wrote:
Sylvain Wallez wrote:
Another idea I had is, that I could work on making the form object 
serializable and save the state in a hidden form field. The price to 
pay would be increased network traffic but the advantage of a 
stateless presentation layer wouldn't get lost. Hmmm the more I 
think about it the more I like this idea  wdot?

You should have a look at the XMLAdapter class in o.a.c.form.util. It 
does handles form serialization/deserialization in XML. AFAIK it 
doesn't keep state, but this could easily be added.

Thanks for the pointer! This should be very helpful, if I go this way.
Is there anything else that is necessary to _completly_ describe the 
state of a form, except the value and the "visibility state"? (events, 
validation errors, ...?)

Events are inherently transient (i.e. they are produced and consumed as 
part of the processing of a request). Validation errors are part of the 
global state of a form, as non-active widgets will loose their value and 
any validation as they don't read their value on the request.

You also have to include  in your form template so 
that the size of repeaters is transmitted back and forth as a hidden input.

ok, so we need following information to describe the state of a form:
 1. widget value
 2. widget visibility state
 3. validation errors
 4. repeater size
This means that I would have to enhance XMLAdapter to save this information too. 
Then I would extend the FormsTransformer to add a hidden input field that 
contains the compressed and encrypted XML.

When the request comes back to the server, the controller checks for the hidden 
field and deserializes it.

Does this sound reasonable?
--
Reinhard Pötz   Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: [cforms] Widget states in request-scoped forms

Reinhard Poetz wrote:
Sylvain Wallez wrote:
Another idea I had is, that I could work on making the form object 
serializable and save the state in a hidden form field. The price to 
pay would be increased network traffic but the advantage of a 
stateless presentation layer wouldn't get lost. Hmmm the more I 
think about it the more I like this idea  wdot?

You should have a look at the XMLAdapter class in o.a.c.form.util. It 
does handles form serialization/deserialization in XML. AFAIK it 
doesn't keep state, but this could easily be added.

Thanks for the pointer! This should be very helpful, if I go this way.
Is there anything else that is necessary to _completly_ describe the 
state of a form, except the value and the "visibility state"? (events, 
validation errors, ...?)

Events are inherently transient (i.e. they are produced and consumed as 
part of the processing of a request). Validation errors are part of the 
global state of a form, as non-active widgets will loose their value and 
any validation as they don't read their value on the request.

You also have to include  in your form template so 
that the size of repeaters is transmitted back and forth as a hidden input.

Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: [cForms] Errors coming from service layer

2005-03-15 Thread Vilya Harvey

Reinhard Poetz wrote:
Thank you!
This means that the service layer is aware of which widgets exist? I'm 
not sure if I (and especially my customer) likes this bi-directional 
dependency ...
I agree it's a bad idea for the service layer to know about the widgets. 
In our case there's a fairly simple correspondence between error types 
and widgets, so we're able to infer it all in the UI layer. For more 
complicated cases I could imagine using some kind of mapping, along the 
same sort of lines as the form bindings. I haven't tried that out, so I 
don't know how well it would work in practice.

BTW, the code to set a validation error on a widget looks like:
var myWidget = form.lookupWidget("...");
var myError = new 
Packages.org.apache.cocoon.forms.validation.ValidationError(myErrorMessage);
myWidget.setValidationError(myError);

(hope that doesn't get word-wrapped...)
Vil.

DO NOT REPLY [Bug 34015] - Cforms greek messages

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=34015





--- Additional Comments From [EMAIL PROTECTED]  2005-03-15 13:41 ---
helma 

yes "el" is official 

some times it appeared as "el_GR" but for this case (cocoon forms messages)
"el" is just enough

stavros

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 34015] - Cforms greek messages

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=34015


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED




--- Additional Comments From [EMAIL PROTECTED]  2005-03-15 13:36 ---
(In reply to comment #0)
> see attachment messages_el.zip

> the last one xml is not needed as is but contains some more messages  plus the
> greek word for "Calendar" as requested by Helma at
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111064656900943&w=2

THANKS! I'll incorporate them in my set.

BTW is "el" the official name for Greek? I was under the impression it was 'gr'.

Helma

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

RE: CForms samples for 2.1.7 - i18n question - errors SOLVEDexcept for one

2005-03-15 Thread Linden H van der (MI)

> 
> Talking about users too lazy to read the docs :-) 
> http://cocoon.apache.org/2.1/userdocs/transformers/i18n-transf
ormer.html#Attributes

Umph, I read this page about a dozen times, even when I was looking for
the answer to this problem, but somehow I either missed it or it didn't
click. :-(

Bye, Helma

DO NOT REPLY [Bug 32491] - POST method in cinclude:includexml is broken

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=32491


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




--- Additional Comments From [EMAIL PROTECTED]  2005-03-15 13:26 ---
You should not set the bug to FIXED until your patch has been applied to
Cocoon's sources.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: [cforms] Widget states in request-scoped forms

Sylvain Wallez wrote:
Another idea I had is, that I could work on making the form object 
serializable and save the state in a hidden form field. The price to 
pay would be increased network traffic but the advantage of a 
stateless presentation layer wouldn't get lost. Hmmm the more I think 
about it the more I like this idea  wdot?
You should have a look at the XMLAdapter class in o.a.c.form.util. It 
does handles form serialization/deserialization in XML. AFAIK it doesn't 
keep state, but this could easily be added.
Thanks for the pointer! This should be very helpful, if I go this way.
Is there anything else that is necessary to _completly_ describe the state of a 
form, except the value and the "visibility state"? (events, validation errors, ...?)

--
Reinhard Pötz   Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: [cforms] Widget states in request-scoped forms

Reinhard Poetz wrote:
Bruno Dumon wrote:
On Tue, 2005-03-15 at 09:11 +0100, Reinhard Poetz wrote:
if the widget is invisible, there is no request value any more and 
as the form is not saved in the session, the widget loses its value.

Yep, though I'd say that's not a bug but a limitation. If you choose to
work stateless, there are some features you loose (for example, value
changed events won't do anything meaningful either).

In particular the value changed event works for me as long as I don't 
change the widget's state. But you're right, saving the form in the 
request-scope brings some limitations.

Ah ok, I understand now as I missed the fact that you were using 
stateless forms. Yes, in this context there are some strong limitations 
on what you can use.

I try to find these limitations and then I can decide together with my 
customer what we will do.

Yes. We could even add some code in CForms so that a Form knows whether 
it runs in stateful or stateless mode and can then throw meaningful 
exceptions when a statefull feature is used in stateless mode.

Another idea I had is, that I could work on making the form object 
serializable and save the state in a hidden form field. The price to 
pay would be increased network traffic but the advantage of a 
stateless presentation layer wouldn't get lost. Hmmm the more I think 
about it the more I like this idea  wdot?

You should have a look at the XMLAdapter class in o.a.c.form.util. It 
does handles form serialization/deserialization in XML. AFAIK it doesn't 
keep state, but this could easily be added.

Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director

RE: Question on CForms - relevant for 2.1.7 - translations requested

2005-03-15 Thread gounis


hi helma

i have create an entry in bugzilla

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

with the greek version of
FormsMessages.xml, OtherMessages.xml

plus one more .xml (MoreMessages.xml) contain the extra messages you have 
request for

let me know in your need more help

regards

stavros



On Sat, 12 Mar 2005, Linden H van der (MI) wrote:

> THANKS a lot.
> 
> I'm putting some i18n text in to make the localized samples more interesting. 
> It would be great if you could provide a translation of the following in your 
> native language:
> 
>Title
>Mr.
>Ms.
>Mrs.
>Miss.
>First Name
>Surname
>Birthdate (dd/MM/)
>Dead and not born yet should not 
> bother filling this form
>Enter your email address
>An email address must be in [EMAIL 
> PROTECTED] format.
>Remember me
>Address
>Username
>The username must contain exactly 5 
> characters.
>Country
>Password
>Retype Password
> 
> I'm sorry it's not yet complete, but every bit helps.
> 
> Thanks. 
> 
> Bye, Helma
> 
> > -Original Message-
> > From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] 
> > Sent: Saturday, 12 March 2005 15:06
> > To: dev@cocoon.apache.org
> > Subject: Re: Question on CForms - relevant for 2.1.7
> > 
> > 
> > Le 12 mars 05, ΰ 14:52, Linden H van der (MI) a ιcrit :
> > 
> > > ...So at least the styling will remain the same, but are there 
> > > differences (big or small) in the widget definitions etc. 
> > that require 
> > > a rewrite of the current form samples?..
> > 
> > Like you I haven't been able to follow everything.
> > 
> > File comparison, however, shows very few differences, it 
> > seems like the 
> > branch and trunk are well in sync. You might want to look at the 
> > status.xml file in the trunk for more info.
> > 
> > -Bertrand
> > 
>

DO NOT REPLY [Bug 34015] - Cforms greek messages

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=34015





--- Additional Comments From [EMAIL PROTECTED]  2005-03-15 10:21 ---
Created an attachment (id=14490)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=14490&action=view)
zip file with greek translations


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 34015] New: - Cforms greek messages

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=34015

   Summary: Cforms greek messages
   Product: Cocoon 2
   Version: Current SVN 2.1
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: CocoonForms
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


see attachment messages_el.zip

the zip contain 3 .xml files with messages translated in greek language
1. FormsMessages_el.xml 
2. OtherMessages_el.xml
3. MoreMessages_el.xml 

the last one xml is not needed as is but contains some more messages  plus the
greek word for "Calendar" as requested by Helma at
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111064656900943&w=2

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Supported and unsupported blocks

Daniel Fagerstrom wrote:
Reinhard Poetz wrote:

So far, I've moved all blocks from /trunk/src/blocks to 
/blocks/[status]/[name]/trunk and updated the svn:external property on 
/trunk/src/blocks to "re-import" them at their former place. This way 
everything should work as it did before the change. 

Cool! As I promised before you get my hero plate and a beer at the next 
GT for daring to move out the blocks from trunk.

As Daniel and Antonio have already found out, at 
http://wiki.apache.org/cocoon/BlockStatusPoll I set up a page that 
should give us an overview on who is able to support which blocks. 
This should help us to decide on the status we want to give every block.

And extra points for putting about everything under blocks/unsupported 
in SVN. That should give us a well needed kick in the ass for actually 
deciding what Cocoon is.
let's look at the results:
I'd say the following blocks are "supported"
authentication-fw   AG,CZ,  
batik   CZ, VG, SW  
cronRP, CZ, VG, SW, LG  
databases   AG, DF, SW, LG  
deliAG, 
fop AG, CZ, VG, BRD, BD 
forms   RP, AG, DF,CZ, VG, SW, BRD, BD, LG  
hsqldb  RP, VG, 
htmlUV, VG, SW, BD  
lucene  JQ, VG, SW  
ojb AG, JQ, VG, BD
poi AG, BRD 
paranoidRP, SW  
portal  CZ, 
profilerCZ, VG, BRD 
qdoxAG,BD
session-fw  AG,CZ   
templateDF, BRD, LG 
xsp AG, VG, SW
These blocks have at least two committers that support them. I added "portal" as 
I know that there are many users out there (regular bug fixes via bugzilla) and 
Ralph hasn't added his name for some reason (although he works regualarly on 
fixing bugs and applying patches.)

I also added Deli as Antonio and Marc are both working on it and I therefore 
don't consider it as one-man-show.

  - o -
The following blocks either have only one committer who supports them or they 
aren't supported by an active committer at all.

apples  BRD 
asciiart
axis
bsf AG, 
chaperon
eventcache  GH  
faces   VG, 
itext   
javaflow
jforBD  
jms GH  
jsp 
linkrewriterVG, 
mailVG, 
midi
naming  
petstore
proxy   BD  
python  
querybean   JQ, 
repository  
scratchpad  
serializers 
slide   
slopBD  
stx DF, 
taglib  VG, 
tourBD  
velocity
web3
webdav  
xmldb   VG, 
Where shall we draw the line between "supported" and "unsupported"? Is it really 
the "two committers rule" that I applied above?

Another thought: maybe we should add another "state" called "sample". "tour" and 
"petstore" could be "sample" blocks,  as well as a future block that contains 
all samples.

Comments?
--
Reinhard Pötz   Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

RE: CForms samples for 2.1.7 - i18n question - errors SOLVED except for one

2005-03-15 Thread Bruno Dumon

On Mon, 2005-03-14 at 22:16 +0100, Linden H van der (MI) wrote:
> Hi Jeremy,
> 
> > you can specify the catalogue name in i18n attributes like this:
> > 
> > 
> 
> Thanks for replying, I already deducted this from a discussion some
> years ago where Bruno suggested this. Talking about hidden
> docs/features. ;-)

Talking about users too lazy to read the docs :-)
http://cocoon.apache.org/2.1/userdocs/transformers/i18n-transformer.html#Attributes

>  
> > However, the forms catalogue has always been the default 
> > (which IMHO is a nuisance) have you changed this?
> 
> I don't recall changing it, but it now points to "other".
> 
> Bye, Helma
-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [cforms] Widget states in request-scoped forms

Bruno Dumon wrote:
On Tue, 2005-03-15 at 09:11 +0100, Reinhard Poetz wrote:
Sylvain Wallez wrote:
Reinhard Poetz wrote:

Sylvain Wallez wrote:

Reinhard Poetz wrote:

Today I've tried to run a form that uses the widget state 
"INVISIBLE" and when the form state is saved in the request. (my 
experiments are based on the form1 action example)

If I use the event framework to change the state from ACTIVE to 
INVISIBLE, toggling works, but the value of the changed widget gets 
lost.

Looking at the samples I can't figure out ...
- How can a widget have the state "INVISIBLE"? Where is this 
information stored, or better from where is it read?


Have a look at AbstractWidget.{get|set|getCombined}State() and also 
at WidgetState.


- If I'm right and the described behavior (losing the values of 
INVISIBLE widgets) is a bug, how can it be fixed? Any ideas?


If it behaves as you describe it, then yes it's a bug. A field only 
reads its value when in ACTIVE state, and keeps its current value 
otherwise.

and here seems to be the bug: the inactive widget can't keep its state 
as its state would have to be available as request parameter and this 
never comes (as it's inactive).

Hmm... before being invisible, the widget is active, no? So that means 
that its value is submitted along with the action that will change the 
state. So, except if you have some fancy layout, it should read its 
value before having its state changed.
I assume that it works so far but ...

And later, once invisible, the widget doesn't read its value on the 
request.
if the widget is invisible, there is no request value any more and as the form 
is not saved in the session, the widget loses its value.

Yep, though I'd say that's not a bug but a limitation. If you choose to
work stateless, there are some features you loose (for example, value
changed events won't do anything meaningful either).
In particular the value changed event works for me as long as I don't change the 
widget's state. But you're right, saving the form in the request-scope brings 
some limitations.

I try to find these limitations and then I can decide together with my customer 
what we will do.

Another idea I had is, that I could work on making the form object serializable 
and save the state in a hidden form field. The price to pay would be increased 
network traffic but the advantage of a stateless presentation layer wouldn't get 
lost. Hmmm the more I think about it the more I like this idea  wdot?

--
Reinhard Pötz   Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

Re: [cforms] Widget states in request-scoped forms

2005-03-15 Thread Bruno Dumon

On Tue, 2005-03-15 at 09:11 +0100, Reinhard Poetz wrote:
> Sylvain Wallez wrote:
> > Reinhard Poetz wrote:
> > 
> >> Sylvain Wallez wrote:
> >>
> >>> Reinhard Poetz wrote:
> >>>
> 
>  Today I've tried to run a form that uses the widget state 
>  "INVISIBLE" and when the form state is saved in the request. (my 
>  experiments are based on the form1 action example)
> 
>  If I use the event framework to change the state from ACTIVE to 
>  INVISIBLE, toggling works, but the value of the changed widget gets 
>  lost.
> 
>  Looking at the samples I can't figure out ...
> 
>  - How can a widget have the state "INVISIBLE"? Where is this 
>  information stored, or better from where is it read?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Have a look at AbstractWidget.{get|set|getCombined}State() and also 
> >>> at WidgetState.
> >>>
>  - If I'm right and the described behavior (losing the values of 
>  INVISIBLE widgets) is a bug, how can it be fixed? Any ideas?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> If it behaves as you describe it, then yes it's a bug. A field only 
> >>> reads its value when in ACTIVE state, and keeps its current value 
> >>> otherwise.
> >>
> >>
> >>
> >> and here seems to be the bug: the inactive widget can't keep its state 
> >> as its state would have to be available as request parameter and this 
> >> never comes (as it's inactive).
> > 
> > 
> > 
> > Hmm... before being invisible, the widget is active, no? So that means 
> > that its value is submitted along with the action that will change the 
> > state. So, except if you have some fancy layout, it should read its 
> > value before having its state changed.
> 
> I assume that it works so far but ...
> 
> > 
> > And later, once invisible, the widget doesn't read its value on the 
> > request.
> 
> if the widget is invisible, there is no request value any more and as the 
> form 
> is not saved in the session, the widget loses its value.

Yep, though I'd say that's not a bug but a limitation. If you choose to
work stateless, there are some features you loose (for example, value
changed events won't do anything meaningful either).

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

Re: [cforms] Widget states in request-scoped forms