from:"bruno"

[ 
http://issues.apache.org/jira/browse/COCOON-1806?page=comments#action_12371529 
] 

Bruno Dumon commented on COCOON-1806:
-

Hi Simone,

If you would let the ValidatorBuilder implement LogEnabled and 
Contextualizable, you could pass the logger and context to setupComponent, so 
that the validator object has access to these.

If one has access to the Context object, it is possible to get the request and 
objectModel from there (using ContextHelper).

Finally, if you could also add a conf patch for SVN trunk (I know, it's 
trivial), then your patch is ready to apply...

Thanks!

 [PATCH] Java class custom validator builder
 ---

  Key: COCOON-1806
  URL: http://issues.apache.org/jira/browse/COCOON-1806
  Project: Cocoon
 Type: New Feature
   Components: Blocks: Forms
 Versions: 2.1.9-dev (current SVN)
 Reporter: Simone Gianni
  Attachments: javavalidator-conf.diff, javavalidator.diff

 Implemented a custom java validator builder, very similar to the custom java 
 listener builder. Also implemented a sample birthday validator and added it 
 to form2 sample.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (COCOON-1806) [PATCH] Java class custom validator builder

 [ http://issues.apache.org/jira/browse/COCOON-1806?page=all ]
 
Bruno Dumon closed COCOON-1806:
---

Fix Version: 2.2-dev (Current SVN)
 2.1.9-dev (current SVN)
 Resolution: Fixed

Applied. Thanks for your contribution.

PS: the forms block is shared between Cocoon 2.1.x and 2.2 (at least the java 
sources and the samples), so the patch for either trunk or 2.1.x only had to 
contain the config changes.

 [PATCH] Java class custom validator builder
 ---

  Key: COCOON-1806
  URL: http://issues.apache.org/jira/browse/COCOON-1806
  Project: Cocoon
 Type: New Feature
   Components: Blocks: Forms
 Versions: 2.1.9-dev (current SVN)
 Reporter: Simone Gianni
  Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN)
  Attachments: javavalidator-conf.diff, javavalidator-trunk.diff, 
 javavalidator.diff, javavalidator2.diff

 Implemented a custom java validator builder, very similar to the custom java 
 listener builder. Also implemented a sample birthday validator and added it 
 to form2 sample.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1806) [PATCH] Java class custom validator builder

[ 
http://issues.apache.org/jira/browse/COCOON-1806?page=comments#action_12371554 
] 

Bruno Dumon commented on COCOON-1806:
-

Forgot to mention this:

It would be nice if you could add some docs on this new validator on

http://cocoon.zones.apache.org/daisy/documentation/864/forms/concepts/484.html

If you don't have an account in Daisy yet, first register yourself, then send a 
mail to the dev list asking for edit access (mention your Daisy login).

Alternatively, if you write something up in text or html format and attach it 
to this issue, I can add it over there as well.

 [PATCH] Java class custom validator builder
 ---

  Key: COCOON-1806
  URL: http://issues.apache.org/jira/browse/COCOON-1806
  Project: Cocoon
 Type: New Feature
   Components: Blocks: Forms
 Versions: 2.1.9-dev (current SVN)
 Reporter: Simone Gianni
  Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN)
  Attachments: javavalidator-conf.diff, javavalidator-trunk.diff, 
 javavalidator.diff, javavalidator2.diff

 Implemented a custom java validator builder, very similar to the custom java 
 listener builder. Also implemented a sample birthday validator and added it 
 to form2 sample.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1806) [PATCH] Java class custom validator builder

[ 
http://issues.apache.org/jira/browse/COCOON-1806?page=comments#action_12371557 
] 

Bruno Dumon commented on COCOON-1806:
-

@andrew:

save the patch files (javavalidator2.diff and javavalidator-conf.diff) in the 
cocoon source tree root and do

patch -p0  javavalidator2.diff
patch -p0  javavalidator-conf.diff

Alternatively, instead of this patch, remember that you can also add validators 
on the form instance from your Java code:

form.addValidator(new WidgetValidator() { ... });

 [PATCH] Java class custom validator builder
 ---

  Key: COCOON-1806
  URL: http://issues.apache.org/jira/browse/COCOON-1806
  Project: Cocoon
 Type: New Feature
   Components: Blocks: Forms
 Versions: 2.1.9-dev (current SVN)
 Reporter: Simone Gianni
  Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN)
  Attachments: javavalidator-conf.diff, javavalidator-trunk.diff, 
 javavalidator.diff, javavalidator2.diff

 Implemented a custom java validator builder, very similar to the custom java 
 listener builder. Also implemented a sample birthday validator and added it 
 to form2 sample.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Commented: (COCOON-1806) [PATCH] Java class custom validator builder

2006-03-23 Thread Bruno Dumon

On Thu, 2006-03-23 at 15:23 +0100, Simone Gianni wrote:
 Hi Bruno,
 I already have an account on cocoon zones : SimoneGianni. Please give me 
 edit rights,

Done.

  I also have to write about the char datatype (COCOON-1789) 
 and the apache enum selection lists (COCOON-1793).

great.

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

Re: [vote] Niclas Hedhman as a new Cocoon committer

2006-03-23 Thread Bruno Dumon

On Thu, 2006-03-23 at 19:26 +0100, Daniel Fagerstrom wrote:
 Hi all!
 
 I'd like to propose Niclas Hedhman as a new Cocoon committer. He has 
 been around at cocoon-dev since 2000, regularly delivering insight full 
 comments about technical as well as community questions, high quality 
 patches and strong opinions in various topics ;) He has been and is 
 committer and active in several other Apache projects and have started 
 some OS projects outside Apache. He is also an expert member of JSR 291 
 (OSGi), and earlier JSR-78 (RMI Custom Remote References).
 
 Please cast your votes.

+1

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

[jira] Commented: (COCOON-1804) Javascript FOM_SCOPE issue when using Java as the flow engine - ReferenceError: cocoon is not defined

2006-03-22 Thread Bruno Dumon (JIRA)

[ 
http://issues.apache.org/jira/browse/COCOON-1804?page=comments#action_12371398 
] 

Bruno Dumon commented on COCOON-1804:
-

Implementing a WidgetValidator + Builder + adding it to cocoon.xconf should IMO 
only be done for providing entirely new types of validators, not for your 
application-logic validators.

Now what's been missing for a long time is a generic java class validator, i.e. 
something one could use like:

fd:validation
   fd:java class=/
/fd:validation

and which delegates to the specified class, without requiring registration in 
cocoon.xconf. Creating such a fd:java validator should be easy. If Avalon 
interfaces such as Contextualizable and Serviceable are honored, the validator 
can access the request object etc.

As an alternative, you can also add a validator on the form instance (using the 
addValidator method on any widget). This makes it very easy to make objects 
from your flow available to the validator.

 Javascript FOM_SCOPE issue when using Java as the flow engine - 
 ReferenceError: cocoon is not defined
 ---

  Key: COCOON-1804
  URL: http://issues.apache.org/jira/browse/COCOON-1804
  Project: Cocoon
 Type: Bug
   Components: Blocks: Java Flow
 Versions: 2.1.8
 Reporter: Andrew Madu
 Priority: Blocker


 I have created a  java flow class which does the following:
 //Load in validation file
 FormInstance form = new FormInstance(forms/login.xml);
 My login map (snippet) is as follows:
 Login.xml:
 fd:validation
 fd:javascript
 var success = true;
 var newUserReg = new Packages.test.User();
 var username = widget.lookupWidget(username);
 var password = widget.lookupWidget(password);

 try {
 
 var checkUserTest = newUserReg.getUser(username.value, 
 password.value);
 
 if (checkUserTest != null) {
 cocoon.session.setAttribute(user, checkUserTest);
 success = true;
 }else{
 username.setValidationError(new 
 Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
 password.setValidationError(new 
 Packages.org.apache.cocoon.forms.validation.ValidationError(The password, 
 username combination does not exist. Please enter another one., false));
 success = false;
 }
 } catch (e) {
 username.setValidationError(new 
 Packages.org.apache.cocoon.forms.validation.ValidationError(e, false));
 password.setValidationError(new 
 Packages.org.apache.cocoon.forms.validation.ValidationError(e., false));
 success = false;
 }
 return success;
 /fd:javascript
 /fd:validation
 I am getting an error message when the line 
 'cocoon.session.setAttribute(user, checkUserTest)' is hit.:
 ReferenceError: cocoon is not defined
 What is the issue here, can I create a session object from within form 
 validation/javascript in another way?
 Andrew

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: ForrestBot build for cocoon-docs FAILED

2006-03-21 Thread Bruno Dumon

On Tue, 2006-03-21 at 19:11 +1100, David Crossley wrote:
 David Crossley wrote:
  Bruno Dumon wrote:
   BTW, this time not because the zone was restarted. Not sure what the
   problem is though.
  
  I investigated a bit yesterday, but cannot see what
  is the problem. Notice that today there are less breaks
  than yesterday. However, looking at the cocoon-docs mailing
  list diffs from Daisy i cannot see any relevant changes.
  
  http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml
  
  It complains about Daisy IDs 786 and 655 which are
  navigation documents. Surely Forrest's Cocoon had
  already processed those resources.
  
  Strange. I am stumped. Ross seems busy with other stuff.
 
 Curiouser and curiouser. At the next 12-hourly run
 there is only one breakage and for a different ID.

FYI: I've had a look at the Daisy log files, and don't see anything
there. The server has also been continuously up.

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

Re: [Vote] Release plan for 2.1.9

2006-03-21 Thread Bruno Dumon

On Tue, 2006-03-21 at 09:20 +0100, Carsten Ziegeler wrote:
 Although we already agreed informaly on the release plan, we should
 do a formal vote.
 As I won't be able to do the release on the 31st of March, we have to
 delay it by one week (unless someone else volunteers to do it).
 
 So the proposed plan to release 2.1.9 is:
 - Start code freeze on the 31st of March
 - Release on the 6th of April (if nothing bad happens)
 
 Please cast your votes

+1

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

Re: [docs] sitemap component docs initial import done

On Mon, 2006-03-20 at 11:20 +0100, hepabolu wrote:
 Bertrand Delacretaz said the following on 18-03-2006 21:24:
  Le 18 mars 06 à 21:03, Bruno Dumon a écrit :
  
  ...You can see the result in the Components section of the 
  documentation,
  or browse it using the faceted navigation...
  
  Awesome! (sound of me writing down your name in the 
  I-owe-these-guys-a-beer list)
  
  ...There's still a lot of work to do to fill in all the docs, but at 
  least
  this gives an overview of the available components...
  
  And the work can be done in small steps, one class at a time, cool!
 
 +1000 here too.
 
 BTW Just for clarity: if I properly tag a class and add the info that's 
 in the legacy docs for this class, would that be ok? And was that your 
 intention?

The intention is to tag the classes, and to write longer, user-oriented
documentation on it in Daisy. For this the legacy docs, javadoc, wiki
and mailing list archives can be used as inspiration.

If you want to help out, but don't necessarily know much about all these
components, a first and very helpful step would be to add the javadoc
tags.

Here's a description of the supported tags, taken from
whiteboard/sitemaptags2daisy/README.txt

--- begin ---
@cocoon.sitemap.component.name
default name with which this component is declared in the
sitemap

@cocoon.sitemap.component.documentation.disabled
excludes the component from the documentation

@cocoon.sitemap.component.documentation
A short (one-paragraph) description of the component.
Can contain HTML markup (preferably only inline tags).

@cocoon.sitemap.component.documentation.caching
A comment about the caching of this component. The cacheability
of the component is figured out automatially by its implemented
interfaces, but this tag allows to provide a short comment on
the chaching conditions. This is mapped to a field in Daisy,
thus should not contain HTML markup.
--- end ---

All tags are optional.

For the @c.s.c.documentation tag, you can often just take the first or
first few sentences of the javadoc.

Also take care to add the tags at the end of the javadoc. I mean the
javadoc should be structured like this:

/**
 * Here's the normal javadoc
 *
 * @cocoon.sitemap.component.documentation blah blah
 */

If you look at e.g. I18nTransformer.java, you'll see the tags are at the
top, and the normal javadoc text at the bottom, which breaks the javadoc
generation:
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/I18nTransformer.html
(it thinks the text is all part of the @c.s.c.logger annotation).

Note that I'm running this tool on trunk, so any updates will only have
effect when committed over there.

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

Re: error handling in aggregations

On Mon, 2006-03-20 at 12:00 +, Jeremy Quinn wrote:
 Thanks for your reply Bruno,
 
 On 19 Mar 2006, at 13:32, Bruno Dumon wrote:
 
  On Sun, 2006-03-19 at 12:10 +, Jeremy Quinn wrote:
  Hi All
 
  Investigating this further, I came up with this simplest possible
  sitemap to reproduce the problem :
 
  ?xml version=1.0?
  map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
 
 map:components
   map:generators default=file
 map:generator name=file label=content
  logger=sitemap.generator.file pool-grow=4 pool-max=32 pool-
  min=4 src=org.apache.cocoon.generation.FileGenerator/
  /map:generators
   map:serializers default=xml
 map:serializer name=xml logger=sitemap.serializer.xml
  mime-type=text/xml pool-grow=4 pool-max=32 pool-min=4
  src=org.apache.cocoon.serialization.XMLSerializer/
   /map:serializers
   map:matchers default=wildcard
 map:matcher logger=sitemap.matcher.wildcard name=wildcard
  src=org.apache.cocoon.matching.WildcardURIMatcher/
   /map:matchers
   map:pipes default=noncaching
 map:pipe logger=sitemap.pipes.noncaching name=noncaching
  src=org.apache.cocoon.components.pipeline.impl.NonCachingProcessingP 
  ipe
  line
   parameter name=outputBufferSize value=32768/
 /map:pipe
   /map:pipes
 /map:components
 
 map:pipelines
 
   map:pipeline internal-only=false type=noncaching
 
 map:match pattern=test
   map:aggregate element=site
 map:part element=content1 src=nothing.xml/
 map:part element=content2 src=nothingelse.xml/
   /map:aggregate
   map:serialize type=xml /
 /map:match
 
   /map:pipeline
 
 /map:pipelines
 
  /map:sitemap
 
  I set this up as the top-level sitemap, loaded by cocoon.xconf.
 
  I access the url and I get this :
 
  $ curl http://localhost:/test
  ?xml version=1.0 encoding=ISO-8859-1?sitecontent1//
  sitehtmlheadtitleResource Not Found/titlestyle!--body
  { background-color: white; color: black; font-family: verdana,
  helvetica, sanf serif;}h1 {color: #336699; margin: 0px 0px 20px 0px;
  border-width: 0px 0px 1px 0px; border-style: solid; border-color:
  #336699;}p.footer { color: #336699; border-width: 1px 0px 0px 0px;
  border-style: solid; border-color: #336699; }span {color: #336699;}
  pre {padding-left: 20px;}a:link {font-weight: bold; color: #336699;}
  a:visited {color: #336699; }a:hover {color: #80; background-
  color: #80;}a:active {color: #00;}--/style/
  headbodyh1Resource Not Found/h1pspanMessage:/span
  Resource Not Found/ppspanDescription:/span The requested
  resource quot;/testquot; could not be found/ppspanSender:/
  span org.apache.cocoon.servlet.CocoonServlet/ppspanSource:/
  span Cocoon Servlet/pp class='footer'a href='http://
  cocoon.apache.org/'Apache Cocoon 2.1.9-dev/p/body/html
 
  Two outputs 
 
  First the content of the failed aggregation : sitecontent1// 
  site
  Then the generic error message.
 
 
  If I now comment out the line parameter name=outputBufferSize
  value=32768/ from the map:pipe. then I only get the error  
  message.
 
  I have tested this in 2.1.7 -- 2.1.9-dev.
 
  I suspect this did not occur in 2.1.6.
 
 
  Is this a bug, or is it what I should expect to happen if an output
  buffer is configured?
 
  Hi Jeremy,
 
  Given the streaming nature of the SAX pipeline, buffering the complete
  output at the end of the pipeline is indeed the only way to reliably
  recover from exceptions that might happen during its execution.  
  This is
  not necessarily bad, as whatever other way you would solve this, you
  would need to temporarily store the data in one way or another to be
  able to recover from errors.
 
 Thanks for your explanation.
 
 So I wonder why is this behaviour is 'fixed' when I turn off the buffer?
 Or am I not actually turning off the buffer by removing that  
 parameter, just allowing it to be set to a different default value?

Yes, by default the whole output is buffered before sending it to the
client. If you search for outputBufferSize in Cocoon's default root
sitemap you will find some information on this.

 
  There's a little bit more to it though. In case of an error the output
  your pipeline is quite small:
 
  ?xml version=1.0 encoding=ISO-8859-1?sitecontent1//site
 
 It is not normally that small, in my 'real' pipelines, there is far  
 more content.
 
  which is much less then your buffer size of 32768, so normally Cocoon
  should still be able to reset the output before generating the error
  page.
 
  Someone asked the exact same question a week or two ago on the users
  list, at which time I had a quick look into this. The cause is that  
  the
  ContentAggregator class, which does the aggregation, will still  
  generate
  the endDocument event in case an exception occurs. IMO, it should  
  not do
  this (unless it would also catch the exception). Here is the relevant
  fragment

Re: ForrestBot build for cocoon-docs FAILED

BTW, this time not because the zone was restarted. Not sure what the
problem is though.

On Mon, 2006-03-20 at 12:22 +, [EMAIL PROTECTED]
wrote:
 Automated build for cocoon-docs FAILED
 Log attached.
snip/
  [java] * [372/7]   [0/296]   4.138s 53.3Kb  
 2.1/userdocs/core/image-reader.html
  [java] * [373/6]   [0/296]   3.547s 48.8Kb  
 2.1/userdocs/widgets/widget_row_action.html
  [java] * [375/4]   [0/296]   3.646s 50.2Kb  
 2.1/userdocs/profile-generator.html
  [java] * [376/3]   [0/296]   3.742s 46.7Kb  2.1/faq/faq-selectors.html
  [java] X [0] 
 2.1/userdocs/concepts/validation.html   BROKEN: Resource not found: 
 cocoon://daisy.site.786
  [java] X [0] 
 2.1/userdocs/text-serializer.html   BROKEN: Resource not found: 
 cocoon://daisy.site.655
  [java] X [0] 
 2.1/userdocs/svgpng-serializer.html BROKEN: Resource not found: 
 cocoon://daisy.site.655
  [java] Total time: 20 minutes 10 seconds,  Site size: 16,404,087 Site 
 pages: 324
  [java] Java Result: 1
  [echo] 
   Copying broken links file to site root.
   
  [copy] Copying 1 file to /var/apache2/htdocs/ft/build/cocoon-docs
  [echo] Oops, something broke
 
-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [docs] sitemap component docs initial import done

On Mon, 2006-03-20 at 14:09 +0100, hepabolu wrote:
Bruno Dumon said the following on 20-03-2006 11:58:

The intention is to tag the classes, and to write longer, user-oriented
documentation on it in Daisy. For this the legacy docs, javadoc, wiki
and mailing list archives can be used as inspiration.

If you want to help out, but don't necessarily know much about all these
components, a first and very helpful step would be to add the javadoc
tags.

If you look at e.g. I18nTransformer.java, you'll see the tags are at the
top, and the normal javadoc text at the bottom, which breaks the javadoc
generation:
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/I18nTransformer.html
(it thinks the text is all part of the @c.s.c.logger annotation).

So after this is done, each component ends up with:
- a javadoc file
- a summary (using this tool) in Daisy
- a Daisy page with user oriented info

Is this correct?

The last two items are in the same Daisy document, just different parts
in it. So they will be dispayed on the same page.

As for every Java class, there will of course be a javadoc-generated
page. However, since sitemap components are not used using their Java
API, and their target audience is not only Java developers, it is IMO
more meaningful and easier to maintain their docs in Daisy.

So with time we might remove the longer user-oriented descriptions from
the javadoc and only use Daisy for them, but let's first see how this
evolves before removing anything.

Note that I'm running this tool on trunk, so any updates will only have
effect when committed over there.

Good to know. ;-)

Bye, Helma

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

Re: error handling in aggregations

2006-03-19 Thread Bruno Dumon

On Sun, 2006-03-19 at 12:10 +, Jeremy Quinn wrote:
 Hi All
 
 Investigating this further, I came up with this simplest possible  
 sitemap to reproduce the problem :
 
 ?xml version=1.0?
 map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
 
map:components
  map:generators default=file
map:generator name=file label=content  
 logger=sitemap.generator.file pool-grow=4 pool-max=32 pool- 
 min=4 src=org.apache.cocoon.generation.FileGenerator/
 /map:generators
  map:serializers default=xml
map:serializer name=xml logger=sitemap.serializer.xml  
 mime-type=text/xml pool-grow=4 pool-max=32 pool-min=4  
 src=org.apache.cocoon.serialization.XMLSerializer/
  /map:serializers
  map:matchers default=wildcard
map:matcher logger=sitemap.matcher.wildcard name=wildcard  
 src=org.apache.cocoon.matching.WildcardURIMatcher/
  /map:matchers
  map:pipes default=noncaching
map:pipe logger=sitemap.pipes.noncaching name=noncaching  
 src=org.apache.cocoon.components.pipeline.impl.NonCachingProcessingPipe 
 line
  parameter name=outputBufferSize value=32768/
/map:pipe
  /map:pipes
/map:components
 
map:pipelines
 
  map:pipeline internal-only=false type=noncaching
 
map:match pattern=test
  map:aggregate element=site
map:part element=content1 src=nothing.xml/
map:part element=content2 src=nothingelse.xml/
  /map:aggregate
  map:serialize type=xml /
/map:match
 
  /map:pipeline
 
/map:pipelines
 
 /map:sitemap
 
 I set this up as the top-level sitemap, loaded by cocoon.xconf.
 
 I access the url and I get this :
 
 $ curl http://localhost:/test
 ?xml version=1.0 encoding=ISO-8859-1?sitecontent1// 
 sitehtmlheadtitleResource Not Found/titlestyle!--body  
 { background-color: white; color: black; font-family: verdana,  
 helvetica, sanf serif;}h1 {color: #336699; margin: 0px 0px 20px 0px;  
 border-width: 0px 0px 1px 0px; border-style: solid; border-color:  
 #336699;}p.footer { color: #336699; border-width: 1px 0px 0px 0px;  
 border-style: solid; border-color: #336699; }span {color: #336699;} 
 pre {padding-left: 20px;}a:link {font-weight: bold; color: #336699;} 
 a:visited {color: #336699; }a:hover {color: #80; background- 
 color: #80;}a:active {color: #00;}--/style/ 
 headbodyh1Resource Not Found/h1pspanMessage:/span  
 Resource Not Found/ppspanDescription:/span The requested  
 resource quot;/testquot; could not be found/ppspanSender:/ 
 span org.apache.cocoon.servlet.CocoonServlet/ppspanSource:/ 
 span Cocoon Servlet/pp class='footer'a href='http:// 
 cocoon.apache.org/'Apache Cocoon 2.1.9-dev/p/body/html
 
 Two outputs 
 
 First the content of the failed aggregation : sitecontent1//site
 Then the generic error message.
 
 
 If I now comment out the line parameter name=outputBufferSize  
 value=32768/ from the map:pipe. then I only get the error message.
 
 I have tested this in 2.1.7 -- 2.1.9-dev.
 
 I suspect this did not occur in 2.1.6.
 
 
 Is this a bug, or is it what I should expect to happen if an output  
 buffer is configured?

Hi Jeremy,

Given the streaming nature of the SAX pipeline, buffering the complete
output at the end of the pipeline is indeed the only way to reliably
recover from exceptions that might happen during its execution. This is
not necessarily bad, as whatever other way you would solve this, you
would need to temporarily store the data in one way or another to be
able to recover from errors.

There's a little bit more to it though. In case of an error the output
your pipeline is quite small:

?xml version=1.0 encoding=ISO-8859-1?sitecontent1//site

which is much less then your buffer size of 32768, so normally Cocoon
should still be able to reset the output before generating the error
page.

Someone asked the exact same question a week or two ago on the users
list, at which time I had a quick look into this. The cause is that the
ContentAggregator class, which does the aggregation, will still generate
the endDocument event in case an exception occurs. IMO, it should not do
this (unless it would also catch the exception). Here is the relevant
fragment:


try {
SourceUtil.parse(this.manager, part.source, this);
} finally {
if (part.element != null) {
endElem(part.element);
}
}
}
} finally {
endElem(this.rootElement);
this.contentHandler.endDocument();
}


I'd be in favor of removing these two finally blocks.

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

[docs] sitemap component docs initial import done

2006-03-18 Thread Bruno Dumon

Hi,

I just wanted to let you know:

* that the new tool to sync the information about sitemap components
from the Java sources to Daisy documents, about which I wrote in a
previous mail, is now in the whiteboard.

* that I've done an initial run of it (during which I disabled the email
notifications to avoid 190 similar mails on the docs list). It uses the
trunk-sources so for now not all blocks are included.

You can see the result in the Components section of the documentation,
or browse it using the faceted navigation.

http://cocoon.zones.apache.org/daisy/documentation/

There's still a lot of work to do to fill in all the docs, but at least
this gives an overview of the available components.

I'll see to add some documentation on how to contribute to this.

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

[docs] @cocoon.sitemap tags and Daisy

2006-03-14 Thread Bruno Dumon

Hi,

This weekend I wrote a little tool to sync the @cocoon.sitemap.**
annotations in the source code to Daisy documents. This proved to be
quite simple, since a lot of work was already done: the tags were
already defined, there are sources files using them, and the SitemapTask
class showed how to use QDox to extract them.

More precisely, for each sitemap component source file, the tool will
check if there is already a document for it in Daisy (based on a field
JavaClass containing the fully qualified name of the class). If it does
not exist, it will create it, or otherwise update the existing document
(only if needed, so that documents are not updated unnecessarily).

The following annotations are mapped to fields in Daisy documents:

@cocoon.sitemap.component.name
@cocoon.sitemap.component.documentation.caching

The value of the following annotation is mapped to a part (to support
markup and somewhat longer content) in the Daisy document:

@cocoon.sitemap.component.documentation

The following tag is honored to exclude the class from the
documentation:

@cocoon.sitemap.component.documentation.disabled

Also, some fields are automatically assigned:
- java class name
- component type (matcher, generator, ...)
- block name
- deprecated

There are some other tags (for label, logger, pooling.max and
configuration) that it currently ignores, as I thought these are not
that useful.


The goal of all this would be that the basic facts about each component
are taken from the source code, and longer (user-oriented) documentation
could then be added in Daisy (in a document part that is left alone by
this tool).

I'll finish it up next weekend (if time permits) and commit it to the
whiteboard. I would then also like to give it a run (based on trunk), if
nobody sees a problem in that (the documents can always be deleted
afterwards, if needed).

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

Re: svn commit: r385053 - in /cocoon/trunk/cocoon-template/cocoon-template-impl/src/main: java/org/apache/cocoon/template/template-instructions.xml resources/org/apache/cocoon/template/template-instru

2006-03-13 Thread Bruno Dumon

On Mon, 2006-03-13 at 09:26 +0100, Leszek Gawron wrote:
 [EMAIL PROTECTED] wrote:
  Author: bruno
  Date: Sat Mar 11 02:41:49 2006
  New Revision: 385053
  
  URL: http://svn.apache.org/viewcvs?rev=385053view=rev
  Log:
  Sharing template block with 2.1: step 3: move template-instructions.xml 
  between java sources (AFAIK 2.1 build doesn't support a separate resources 
  dir)
  
  Added:
  
  cocoon/trunk/cocoon-template/cocoon-template-impl/src/main/java/org/apache/cocoon/template/template-instructions.xml
- copied unchanged from r385046, 
  cocoon/trunk/cocoon-template/cocoon-template-impl/src/main/resources/org/apache/cocoon/template/template-instructions.xml
  Removed:
  
  cocoon/trunk/cocoon-template/cocoon-template-impl/src/main/resources/org/apache/cocoon/template/template-instructions.xml
 you cannot do it like this - maven won't pick that file up for jar package.
 

Ah of course. I have now added it to the resources in the pom of the
template block. If you prefer another solution, just let me know. BTW, I
think we'll need to do something similar for the resources in the forms
block.

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

Re: [EMAIL PROTECTED]: Project daisy-util (in module cocoon) failed

2006-03-12 Thread Bruno Dumon

I took care of this.

On Sun, 2006-03-12 at 00:26 -0800, Gump wrote:
 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 daisy-util has an issue affecting its community integration.
snip/

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

forgot to update license files in legal (was Re: svn commit: r385265 - in /cocoon/trunk/lib/optional: daisy-htmlcleaner-1.1.jar daisy-htmlcleaner-1.4.1.jar daisy-util-1.1.jar daisy-util-1.4.1.jar)

2006-03-12 Thread Bruno Dumon

Thanks for reminding, done now.

On Sun, 2006-03-12 at 04:27 -0600, Antonio Gallardo wrote:
 Bruno,
 
 please update the license files in legal.
 
 Best Regards,
 
 Antonio Gallardo
 
 [EMAIL PROTECTED] wrote:
 
 Author: bruno
 Date: Sun Mar 12 01:36:27 2006
 New Revision: 385265
snip/

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

Re: Sharing the template block between 2.1 and 2.2 DONE!

2006-03-11 Thread Bruno Dumon

On Fri, 2006-03-10 at 16:53 +0100, Reinhard Poetz wrote:
 Jason Johnston wrote:
 
  A question: it appears that both the 2.1.x core and the template block
  contain the classes o.a.c.generation.JXTemplateGenerator and
  o.a.c.transformation.JXTemplateTransformer.  In 2.1.x they're the old JX
  we know and love, and in the template block they point to the new JX.
  
  So when using those old classes in 2.1.x with the template block
  included, which version of JX gets used?
 
 In 2.1.x the old generator should *not* extend the new generator and in the 
 template block we should simply remove the class. In order to do this and 
 follow 
 our versioning policy, we have to deprecate the old implementations.
 

I followed this suggestion, as this is also what has been voted on [1].

The move is done now. The java sources of the template block are
shared via svn:externals.

In 2.1, the new jx template generator is by default declared in the
sitemap with the name newjx.

[1] http://marc.theaimsgroup.com/?t=11371475241r=1w=2

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

Re: [Documentation] Verify status of flowscript document please

2006-03-10 Thread Bruno Dumon

On Fri, 2006-03-10 at 11:31 +0100, hepabolu wrote:
 Hi,
 
 AFAICT this page:
 
 http://cocoon.zones.apache.org/daisy/legacydocs/documentation/userdocs/flow/api.html
 
 is still valid for trunk.
 
 If so I'd like to move it out of the legacy documentation into the 
 official documentation for 2.2. For those not up-to-date on this: it 
 merely means it will be useable in both 2.1.X and 2.2 documentation.
 
 So can some flow expert do a quick check and either change the Daisy 
 collection of the file or report back here.

It needs a refresh, for example the request, response and session
objects have been replaced with their full java equivalents instead of a
subset of them (and hence, don't need to be documented in full there
anymore). It would be best to check the source code of the FOM to see if
all methods  parameters have been documented.

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

[jira] Commented: (COCOON-1777) fd:on-value-changed does not work with fd:multivaluefield

2006-03-10 Thread Bruno Dumon (JIRA)

[ 
http://issues.apache.org/jira/browse/COCOON-1777?page=comments#action_12369849 
] 

Bruno Dumon commented on COCOON-1777:
-

Hi,

Thanks for your patch.

If I understand it correctly, the following will cause auto-submit to be 
enabled if there are value change listeners:

  script type=text/javascriptxsl:value-of select=$browser-variable/ 
= forms_createOptionTransfer('xsl:value-of select=@id/', xsl:value-of 
select=@listening = 'true'/);/script

which makes it impossible to disable value change listeners, so a better test 
would be:

  script type=text/javascriptxsl:value-of select=$browser-variable/ 
= forms_createOptionTransfer('xsl:value-of select=@id/', xsl:value-of 
select=@listening = 'true'  and not(fi:styling/@submit-on-change = 
'false')/);/script

Correct?

 fd:on-value-changed does not work with fd:multivaluefield
 -

  Key: COCOON-1777
  URL: http://issues.apache.org/jira/browse/COCOON-1777
  Project: Cocoon
 Type: Bug
   Components: Blocks: Forms
 Versions: 2.1.8
 Reporter: Grzegorz Kossakowski (aka g[R]eK)
  Attachments: mutlivaluefield.patch

 Element fd:on-value-changed seems to not work with fd:multivaluefield. I have 
 tried it using Cocoon samples, more specifically I changed fd:[EMAIL 
 PROTECTED]'drinks'] to:
 fd:multivaluefield id=drinks
   fd:labelIndicate which 2 of the following drinks you'd like to 
 receive:/fd:label
   fd:datatype base=string/
   fd:validation
 fd:value-count exact=2/
   /fd:validation
   fd:selection-list
 fd:item value=Maes/
 fd:item value=Jupiler/
 fd:item value=Leffe/
 fd:item value=Hoegaarden/
 fd:item value=Coca Cola/
   /fd:selection-list
   fd:on-value-changed
 javascript
   java.lang.System.err.println(Drinks value changed:  + 
 event.newValue);
 /javascript
   /fd:on-value-changed
 /fd:multivaluefield 
 So I just added fd:on-value-changed but nothing happend when I was trying to 
 change values of this field. I have no problem with normal field widgets, 
 events work perfectly. I am also sure that it's not client/styling issue 
 because I found that in form instance xml normal field widget have @listening 
 attribute but multivalue field have not.
 I don not know how to debug Cocoon so I am not able to continue investigation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Sharing the template block between 2.1 and 2.2 (was Re: Release 2.1.9 (again))

2006-03-10 Thread Bruno Dumon

On Thu, 2006-03-09 at 14:49 -0700, Jason Johnston wrote:
 On Thu, 2006-03-09 at 21:10 +, Upayavira wrote:
  Jason Johnston wrote:
   On Thu, 2006-03-09 at 08:46 -0800, Ralph Goers wrote:
   Bruno Dumon wrote:
  
   On Thu, 2006-03-09 at 06:35 -0800, Ralph Goers wrote:

  
   Hi. Its me again.
  
   Seriously, are we there yet?
  
  
   I guess nothing changed since you last asked ;-)

  
   Not quite.  A few days passed, which is all Sylvain said he needed.  
   AFAIK that is all we are waiting for.
   
   
   It gets mentioned every time someone asks about the 2.1.9 release, so to
   keep the pattern going: what about the Template block from trunk?  IIRC
   this was discussed and planned for inclusion in 2.1.9.
  
  Could you make a patch? That could make it happen.
 
 I would be glad to.  But I would need guidance, since I know nothing
 about what is required.  Is it just adding an svn:external to that
 block, or are there code changes involved?

I just gave this a try to see if it needs any special work.

Here's what I did or found out:

 * copied the java sources (src/main/java)

 * resources (src/main/resources):

   - 2.2 has imports for xconf and xroles, so for 2.1 I had to create a
set of patch files (similar as is done for forms): nothing special here

   - the resources also contained a file template-instructions.xml, I
copied this to the java sources

 * the template block needs the (new in 2.2) class
TemplateObjectModelHelper, which is outside of the template block. I
copied it in the sources of the template block

 * class JavascriptExpression and TemplateObjectModelHelper: require
changes due to changed rhino API. For JavascriptExpression I simply
commented out the code since it is not essential.

 * I got classcast exceptions when StringTemplateFactory and
ExpressionFactory were looked up from the ServiceManager. The cause is
that these classes don't have a service interface (their role is a
concrete class). I introduced interfaces for them.

 * Added block to gump.xml and block.properties

And then it worked. I tried it first with a simple test file and then
with the forms block, and everything seems ok.

- o -

To  summarize: if we want to have a shared codebase for the template
block, things that need to handled:

 - introduce interface for StringTemplateFactory and ExpressionFactory
== this is something I can do

 - don't make use of new rhino API features: I need someone else to look
into this

 - Move template_instructions.xml between the java sources instead of
the resources: I could do this, if nobody objects or knows a better way

 - TemplateObjectModelHelper: could duplicate it into 2.1 core

Opinions? Objections? Help?

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

[jira] Commented: (COCOON-1777) fd:on-value-changed does not work with fd:multivaluefield

2006-03-10 Thread Bruno Dumon (JIRA)

[ 
http://issues.apache.org/jira/browse/COCOON-1777?page=comments#action_12369858 
] 

Bruno Dumon commented on COCOON-1777:
-

I applied your patch, with the submit-on-change change.

 fd:on-value-changed does not work with fd:multivaluefield
 -

  Key: COCOON-1777
  URL: http://issues.apache.org/jira/browse/COCOON-1777
  Project: Cocoon
 Type: Bug
   Components: Blocks: Forms
 Versions: 2.1.8
 Reporter: Grzegorz Kossakowski (aka g[R]eK)
  Attachments: mutlivaluefield.patch

 Element fd:on-value-changed seems to not work with fd:multivaluefield. I have 
 tried it using Cocoon samples, more specifically I changed fd:[EMAIL 
 PROTECTED]'drinks'] to:
 fd:multivaluefield id=drinks
   fd:labelIndicate which 2 of the following drinks you'd like to 
 receive:/fd:label
   fd:datatype base=string/
   fd:validation
 fd:value-count exact=2/
   /fd:validation
   fd:selection-list
 fd:item value=Maes/
 fd:item value=Jupiler/
 fd:item value=Leffe/
 fd:item value=Hoegaarden/
 fd:item value=Coca Cola/
   /fd:selection-list
   fd:on-value-changed
 javascript
   java.lang.System.err.println(Drinks value changed:  + 
 event.newValue);
 /javascript
   /fd:on-value-changed
 /fd:multivaluefield 
 So I just added fd:on-value-changed but nothing happend when I was trying to 
 change values of this field. I have no problem with normal field widgets, 
 events work perfectly. I am also sure that it's not client/styling issue 
 because I found that in form instance xml normal field widget have @listening 
 attribute but multivalue field have not.
 I don not know how to debug Cocoon so I am not able to continue investigation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Re[2]: [Documentation] isGlobal == HTTP redirect, right? (was: Verify status of flowscript document please)

2006-03-10 Thread Bruno Dumon

On Fri, 2006-03-10 at 12:16 +0100, Grzegorz Kossakowski wrote:
 Hello Bertrand,
 
 Friday, March 10, 2006, 11:51:33 AM, you wrote:
 
  Le 10 mars 06 à 11:31, hepabolu a écrit :
 
  Just wondering about this isGlobal explanation:
 
  If the isGlobal argument is true, the redirect will be global, i.e.  
  it returns all the way to the browser, even from within internal  
  requests.
 
  is not too clear for me, I'd write:
 
 after few moments of exhilaration caused by the fact my first reported bug
 was fixed I feel the same, it's not clear
 
  The isGlobal argument, if true, causes an HTTP redirect to be sent  
  to the client browser in all cases.
 
  When isGlobal is false and the current request is an internal one  
  (i.e. uses the cocoon: protocol), the redirect is processed  
  internally within Cocoon, by executing the pipeline specified by the  
  uri argument, without sending an HTTP redirect.
 
 +1 for this with one exception. Not always pipeline is executed even isGlobal 
 is
 false. Eg:
 map:aggregate
   map:part src=cocoon:/callflow/
 /map:aggregate
 
 And in some flow function:
 cocoon.redirectTo(http://www.google.com;, false);
 
 Aggregator will try to use as a part content read from google. So it's not
 neccessarily redirect to another Cocoon pipeline. It just redirect internal
 request to whatever you want.

Thanks for clarifying (I learned something new). I added your
explanation to the docs:
http://cocoon.zones.apache.org/daisy/legacydocs/documentation/userdocs/flow/api.html

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

Re: Use Maven 2 for the generation of the Cocoon documentation

2006-03-07 Thread Bruno Dumon

On Tue, 2006-03-07 at 09:06 +0100, Reinhard Poetz wrote:
 Bruno Dumon wrote:
 
  OTOH, having the docs
  split up between a lot of little maven-sites might lessen the overview.
 
 Because of the nature of Daisy this shouldn't become a problem:
 
   - we can have one navigation document which is a collection of all
 block navigation docs
   - we have Daisy books
   - if that's not enough, we can refer to the same document from different
 navigation docs

Yes indeed, we can republish the same content in different ways.

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

Re: Use Maven 2 for the generation of the Cocoon documentation

2006-03-06 Thread Bruno Dumon

On Mon, 2006-03-06 at 18:39 +0100, Reinhard Poetz wrote:
 hepabolu wrote:
 
  Finally, adding the proposed plugin can always be added later without 
  loosing the effort of the current setup.
 
 ok, that's right. Anyway, I can't do it myself now but if somebody is 
 interested, I can help. Maybe some of the Daisy gurus here can comment on the 
 idea itself?
 

It shouldn't be too hard. If it is just for publishing, you don't even
need the Daisy client libraries, being able to do a HTTP request is
enough. I'm not sure what the difficulties are that Ross refers too in
reusing the navigation documents. A basic plugin can probably be created
in a day (by an experienced Java/XSLT person).

As for publishing the docs via Maven, I can understand the benefits to
that, especially as each block will become less dependent on the core
and might be versioned and released independently. OTOH, having the docs
split up between a lot of little maven-sites might lessen the overview.

In the short term, personally I'll focus on the actual content, as I
think that's a more urgent issue. However, while writing docs, we should
keep in mind to keep the docs related to a block grouped, focussed and
independent from each other, so that we don't make this proposal harder
to achieve.

[only slightly related to this thread...]
Something which I'll look in setting up soon is to allow to refer to
javadoc using a javadoc: URL which gets translated to the actual
javadoc location during publishing. To make it more block-oriented, the
syntax will probably be something like
javadoc:blockname:org/apache/

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

Re: [Docs] FAQ Document Type

2006-03-05 Thread Bruno Dumon

On Sat, 2006-03-04 at 19:04 +, Ross Gardler wrote:
 Bruno Dumon wrote:
  On Wed, 2006-03-01 at 14:01 +, Ross Gardler wrote:
  
 A couple of weeks ago I promised to set up a FAQ system in Daisy. I've 
 now done this.
 
 Creating a FAQ
 ==
 
 There is a FAQ document Type. This is a simple document in which the 
 document title should be the question and the content should be the answer.
 
 To illustrate things I have copied the installation faqs from 
 http://cocoon.apache.org/2.1/faq/faq-install.html into individual FAQ 
 documents, for example:
 
 http://cocoon.zones.apache.org/daisy/documentation/799.html?branch=1language=1
 http://cocoon.zones.apache.org/daisy/documentation/806.html?branch=1language=1
 
  
  snip the details/
  
 
 
 So, if people like this, we should migrate all FAQs from the legacy docs 
 into this format, as well as including relevant ones from the Wiki.
 
 Ross
  
  
  Thanks for setting this up. I have some reservations though about
  copying the FAQs from the legacy docs. I haven't read them all but a lot
  of them have become either incorrect or irrelevant. One of the reasons
  for the new documentation is that we can leave behind the outdated
  information.
 
 Yes, that makes sense, I'm a little behind with Cocoon, so do not have 
 the knowledge to decide what goes in and what stays out.
 
  I'd also like to change the
  query in the navigation to a query in a document: having the long
  questions in the navigation doesn't make sense I think.
 
 +1
 
 I only really threw these in as examples. Later I realised I had not 
 done an example of creating a complete FAQ document (i.e. with questions 
  answers) only of indexes (bth navigation and in document).
 
 None daisy users should be aware that the query system in Daisy is 
 superb and very flexible. If folk want something better than is 
 currently in place then just ask how (or do it).
 

I now made this of it:

http://cocoon.zones.apache.org/daisy/documentation/856.html

I've added a forms-related FAQ and a flowscript-related FAQ.

  Similar to the FAQ doctype, I'd also like to set up a GlosarryItem
  doctype which can be used to provide short explanations of
  Cocoon-specific terms (such as sitemap, subsitemap, FOM, flowscript,
  blocks, real blocks, ...).
 
 +1

And the glossary is here:

http://cocoon.zones.apache.org/daisy/documentation/857.html

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

Re: [Docs] FAQ Document Type

2006-03-04 Thread Bruno Dumon

On Wed, 2006-03-01 at 14:01 +, Ross Gardler wrote:
 A couple of weeks ago I promised to set up a FAQ system in Daisy. I've 
 now done this.
 
 Creating a FAQ
 ==
 
 There is a FAQ document Type. This is a simple document in which the 
 document title should be the question and the content should be the answer.
 
 To illustrate things I have copied the installation faqs from 
 http://cocoon.apache.org/2.1/faq/faq-install.html into individual FAQ 
 documents, for example:
 
 http://cocoon.zones.apache.org/daisy/documentation/799.html?branch=1language=1
 http://cocoon.zones.apache.org/daisy/documentation/806.html?branch=1language=1
 
snip the details/
 
 
 
 So, if people like this, we should migrate all FAQs from the legacy docs 
 into this format, as well as including relevant ones from the Wiki.
 
 Ross

Thanks for setting this up. I have some reservations though about
copying the FAQs from the legacy docs. I haven't read them all but a lot
of them have become either incorrect or irrelevant. One of the reasons
for the new documentation is that we can leave behind the outdated
information.

I'll have a look at removing those I think shouldn't be included
anymore, and maybe adding some fresh ones. I'd also like to change the
query in the navigation to a query in a document: having the long
questions in the navigation doesn't make sense I think.


Similar to the FAQ doctype, I'd also like to set up a GlosarryItem
doctype which can be used to provide short explanations of
Cocoon-specific terms (such as sitemap, subsitemap, FOM, flowscript,
blocks, real blocks, ...).

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

[docs] updating Daisy

2006-03-03 Thread Bruno Dumon

Hi,

If nobody minds I'd like to upgrade the Daisy on the cocoon zone this
afternoon, somewhere around 4 pm CET. Since this involves restarting
Daisy, it's better not to edit docs in Daisy around that time. I'll give
a notice when it's done.

Bruno.

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

Re: I am guest in Daisy

2006-03-03 Thread Bruno Dumon

On Fri, 2006-03-03 at 11:38 +0100, Jean-Baptiste Quenot wrote:
 Hello,
 
 Can someone with Daisy karma grant me to edit documents?  I would
 like to change the « Who we are » page for now.

done, enjoy.

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

[docs] Daisy updated, some new docs

2006-03-03 Thread Bruno Dumon

Hi,

The Daisy update on the cocoon zone is done.

I have also added some new sitemap reference docs, e.g.

http://cocoon.zones.apache.org/daisy/documentation/sitemap/reference/pipeline_elements/842.html

It's basically a document for each sitemap element, with a short
description, the attributes, and a link field holding references to the
documents describing the child elements of the sitemap element.

It should be complete (for C2.1) but if you notice missing elements or
attributes, just let me know or add them yourself. I have left out the
container-specific attributes on purpose (pool-min etc.).

From time to time I'll try to fill this up with some more content,
integrating the old docs etc.

 - o -

To the default CocoonDocument document type, I've added some (optional)
fields to allow more query-based navigation and faceted navigation. The
fields are:

* CocoonBlock: core, forms, portal, ...

* CocoonComponentReference: if the document is the reference
documentation for some type of Cocoon component (a transformer, a
widget), then this is indicated in this field

So that allows some more faceted browsing:

http://cocoon.zones.apache.org/daisy/documentation/facetedBrowser/default

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

Re: ForrestBot build for cocoon-docs FAILED

2006-02-27 Thread Bruno Dumon

I started the zone services.

On Mon, 2006-02-27 at 00:02 +, [EMAIL PROTECTED]
wrote:
 Automated build for cocoon-docs FAILED
 Log attached.
 

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

Re: ForrestBot build for cocoon-docs FAILED

2006-02-24 Thread Bruno Dumon

Zone services restarted...

On Fri, 2006-02-24 at 00:02 +, [EMAIL PROTECTED]
wrote:
 Automated build for cocoon-docs FAILED
 Log attached.

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

Re: Forms broken on IE

2006-02-24 Thread Bruno Dumon

On Thu, 2006-02-23 at 13:43 +0100, Sylvain Wallez wrote:
 Bruno Dumon wrote:
  Hi,
 
  With latest SVN (2_1_x branch), CForms gives a javascript error on IE6.
  This happens whenever I click somewhere on the page (doesn't matter
  where: in a blank area or an input field).
 
  The cause is that in dojo's HtmlDragManager.js, on line 185, the 'e'
  variable is undefined:
 
onMouseUp: function(e){
  this.mouseDownX = null;
  this.mouseDownY = null;
  this._dragTriggered = false;
  var _this = this;
  e.preventDefault();   === e undefined
 
  Maybe some of you who follow up dojo development know if this is already
  fixed or if the problem is caused by us.

 
 This not a problem in Dojo, but a bug in Matt Kruses's PopupWindow class 
 that wasn't properly chaining window.onload when there's an existing 
 handler, as is the case with Dojo.
 
 I fixed it when committing the Dojo stuff [1]
 
 Sylvain
 
 [1] 
 http://svn.apache.org/viewcvs.cgi/cocoon/trunk/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/resources/mattkruse-lib/PopupWindow.js?rev=379087r1=367689r2=379087
 

Hmmm, I still have this error. I was first testing on Windows 2000 (with
latest IE6) but now verified it's the same on Windows XP. This is with
an up to date checkout from this morning. Nobody else seeing this?

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

Re: Forms broken on IE

2006-02-23 Thread Bruno Dumon

On Thu, 2006-02-23 at 11:10 +0100, Carsten Ziegeler wrote:
 Bruno Dumon wrote:
  Hi,
  
  With latest SVN (2_1_x branch), CForms gives a javascript error on IE6.
  This happens whenever I click somewhere on the page (doesn't matter
  where: in a blank area or an input field).
  
  The cause is that in dojo's HtmlDragManager.js, on line 185, the 'e'
  variable is undefined:
  
onMouseUp: function(e){
  this.mouseDownX = null;
  this.mouseDownY = null;
  this._dragTriggered = false;
  var _this = this;
  e.preventDefault();   === e undefined
  
  Maybe some of you who follow up dojo development know if this is already
  fixed or if the problem is caused by us.
  
 Such issues really raise the question, Ralph has asked earlier one: Does
 it make sense
 that a stable forms block heavily depends on such an unstable Ajax
 block? I would be great, if the forms block could be used without ajax
 and ajax is an optional part. So we can mark forms stable without having
 to worry about ajax stuff. If we are not going this way and are tying
 those blocks heavily together (like they are today) then we should not
 mark the forms block stable and wait for that until the ajax block is
 stable as well.

I think we can mark them both stable. It's not like the Ajax
functionality will be removed again in the future, and from the user's
mailing list it seems many people are already relying on it.

But as Sylvain pointed out, since he just rewrote that part, it might be
better to wait a few weeks for the release so that it can get some more
testing.

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

[jira] Commented: (COCOON-1780) [PATCH] Upload Widget : Can not change selected file

[ 
http://issues.apache.org/jira/browse/COCOON-1780?page=comments#action_12367320 
] 

Bruno Dumon commented on COCOON-1780:
-

@vincent: I don't think there's a problem with that, but since it worked with 
'button' before, the real cause of the bug had to be something else.

 [PATCH] Upload Widget : Can not change selected file
 

  Key: COCOON-1780
  URL: http://issues.apache.org/jira/browse/COCOON-1780
  Project: Cocoon
 Type: Bug
   Components: Blocks: Forms
 Versions: 2.2-dev (Current SVN), 2.1.9-dev (current SVN)
 Reporter: vincent Demay
 Assignee: Jean-Baptiste Quenot
  Fix For: 2.1.9-dev (current SVN)


 When a file is selected with the upload widget and a on-value-change event is 
 fired, the value of the widget can not be changed by user.
 here is the patch
 Index: 
 /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
 ===
 --- 
 /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
(revision 377974)
 +++ 
 /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
(working copy)
 @@ -486,7 +486,7 @@
  xsl:text[/xsl:text
  xsl:value-of select=fi:value/
  xsl:text] /xsl:text
 -input type=button id=[EMAIL PROTECTED]:input name=[EMAIL 
 PROTECTED] value=... onclick=forms_submitForm(this)/
 +   input type=submit id=[EMAIL PROTECTED]:input name=[EMAIL 
 PROTECTED] value=... onclick=forms_submitForm(this)/
  /xsl:when
  xsl:otherwise
input type=file id=[EMAIL PROTECTED]:input name=[EMAIL 
 PROTECTED] title={fi:hint} accept=[EMAIL PROTECTED]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1780) [PATCH] Upload Widget : Can not change selected file

[ 
http://issues.apache.org/jira/browse/COCOON-1780?page=comments#action_12367334 
] 

Bruno Dumon commented on COCOON-1780:
-

good you noticed, it's fixed now, I hope.

 [PATCH] Upload Widget : Can not change selected file
 

  Key: COCOON-1780
  URL: http://issues.apache.org/jira/browse/COCOON-1780
  Project: Cocoon
 Type: Bug
   Components: Blocks: Forms
 Versions: 2.2-dev (Current SVN), 2.1.9-dev (current SVN)
 Reporter: vincent Demay
 Assignee: Jean-Baptiste Quenot
  Fix For: 2.1.9-dev (current SVN)


 When a file is selected with the upload widget and a on-value-change event is 
 fired, the value of the widget can not be changed by user.
 here is the patch
 Index: 
 /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
 ===
 --- 
 /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
(revision 377974)
 +++ 
 /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
(working copy)
 @@ -486,7 +486,7 @@
  xsl:text[/xsl:text
  xsl:value-of select=fi:value/
  xsl:text] /xsl:text
 -input type=button id=[EMAIL PROTECTED]:input name=[EMAIL 
 PROTECTED] value=... onclick=forms_submitForm(this)/
 +   input type=submit id=[EMAIL PROTECTED]:input name=[EMAIL 
 PROTECTED] value=... onclick=forms_submitForm(this)/
  /xsl:when
  xsl:otherwise
input type=file id=[EMAIL PROTECTED]:input name=[EMAIL 
 PROTECTED] title={fi:hint} accept=[EMAIL PROTECTED]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Forms broken on IE

2006-02-22 Thread Bruno Dumon

Hi,

With latest SVN (2_1_x branch), CForms gives a javascript error on IE6.
This happens whenever I click somewhere on the page (doesn't matter
where: in a blank area or an input field).

The cause is that in dojo's HtmlDragManager.js, on line 185, the 'e'
variable is undefined:

  onMouseUp: function(e){
this.mouseDownX = null;
this.mouseDownY = null;
this._dragTriggered = false;
var _this = this;
e.preventDefault();   === e undefined

Maybe some of you who follow up dojo development know if this is already
fixed or if the problem is caused by us.

TIA

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

[jira] Commented: (COCOON-1780) [PATCH] Upload Widget : Can not change selected file

[ 
http://issues.apache.org/jira/browse/COCOON-1780?page=comments#action_12367344 
] 

Bruno Dumon commented on COCOON-1780:
-

Hi Vincent,

It's not really useless code, since it allows more flexibility in rendering. 
For example, it would allow to use the HTML button tag, allowing to put an 
image on the button.

The way I've fixed the Upload widget follows the same pattern as the other 
widgets do, such as Action. In fact, I looked a bit too much at the Action 
widget and that's why I got it wrong the first time.

 [PATCH] Upload Widget : Can not change selected file
 

  Key: COCOON-1780
  URL: http://issues.apache.org/jira/browse/COCOON-1780
  Project: Cocoon
 Type: Bug
   Components: Blocks: Forms
 Versions: 2.2-dev (Current SVN), 2.1.9-dev (current SVN)
 Reporter: vincent Demay
 Assignee: Jean-Baptiste Quenot
  Fix For: 2.1.9-dev (current SVN)


 When a file is selected with the upload widget and a on-value-change event is 
 fired, the value of the widget can not be changed by user.
 here is the patch
 Index: 
 /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
 ===
 --- 
 /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
(revision 377974)
 +++ 
 /cvs/cocoon/cocoon_BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
(working copy)
 @@ -486,7 +486,7 @@
  xsl:text[/xsl:text
  xsl:value-of select=fi:value/
  xsl:text] /xsl:text
 -input type=button id=[EMAIL PROTECTED]:input name=[EMAIL 
 PROTECTED] value=... onclick=forms_submitForm(this)/
 +   input type=submit id=[EMAIL PROTECTED]:input name=[EMAIL 
 PROTECTED] value=... onclick=forms_submitForm(this)/
  /xsl:when
  xsl:otherwise
input type=file id=[EMAIL PROTECTED]:input name=[EMAIL 
 PROTECTED] title={fi:hint} accept=[EMAIL PROTECTED]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1780) [PATCH] Upload Widget : Can not change selected file