Re: auto generation of blocks.properties

[Upayavira]

Joerg Heinicke wrote:

Hello guys,

last week there was again a thread about binary dists or at least 
about simplifying the build on the users list:

http://marc.theaimsgroup.com/?t=10681742141&r=1&w=2

The original reason were Alexander's problems with the CLI: it is/was 
not usable with the authentication-fw block. Further dependencies were 
not in the blocks.properties and so he became frustrated.

One solution for him where different blocks.properties for different 
use cases. Another solution IMO are the complete dependencies in our 
blocks.properties. But maintaining both gump.xml and blocks.properties 
is a pain. The solution is to have one file and to generate the other 
one. I wrote a stylesheet doing this from gump.xml, find it attached 
(after problems with Xalan).

The question is how to integrate it exactly into the build. Only as a 
helper target? Only for developers before committing gump.xml? As one 
of the first steps in the build, i.e. blocks.properties is removed 
from the CVS and it's only generated dynamically?

Furthermore the gump.xml project/@status must be completed 
(status="stable" and stable="deprecated").

I hope you will find it useful. Any comments?
I'd say in two ways:
(1) as a task anyone can run at their leasure: build blocks-properties
and
(2) as a part of the release process - so that releases always have a 
correct blocks-properties.

That way, developers have the responsibility to create a 
blocks-properites file for themselves, but users get one ready made. If 
someone starts using CVS, they need to look out for this.

Does your blocks.properties include dependency info and descriptions of 
the blocks themselves?

Otherwise, I think this is great, and much needed (and will no our 
users, and gump, no harm at all!)

Regards, Upayavira

Re: [vote] forbidding flowscripts with no sendpage redirects (was Re: Saving pipeline output to a temp file...)

[Bertrand Delacretaz]

Do you want to enforce the fact that flowscript calls (either 
"function" or "continuation") *must* redirect using sendPage, 
sendPageAndWait or redirectTo and that, should it not be the case, a 
ProcessingException be raised?

[ ] no, let the sitemap execution continue after the  if 
there was no redirect.
[X ] yes, enforce it in 2.1.3
[ ] yes, enforce it in 2.1.4
- Bertrand

Re: whitespace cleanup and efficiency drive

[Bertrand Delacretaz]

Le Lundi, 10 nov 2003, à 16:56 Europe/Zurich, David Crossley a écrit :

...
Well this is all that this discussion really set out to achieve:
consistent 4-space indentation, remove all tabs, get rid of other
spurious whitespace. So, yes, let us stop at that.
+1, keep it simple!

IIUC the whole point is to have easy to work with CVS diffs, the rest 
is largely personal taste, mostly impossible to agree on.

"diff -b" also helps ignore "reasonable" whitespace differences.

-Bertrand

Re: auto generation of blocks.properties

[Bertrand Delacretaz]

Le Mardi, 11 nov 2003, à 00:20 Europe/Zurich, Joerg Heinicke a écrit :

...Another solution IMO are the complete dependencies in our 
blocks.properties. But maintaining both gump.xml and blocks.properties 
is a pain. The solution is to have one file and to generate the other 
one
+1, actually this info should come from the blocks directly (metadata), 
but this is for later...

I like the idea of generating blocks.properties from gump.xml.

I'd just add a prominent notice at the beginning of the generated 
blocks.properties: "autogenerated - do not edit" or something.

-Bertrand

Re: [IMP] Code Freeze

[Bertrand Delacretaz]

Le Mardi, 11 nov 2003, à 00:15 Europe/Zurich, David Crossley a écrit :
...#24463 is a patch for the Petstore sample which would be
excellent to have in the 2.1.3 release. It does fix
a lot of bugs and incomplete facilities. It also begins
to use Woody. Also it is "only" a Sample.
If people are happy, then i am ready to commit it on
Wednesday Europe morning...
+1, it is "only" a sample, it won't break anything critical. Thanks for 
this.

-Bertrand

RE: [IMP] Code Freeze

[Reinhard Poetz]

From: David Crossley

> Carsten Ziegeler wrote:
> > starts tonight - release is (hopefully) on thursday.
> 
> As discussed in Bug 24463 [1] i am still not clear about
> what is meant by "freeze". I presume that it is the core
> and some fundamental blocks that are intended to be frozen.
> 
> #24463 is a patch for the Petstore sample which would be 
> excellent to have in the 2.1.3 release. It does fix a lot of 
> bugs and incomplete facilities. It also begins to use Woody. 
> Also it is "only" a Sample.
> 
> If people are happy, then i am ready to commit it on
> Wednesday Europe morning.
> 
> [1]
> [PATCH] Petstore sample: bug fixes + completions 
> http://nagoya.apache.org/bugzilla/show_> bug.cgi?id=24463

+1 because the Petstore example has some bugs here and there and this
patch will solve those issues (at least this is my impression when I
read Leo's mails). Those issues also were the reason why I marked the
Petstore block as unstable - if they are solved we can think about
moving it into the 'stable' section after the release.

--
Reinhard

Re: [vote] forbidding flowscripts with no sendpage redirects (was Re: Saving pipeline output to a temp file...)

[Joerg Heinicke]

On 10.11.2003 21:15, Sylvain Wallez wrote:
Let's reformulate this into a proper vote.

Do you want to enforce the fact that flowscript calls (either "function" 
or "continuation") *must* redirect using sendPage, sendPageAndWait or 
redirectTo and that, should it not be the case, a ProcessingException be 
raised?

[ ] no, let the sitemap execution continue after the  if there 
was no redirect.
[X] yes, enforce it in 2.1.3
[ ] yes, enforce it in 2.1.4
If it's not to complicated to enforce, i.e. if it does not possibly 
break other code.

Joerg

Re: auto generation of blocks.properties

[Joerg Heinicke]

On 11.11.2003 08:29, Upayavira wrote:

The solution is to have one file and to generate the other 
one. I wrote a stylesheet doing this from gump.xml, find it attached 
(after problems with Xalan).

The question is how to integrate it exactly into the build. Only as a 
helper target? Only for developers before committing gump.xml? As one 
of the first steps in the build, i.e. blocks.properties is removed 
from the CVS and it's only generated dynamically?

Furthermore the gump.xml project/@status must be completed 
(status="stable" and stable="deprecated").

I hope you will find it useful. Any comments?


I'd say in two ways:
(1) as a task anyone can run at their leasure: build blocks-properties
and
(2) as a part of the release process - so that releases always have a 
correct blocks-properties.

That way, developers have the responsibility to create a 
blocks-properites file for themselves, but users get one ready made. If 
someone starts using CVS, they need to look out for this.

Does your blocks.properties include dependency info and descriptions of 
the blocks themselves?
Of course dependency info, that was the reason for doing it - and we 
have a lot of dependencies of you look at the result, much more than 
there were mentioned in the blocks.properties until now.

I don't like the idea of having block descriptions also in the 
blocks.properties. This makes the file unreadable. With the dependencies 
it's already "full".

Otherwise, I think this is great, and much needed (and will no our 
users, and gump, no harm at all!)
Ok, I will commit it soon as helper target.

Joerg

Re: auto generation of blocks.properties

[Joerg Heinicke]

On 11.11.2003 08:56, Bertrand Delacretaz wrote:

Le Mardi, 11 nov 2003, à 00:20 Europe/Zurich, Joerg Heinicke a écrit :

...Another solution IMO are the complete dependencies in our 
blocks.properties. But maintaining both gump.xml and blocks.properties 
is a pain. The solution is to have one file and to generate the other 
one


+1, actually this info should come from the blocks directly (metadata), 
but this is for later...
This stylesheet was especially for the time we don't have the "real" 
blocks. But of course maybe we can have some intermediate, i.e. a time 
where we have the blocks, but not the block deployer. There another 
stylesheet can also help.

I like the idea of generating blocks.properties from gump.xml.

I'd just add a prominent notice at the beginning of the generated 
blocks.properties: "autogenerated - do not edit" or something.
This depends. If it is only a helper target it will be called on demand. 
It would be the same as a committer is editing the blocks.properties and 
commits it. Now he needs not to edit it by hand but generate it 
automatically.

It's another issue if it is deeper integrated into the build process. 
Remove blocks.properties from CVS, starting the generation on the first 
build, later on it will be updated after an update on gump.xml, the user 
get's again it local.blocks.properties and *must* change the blocks 
deployment there. But how to keep it in sync? Adding a warning on the 
screen if the blocks.properties is newer than local.blocks.properties?

It's not easy as you can see. It's also only a temporary solution.

Joerg

Re: whitespace cleanup and efficiency drive

[David Crossley]

Bertrand Delacretaz wrote:
> David Crossley a écrit :
> 
> > ...
> > Well this is all that this discussion really set out to achieve:
> > consistent 4-space indentation, remove all tabs, get rid of other
> > spurious whitespace. So, yes, let us stop at that.
> 
> +1, keep it simple!
> 
> IIUC the whole point is to have easy to work with CVS diffs,

YDUC ... You Do Understand Correctly.

> the rest 
> is largely personal taste, mostly impossible to agree on.
> 
> "diff -b" also helps ignore "reasonable" whitespace differences.

I learn something every minute.

--David

Re: auto generation of blocks.properties

[Bertrand Delacretaz]

Le Mardi, 11 nov 2003, à 10:30 Europe/Zurich, Joerg Heinicke a écrit :

On 11.11.2003 08:56, Bertrand Delacretaz wrote:

Le Mardi, 11 nov 2003, à 00:20 Europe/Zurich, Joerg Heinicke a écrit :
...Another solution IMO are the complete dependencies in our 
blocks.properties. But maintaining both gump.xml and 
blocks.properties is a pain. The solution is to have one file and to 
generate the other one
+1, actually this info should come from the blocks directly 
(metadata), but this is for later...
This stylesheet was especially for the time we don't have the "real" 
blocks...
Sure - your (temporary, as you mention) solution is fine for now IMHO.

...
I'd just add a prominent notice at the beginning of the generated 
blocks.properties: "autogenerated - do not edit" or something.
This depends. If it is only a helper target it will be called on 
demand. It would be the same as a committer is editing the 
blocks.properties and commits it. Now he needs not to edit it by hand 
but generate it automatically.
IIUC the scenario when there is a change in block info would be:

1. update gump.xml
2. generate blocks.properties from gump.xml (using helper build target)
3. commit both gump.xml and blocks.properties
Is that what you mean?

In this case a warning is needed in blocks.properties, to describe how 
to correctly handle it.
And a warning in gump.xml, to remind people to regenerate 
blocks.properties upon changes.
Might be ok for a temp solution, gump.xml does not change that often.

...It's another issue if it is deeper integrated into the build 
process. Remove blocks.properties from CVS, starting the generation on 
the first build, later on it will be updated after an update on 
gump.xml, the user get's again it local.blocks.properties and *must* 
change the blocks deployment there. But how to keep it in sync? Adding 
a warning on the screen if the blocks.properties is newer than 
local.blocks.properties?
Not sure what you mean by "keep it in sync", Isn't this the same 
problem as now?
Currently if blocks.properties changes, I have to do a diff with my 
local.blocks.properties to see what happened.

-Bertrand

RE: [vote] forbidding flowscripts with no sendpage redirects (was Re: Saving pipeline output to a temp file...)

[Unico Hommes]

I am still learing to vote properly ;-)

Sylvain Wallez wrote:
> Let's reformulate this into a proper vote.
> 
> Do you want to enforce the fact that flowscript calls (either 
> "function" 
> or "continuation") *must* redirect using sendPage, 
> sendPageAndWait or redirectTo and that, should it not be the 
> case, a ProcessingException be raised?
> 

As my previous vote was a bit unclear, this *is* my vote:

 [ ] no, let the sitemap execution continue after the 
  if there was no redirect.
 [X] yes, enforce it in 2.1.3
 [ ] yes, enforce it in 2.1.4

Unico

GT 2003 talks: audio only example, please test

[Bertrand Delacretaz]

A while ago there were requests to provide the GT2003 presentations as 
low-bandwidth audio only.

I have made a small example with the first minute of Steven's talk, 
could people test it on various platforms before I do the whole thing? 
Please report here indicating platform.

MP3 example file can be found at 
http://www.codeconsult.ch/clients/gt2003/00-introduction.mp3

I've tested it on macosx with ITunes, plays ok, title and copyright are 
shown in the info fields.

Audio quality is, well, lame. I used the phone preset to make these 
files as small as possible (should be about 6MB for a 40-minute talk). 
People with enough bandwidth can get the videos anyway.

Here's how I did it. Never used lame before, suggestions are welcome:

-open movie in QuickTime Pro
-File menu, export, "export audio to WAVE"
-Shorten wave file for this test, using audio editor (Spark ME)
-Use lame to convert to mp3:
  lame --preset phone \
  --add-id3v2 \
  --tt "Cocoon GetTogether 2003, Steven Noels, introduction" \
  --ta "Copyright (C) 2003 Apache Software Foundation" \
  00-introduction.wav \
  00-introduction.mp3
(Tried -tc for copyright but it didn't show in ITunes).

-Bertrand

RE: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/sitemap MountNode.java

[Unico Hommes]

O dear, did I just break the code freeze? Or what does it actually mean
a code freeze? (Still not clear after discussion on the other thread)
Does it include changes like this?

Actually this could have waited 'till after the release. I just forgot.

Sorry about this.

Unico

> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: dinsdag 11 november 2003 11:31
> To: [EMAIL PROTECTED]
> 
> unico   2003/11/11 02:31:04
> 
>   Modified:
> src/java/org/apache/cocoon/components/treeprocessor/sitemap
> MountNode.java
>   Log:
>   fix line break
>   
>   Revision  ChangesPath
>   1.9   +3 -2  
> cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor
> /sitemap/MountNode.java
>   
>   Index: MountNode.java
>   ===
>   RCS file: 
> /home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/tre
> eprocessor/sitemap/MountNode.java,v
>   retrieving revision 1.8
>   retrieving revision 1.9
>   diff -u -r1.8 -r1.9
>   --- MountNode.java  7 Nov 2003 12:51:38 -   1.8
>   +++ MountNode.java  11 Nov 2003 10:31:04 -  1.9
>   @@ -92,7 +92,8 @@
>/** The component manager to be used by the mounted 
> processor */
>private ComponentManager manager;
>
>   -public MountNode(VariableResolver prefix, 
> VariableResolver source, String language, TreeProcessor 
> parentProcessor) {this.prefix = prefix;
>   +public MountNode(VariableResolver prefix, 
> VariableResolver source, String language, TreeProcessor 
> parentProcessor) {
>   +this.prefix = prefix;
>this.source = source;
>this.language = language;
>this.parentProcessor = parentProcessor;
>   
>   
>   
> 
> 

Re: GT 2003 talks: audio only example, please test

[Antonio Gallardo]

Bertrand Delacretaz dijo:
> A while ago there were requests to provide the GT2003 presentations as
> low-bandwidth audio only.
>
> I have made a small example with the first minute of Steven's talk,
> could people test it on various platforms before I do the whole thing?
> Please report here indicating platform.
>
> MP3 example file can be found at
> http://www.codeconsult.ch/clients/gt2003/00-introduction.mp3
>
> I've tested it on macosx with ITunes, plays ok, title and copyright are
> shown in the info fields.

Hi Bertrand:

Nice effort. I think people with low bandwith will welcome this new
presentation of the conferences. I already tested it on my Fedora Core 1
(yes!, the new one from Red Hat!) :-D

BTW, Cocoon shine in this OS too.

The MP3 sounds good and comprehensible. XMMS reports me: 16Kbps, 11KHz. Mono.

I think it is OK.

Best Regards,

Antonio Gallardo

Re: GT 2003 talks: audio only example, please test

[Torsten Curdt]

I have made a small example with the first minute of Steven's talk, 
could people test it on various platforms before I do the whole thing? 
Please report here indicating platform.

MP3 example file can be found at 
http://www.codeconsult.ch/clients/gt2003/00-introduction.mp3

I've tested it on macosx with ITunes, plays ok, title and copyright are 
shown in the info fields.
Same on windows with winamp

Audio quality is, well, lame. I used the phone preset to make these 
files as small as possible (should be about 6MB for a 40-minute talk). 
For low quality audio ogg is supposed to be much better.

WDYT

Cheers
--
Torsten

Re: GT 2003 talks: audio only example, please test

[Bertrand Delacretaz]

Le Mardi, 11 nov 2003, à 12:09 Europe/Zurich, Torsten Curdt a écrit :
...For low quality audio ogg is supposed to be much better.
Does it play "everywhere" without requiring special software?
Otherwise I think the accessibility of mp3 is better.
-Bertrand

Re: GT 2003 talks: audio only example, please test

[Antonio Gallardo]

Bertrand Delacretaz dijo:
> Le Mardi, 11 nov 2003, à 12:09 Europe/Zurich, Torsten Curdt a écrit :
>> ...For low quality audio ogg is supposed to be much better.
>
> Does it play "everywhere" without requiring special software?
> Otherwise I think the accessibility of mp3 is better.

I would prefer ogg because MP3 has copyright issues.

Best Regards,

Antonio Gallardo

Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/sitemap MountNode.java

[Joerg Heinicke]

Unico Hommes wrote:
O dear, did I just break the code freeze? Or what does it actually mean
a code freeze? (Still not clear after discussion on the other thread)
Does it include changes like this?
Actually this could have waited 'till after the release. I just forgot.

Sorry about this.
I think absolutely no problem. It's only about "things, that may break other 
stuff". The code freeze period should in theory be used for tests if 
everything works ok. If not, fixes can be committed. The quality of the code 
base shell "in guarantee" not decrease in the code freeze period.

Joerg

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: dinsdag 11 november 2003 11:31
To: [EMAIL PROTECTED]

unico   2003/11/11 02:31:04

 Modified:
src/java/org/apache/cocoon/components/treeprocessor/sitemap
   MountNode.java
 Log:
 fix line break
 
 Revision  ChangesPath
 1.9   +3 -2  
cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor
/sitemap/MountNode.java
 
 Index: MountNode.java
 ===
 RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/tre
eprocessor/sitemap/MountNode.java,v
 retrieving revision 1.8
 retrieving revision 1.9
 diff -u -r1.8 -r1.9
 --- MountNode.java	7 Nov 2003 12:51:38 -	1.8
 +++ MountNode.java	11 Nov 2003 10:31:04 -	1.9
 @@ -92,7 +92,8 @@
  /** The component manager to be used by the mounted 
processor */
  private ComponentManager manager;
  
 -public MountNode(VariableResolver prefix, 
VariableResolver source, String language, TreeProcessor 
parentProcessor) {this.prefix = prefix;
 +public MountNode(VariableResolver prefix, 
VariableResolver source, String language, TreeProcessor 
parentProcessor) {
 +this.prefix = prefix;
  this.source = source;
  this.language = language;
  this.parentProcessor = parentProcessor;
--
System Development
VIRBUS AG
Fon  +49(0)341-979-7419
Fax  +49(0)341-979-7409
[EMAIL PROTECTED]
www.virbus.de

RE: Migrating TreeProcessor to Fortress

[Unico Hommes]

 

> 
> -Original Message-
> From: Joerg Heinicke [mailto:[EMAIL PROTECTED] 
> Sent: dinsdag 11 november 2003 0:30
> To: [EMAIL PROTECTED]
> 
> On 10.11.2003 21:27, Unico Hommes wrote:
> 
> > * sitemap-container.xconf:
> > 
> > 
> > 
> >  
> >   
> >   
> >  
> > 
> >  
> >   
> >  
> > 
> >  
> >   
> >  
> > 
> >  
> > 
> >  
> > 
> > 
> 
> Doesn't this id/idref handling fail, if a component is 
> declared only in the parent sitemap and inherited? At least 
> from an XML POV.
> 

Do you mean:

parent.xmap:

  

  

  


child.xmap:

  

  


  

  


?

No this is not a problem because the ServiceManager of the parent
processor acts as the parent to the ServiceManager of the child
processor. The match node will ask the child ServiceManager for the file
generator, and if the child ServiceManager doesn't find it among its own
components it asks the parent ServiceManager for it. This is also how it
is handled today.

The sitemap components will actually be handled a little different from
the pipeline nodes. The above parent.xmap translated into a fortress
configuration will look like:

parent.xconf:

  


And the child.xmap looks like:

child.xconf:

  ...
  
   
  


  



At first I thought you were asking how mount nodes would be handled.
This is not a problem either because the mount node does not need to be
configured with an id to a node in the subsitemap. Its 'src' attribute
identifies the subprocessor and that's all that is needed.


Regards, Unico

Re: [vote] forbidding flowscripts with no sendpage redirects (was Re:Saving pipeline output to a temp file...)

[Stefano Mazzocchi]

On 11 Nov 2003, at 05:47, Antonio Gallardo wrote:

Sylvain Wallez dijo:
Let's reformulate this into a proper vote.

Do you want to enforce the fact that flowscript calls (either 
"function"
or "continuation") *must* redirect using sendPage, sendPageAndWait or
redirectTo and that, should it not be the case, a ProcessingException 
be
raised?

[ ] no, let the sitemap execution continue after the  if 
there
was no redirect.
  [X] yes, enforce it in 2.1.3
[ ] yes, enforce it in 2.1.4
Earlier means less pain in the future.
Agreed, +1

--
Stefano.

Re: [IMP] Code Freeze

[Stefano Mazzocchi]

On 11 Nov 2003, at 08:58, Bertrand Delacretaz wrote:

Le Mardi, 11 nov 2003, à 00:15 Europe/Zurich, David Crossley a écrit :
...#24463 is a patch for the Petstore sample which would be
excellent to have in the 2.1.3 release. It does fix
a lot of bugs and incomplete facilities. It also begins
to use Woody. Also it is "only" a Sample.
If people are happy, then i am ready to commit it on
Wednesday Europe morning...
+1, it is "only" a sample, it won't break anything critical. Thanks 
for this.
Carsten, what is the status of the component proxy? If we have such a 
big memory leak, I think we should get it solved before doing the 
release.

Also note that there seems to be consensus on making Sylvain's 
restricted flowscript calling policy in 2.1.3

These two might just well "unfreeze" the tree? WDYT?

--
Stefano.

Re: GT 2003 talks: audio only example, please test

[Stefano Mazzocchi]

On 11 Nov 2003, at 12:31, Antonio Gallardo wrote:

Bertrand Delacretaz dijo:
Le Mardi, 11 nov 2003, à 12:09 Europe/Zurich, Torsten Curdt a écrit :
...For low quality audio ogg is supposed to be much better.
Does it play "everywhere" without requiring special software?
Otherwise I think the accessibility of mp3 is better.
I would prefer ogg because MP3 has copyright issues.
ehm, patent issues. Different thing.

[bertrand, there is an ogg plugin for iTunes, if you wondered]

--
Stefano.

[woody] validation error messages

[Jeremy Quinn]

Dear All

I noticed that when you use something like :

form.getWidget ("email").setValidationError (
new ValidationError ("validation.email.inuse")
);
then the i18n tag output by setValidationError() looks like this:

	validation.email.inuse

which means that any custom validation errors pretty much have to be 
kept in WoodyMessages which could well be inconvenient 

Is it really necessary for Woody to set the catalogue attribute in this 
situation?

BTW. Is there a plan to add a generic form validation message tag to 
woody?
ie. not tied to a particular field widget.

Thanks

regards Jeremy

Re: [woody] validation error messages

[Antonio Gallardo]

Jeremy Quinn dijo:
> Dear All
>
> I noticed that when you use something like :
>
>   form.getWidget ("email").setValidationError (
>   new ValidationError ("validation.email.inuse")
>   );
>
> then the i18n tag output by setValidationError() looks like this:
>
>   validation.email.inuse
>
> which means that any custom validation errors pretty much have to be
> kept in WoodyMessages which could well be inconvenient 
>
> Is it really necessary for Woody to set the catalogue attribute in this
> situation?

I think Jeremy it is a good practice. Remember not all of us develop for
the english speaking market. In that way i18n is good.

Also I think it is better to have all your error messages in just one file.

Best Regards,

Antonio Gallardo

Re: GT 2003 talks: audio only example, please test

[Jeremy Quinn]

On 11 Nov 2003, at 11:41, Stefano Mazzocchi wrote:

On 11 Nov 2003, at 12:31, Antonio Gallardo wrote:

Bertrand Delacretaz dijo:
Le Mardi, 11 nov 2003, à 12:09 Europe/Zurich, Torsten Curdt a écrit :
...For low quality audio ogg is supposed to be much better.
Does it play "everywhere" without requiring special software?
Otherwise I think the accessibility of mp3 is better.
I would prefer ogg because MP3 has copyright issues.
ehm, patent issues. Different thing.

[bertrand, there is an ogg plugin for iTunes, if you wondered]
I was trying to do lo-res audio re-samples to use them for my SMIL 
Presentation attempt instead of the video which does not seem to play 
for anyone.

I found that Stefano's audio would crash QuickTime if it tried to 
extract or re-sample.

If we are going to decide between MP3 and Ogg, could we test to see if 
Ogg will work with QuickTime and RealPlayer SMIL, as it would be cool 
to re-use them for this purpose too.

regards Jeremy

Re: [woody] validation error messages

[Jeremy Quinn]

On 11 Nov 2003, at 11:53, Antonio Gallardo wrote:

Jeremy Quinn dijo:
Dear All

I noticed that when you use something like :

form.getWidget ("email").setValidationError (
new ValidationError ("validation.email.inuse")
);
then the i18n tag output by setValidationError() looks like this:

	validation.email.inuse

which means that any custom validation errors pretty much have to be
kept in WoodyMessages which could well be inconvenient 
Is it really necessary for Woody to set the catalogue attribute in 
this
situation?
I think Jeremy it is a good practice. Remember not all of us develop 
for
the english speaking market. In that way i18n is good.
I am not worried about i18n per sé, but the forced usage of the 'woody' 
catalogue for what might be non-woody messages.

ie.  'validation.email.inuse' is a custom message for my app, not one 
built-in to woody.

However, I am forced to keep it in WoodyMessages (or a catalog called 
'woody' in the sitemap) because it automatically has the 
'catalogue="woody"' attribute added to it when you use 
setValidationError, which AFAIU you would use mainly for extra-woody 
validation.

Also I think it is better to have all your error messages in just one 
file.
I disagree . with Woody progressing at such a pace, my feelings are 
that it should be possible to statically include the WoodyMessages for 
built-in components (as a fall-back), while being able to over-ride 
specific messages from your own application messages catalogue. (As the 
Woody Samples do with "OtherMessages").

This way different collections of forms can use different message 
catalogues, but still have the built-in WoodyMessages as a fallback.

I hope that is a bit clearer ;)

regards jeremy

Petstore Sample updated, please test

[David Crossley]

Many thanks to Leo Leonid for the important patch which
updates the Petstore Sample to use our Woody Forms and Flow
and other various dogfood. Many things are fixed and polished.

Please follow the relevant parts of the Bugzilla report, where
Leo has expressed some concerns. Especially please review the
flow stuff.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24463

--David

DO NOT REPLY [Bug 24463] - [PATCH] Petstore sample: bug fixes + completions

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24463

[PATCH] Petstore sample: bug fixes + completions

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-11-11 12:20 ---
Okay, it is in the 2.1 cvs now. Everyone please review ASAP, and see the notes
in this Bug report.
--David

Re: GT 2003 talks: audio only example, please test

[Antonio Gallardo]

Jeremy Quinn dijo:
> I was trying to do lo-res audio re-samples to use them for my SMIL
> Presentation attempt instead of the video which does not seem to play
> for anyone.

Hi Jeremy:

Why you said that

I played the videos on Red Hat 9 and Fedora 1 without problems. I used
Xine. BTW, the videos are very fine. It helps us to taste even better what
happened in GT2003. We also did a private presentation of the videos at
the office. I also give copies of them to all my co-workers.

Best Regards,

Antonio Gallardo

Re: GT 2003 talks: audio only example, please test

[Jeremy Quinn]

On 11 Nov 2003, at 12:25, Antonio Gallardo wrote:

Jeremy Quinn dijo:
I was trying to do lo-res audio re-samples to use them for my SMIL
Presentation attempt instead of the video which does not seem to play
for anyone.
Hi Jeremy:

Why you said that

I played the videos on Red Hat 9 and Fedora 1 without problems. I used
Xine. BTW, the videos are very fine. It helps us to taste even better 
what
happened in GT2003. We also did a private presentation of the videos at
the office. I also give copies of them to all my co-workers.
I understood that the videos work fine if you download them before 
playing, but AFAIU no-one was able to get them to play properly when 
they were included as part of a SMIL Presentation.

regards Jeremy

Re: GT 2003 talks: audio only example, please test

[David Crossley]

Bertrand Delacretaz wrote:
> A while ago there were requests to provide the GT2003 presentations as 
> low-bandwidth audio only.
> 
> I have made a small example with the first minute of Steven's talk, 
> could people test it on various platforms before I do the whole thing? 
> Please report here indicating platform.

Brilliant. Thanks a million.

No problems with "noatun" on Linux. But "xmms" complained
about patent issues with MP* and refused to let him speak.

--David

DO NOT REPLY [Bug 24571] - Content-Length header missing

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24571

Content-Length header missing





--- Additional Comments From [EMAIL PROTECTED]  2003-11-11 12:53 ---
Maybe we could provide a configuration option for this in AbstractTextSerializer
or AbstractSerializer?

Re: GT 2003 talks: audio only example, please test

[Bertrand Delacretaz]

Le Mardi, 11 nov 2003, à 12:41 Europe/Zurich, Stefano Mazzocchi a écrit 
:
On 11 Nov 2003, at 12:31, Antonio Gallardo wrote:

Bertrand Delacretaz dijo:
Le Mardi, 11 nov 2003, à 12:09 Europe/Zurich, Torsten Curdt a écrit :
...For low quality audio ogg is supposed to be much better.
Does it play "everywhere" without requiring special software?
Otherwise I think the accessibility of mp3 is better.
I would prefer ogg because MP3 has copyright issues.
ehm, patent issues. Different thing.
The deal here is to make the talks as accessible as possible: make low 
bandwidth downloads possible and use a plain vanilla format, hence my 
choice of mp3.

But I'm ok to prepare both ogg and mp3 formats once I'm at it, can 
anyone recommend a good ogg encoder for macosx?

[bertrand, there is an ogg plugin for iTunes, if you wondered]
Thanks for the tip.

-Bertrand

Re: [vote] forbidding flowscripts with no sendpage redirects (was Re:Saving pipeline output to a temp file...)

[Vadim Gritsenko]

Stefano Mazzocchi wrote:

On 11 Nov 2003, at 05:47, Antonio Gallardo wrote:

Sylvain Wallez dijo:

Let's reformulate this into a proper vote.

Do you want to enforce the fact that flowscript calls (either 
"function"
or "continuation") *must* redirect using sendPage, sendPageAndWait or
redirectTo and that, should it not be the case, a 
ProcessingException be
raised?

[ ] no, let the sitemap execution continue after the  if 
there
was no redirect.
  [X] yes, enforce it in 2.1.3

[ ] yes, enforce it in 2.1.4


Earlier means less pain in the future.


Agreed, +1


I'm -0 on "yes, enforce". Not sure why it should be disabled.

Vadim

Re: [woody] validation error messages

[Ugo Cei]

Jeremy Quinn wrote:
I disagree . with Woody progressing at such a pace, my feelings are 
that it should be possible to statically include the WoodyMessages for 
built-in components (as a fall-back), while being able to over-ride 
specific messages from your own application messages catalogue. (As the 
Woody Samples do with "OtherMessages").
By the way, would it be possible to read the default catalog from a 
resource (i.e. from cocoon-woody-block.jar) instead of copying them from 
the samples?

	Ugo

--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: [EMAIL PROTECTED]

[GT2003] cannot play 20-town-hall.avi video

[Bertrand Delacretaz]

I downloaded this video from two different mirror locations but neither 
does work here (macosx 10.2.8, tried with QuickTime and Windows Media 
Player), QuickTime says "program error" and WMP says "wrong format".

Does it work for others? The MD5 of the file that I have is

b6d698b4d4f98c38d5e382a9e3f82d61  20-town-hall.avi

-Bertrand

Re: [GT2003] cannot play 20-town-hall.avi video

[Antonio Gallardo]

Bertrand Delacretaz dijo:
> I downloaded this video from two different mirror locations but neither
> does work here (macosx 10.2.8, tried with QuickTime and Windows Media
> Player), QuickTime says "program error" and WMP says "wrong format".
>
> Does it work for others? The MD5 of the file that I have is
>
> b6d698b4d4f98c38d5e382a9e3f82d61  20-town-hall.avi

The same here. I played it. Check the archives I think somebody post how
to view the video on Win32.

Best Regards,

Antonio Gallardo

Re: [GT2003] cannot play 20-town-hall.avi video

[Steven Noels]

Bertrand Delacretaz wrote:

I downloaded this video from two different mirror locations but neither 
does work here (macosx 10.2.8, tried with QuickTime and Windows Media 
Player), QuickTime says "program error" and WMP says "wrong format".
IIRC, the MacOSX port of mplayer did work on all files.


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java & XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

Re: [woody] validation error messages

[Sylvain Wallez]

Jeremy Quinn wrote:

Dear All

I noticed that when you use something like :

form.getWidget ("email").setValidationError (
new ValidationError ("validation.email.inuse")
);
then the i18n tag output by setValidationError() looks like this:

validation.email.inuse


Note that you can also use the second constructor which specifies if the 
string is an i18n key or the final message, i.e.:
new ValidationError("Bad input!", false);

which means that any custom validation errors pretty much have to be 
kept in WoodyMessages which could well be inconvenient 


Sure, you're right.

Is it really necessary for Woody to set the catalogue attribute in 
this situation?


I would say no, but I'm not very aware of the multicatalogue i18n 
features. Isn't it possible to specify no attribute and have the i18n 
transformer search all declared catalogues?

BTW. Is there a plan to add a generic form validation message tag to 
woody? ie. not tied to a particular field widget.


A widget that would collect all error messages? IIRC, this has been 
discussed.

Sylvain

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

Re: GT 2003 talks: audio only example, please test

[Steven Noels]

David Crossley wrote:

No problems with "noatun" on Linux. But "xmms" complained
about patent issues with MP* and refused to let him speak.
Now we're getting there: software-driven patent law abuse detection. :-)


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java & XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

DO NOT REPLY [Bug 24463] - [PATCH] Petstore sample: bug fixes + completions

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24463

[PATCH] Petstore sample: bug fixes + completions

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2003-11-11 13:34 ---
On my macosx / jdk 1.4.1 system, the "List Price" and "Total Cost" columns of
the cart show $NaN instead of the correct values, as soon as I add something to
the cart, if using the Jexl or JXPath views.

Same problem on the checkout page.

Velocity and XSP views are ok.

Re: GT 2003 talks: audio only example, please test

[Torsten Curdt]

David Crossley wrote:

Bertrand Delacretaz wrote:

A while ago there were requests to provide the GT2003 presentations as 
low-bandwidth audio only.

I have made a small example with the first minute of Steven's talk, 
could people test it on various platforms before I do the whole thing? 
Please report here indicating platform.


Brilliant. Thanks a million.

No problems with "noatun" on Linux. But "xmms" complained
about patent issues with MP* and refused to let him speak.
IIRC there is a plugin available that will bring
back MP* on xmms. Sorry, no link at hand...
cheers
--
Torsten

Re: [woody] validation error messages

[Sylvain Wallez]

Ugo Cei wrote:

Jeremy Quinn wrote:

I disagree . with Woody progressing at such a pace, my feelings 
are that it should be possible to statically include the 
WoodyMessages for built-in components (as a fall-back), while being 
able to over-ride specific messages from your own application 
messages catalogue. (As the Woody Samples do with "OtherMessages").


By the way, would it be possible to read the default catalog from a 
resource (i.e. from cocoon-woody-block.jar) instead of copying them 
from the samples?


Yep. I was also thinking of moving the default styling XSLs in the jar 
for the same reason.

Sylvain

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

Re: [GT2003] cannot play 20-town-hall.avi video

[Martijn Bouterse]

Bertrand Delacretaz wrote:

I downloaded this video from two different mirror locations but neither 
does work here (macosx 10.2.8, tried with QuickTime and Windows Media 
Player), QuickTime says "program error" and WMP says "wrong format".

Does it work for others? The MD5 of the file that I have is

b6d698b4d4f98c38d5e382a9e3f82d61  20-town-hall.avi
GSpot[1] says about this file:

"
This is an invalid AVI file due to corruption of the data in the header. 
 This is a serious problem, and this file is not likely to playable

Details: While processing chunk /RIFF:AVI , found bad length value 8822 
at file offset 0x0010
"

Then I tried to open it with VirtualDub[2]. VirtualDub reported that the 
index block was missing and reconstructed it using a file scan. I 
re-saved the file and GSpot reported the following:

"
 DirectShow claims to be able to play the file. The following 
combination of filters were used:

 {C:\temp\cocoon\20-town-hall_resave.avi} (Source)
 {AVI Splitter} (Splitter)
 {DivX Decoder Filter} (Video Decoder)
 {Video Renderer} (Video Renderer)
 {MPEG Layer-3 Decoder} (Audio Decoder)
 {Default WaveOut Device} (Audio Renderer)
"
So that's the trick and the new file played happily :-).

HTH, HAND

Martijn Bouterse

[1] http://www.headbands.com/gspot/
[2] http://www.virtualdub.org/index

Re: [woody] validation error messages

[Jeremy Quinn]

On 11 Nov 2003, at 13:27, Sylvain Wallez wrote:

Jeremy Quinn wrote:

Dear All

I noticed that when you use something like :

form.getWidget ("email").setValidationError (
new ValidationError ("validation.email.inuse")
);
then the i18n tag output by setValidationError() looks like this:

validation.email.inuse


Note that you can also use the second constructor which specifies if 
the string is an i18n key or the final message, i.e.:
new ValidationError("Bad input!", false);
andnew ValidationError("some.message.key", true);

:)


which means that any custom validation errors pretty much have to be 
kept in WoodyMessages which could well be inconvenient 


Sure, you're right.

Is it really necessary for Woody to set the catalogue attribute in 
this situation?


I would say no, but I'm not very aware of the multicatalogue i18n 
features.
I got this pattern from the Woody Samples, the sitemap is set up to use 
the "OtherMessages" catalogue as default, with the WoddyMessages 
catalogue as fallback, though currently "OtherMessages" is empty.

Isn't it possible to specify no attribute and have the i18n 
transformer search all declared catalogues?
Yes, but  when you use setValidationError the catalogue attribute 
is added automatically, I don't think there is a option to turn this 
off. I have not seen this i18n behaviour on any other bit of Woody.

I am using multiple catalogues, the supplied woody one, which 
unfortunately I now have to copy and modify with my messages output by 
setValidationError, and my Applications catalogues (sitemap default), 
where I put application-specific messages (I have several logical 
groups of forms, each in a separate sitemap, with their own message 
files).

One thing that is confusing, is that custom messages output like this:



validation.password.sameasname



only seem to work when the message is in my application catalogue.
While messages output like this:

form.getWidget ("email").setValidationError (
new ValidationError ("validation.email.notfound", true)
);
only appear to work if the message is in the 'woody' catalogue.

BTW. Is there a plan to add a generic form validation message tag to 
woody? ie. not tied to a particular field widget.


A widget that would collect all error messages? IIRC, this has been 
discussed.
Collect?

Do you mean, collect from all widgets?
Or, collect all messages sent to the form widget (which does not 
currently accept them)?

Thanks

regards Jeremy

WoodyTransformer: radio buttons

[Vadim Gritsenko]

Hey guys,

Has anybody have any suggestions on how to make @required=true, 
, widget make less ugly? Currently it 
looks like:
  (   ) Label for the first radio button
  ( o ) Second
  (   ) Third *
Where * indicates that the widget is required, but is higly misleading 
because it is attached to the third radio button.

I came up with several workarounds:
1) Change how woody transformer transformrms wt:widget-labels.
Currently, validation error messages and @required attribute are present 
only on wi:field (and similar elements). And wt:widget-label disappears 
completely, replaced by the content of the label. Instead, it can 
replace wt:widget-label with wi:widget-label, which has validation 
messages and required attribute. This way, you have more flexibility in 
styling the form, including placing of error messages.

2) Do not use woody-field-styling.xsl at all; roll your own... wi:field 
has all the necessary data.

3) Make woody-field-styling.xsl more flexible: divide field styling into 
several steps (using mode="" attribute on templates)

4) Ask list for other suggestions :)

BTW, is anybody against replacing  with  ? It's not possible to override in the including 
stylesheet named templates, but you can override match="" templates.

Vadim

Re: [woody] validation error messages

[Bruno Dumon]

On Tue, 2003-11-11 at 12:47, Jeremy Quinn wrote:
> Dear All
> 
> I noticed that when you use something like :
> 
>   form.getWidget ("email").setValidationError (
>   new ValidationError ("validation.email.inuse")
>   );
> 
> then the i18n tag output by setValidationError() looks like this:
> 
>   validation.email.inuse
> 
> which means that any custom validation errors pretty much have to be 
> kept in WoodyMessages which could well be inconvenient 
> 
> Is it really necessary for Woody to set the catalogue attribute in this 
> situation?

Yes and no. The reason is historical: ValidationErrors were only created
by Woody classes themselves, so all their messages would come from the
woody catalogue.

Now that setValidationError is a public method, it is indeed necessary
to add some more flexibility to the ValidationError class.

> 
> BTW. Is there a plan to add a generic form validation message tag to 
> woody?
> ie. not tied to a particular field widget.

As Sylvain also replied, this has been brought up already, even as
recently as a couple of days ago on the user mailing list:

http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=106821138010096&w=2

I suppose you should know since you even replied to it ;-)

I've actually implemented it already but I want to clean up some other
things first before committing it.

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

Re: [woody] validation error messages

[Bruno Dumon]

Concerning the i18n confusion, it's probably best to read the i18n
transformer docs, though it's quite simple: a message is retrieved from
the catalogue you specify, and if no catalogue is specified, it is
retrieved from the default catalogue (which is specified in the
configuration of the i18n transformer).

On Tue, 2003-11-11 at 15:03, Jeremy Quinn wrote:

> >> BTW. Is there a plan to add a generic form validation message tag to 
> >> woody? ie. not tied to a particular field widget.
> >
> >
> > A widget that would collect all error messages? IIRC, this has been 
> > discussed.
> 
> Collect?

Ah yes, that still something else. An example of this was also posted to
the user mailing list:
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=106820190901404&w=2

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

Re: [woody] validation error messages

[Jeremy Quinn]

On 11 Nov 2003, at 14:15, Bruno Dumon wrote:

On Tue, 2003-11-11 at 12:47, Jeremy Quinn wrote:
Dear All

I noticed that when you use something like :

form.getWidget ("email").setValidationError (
new ValidationError ("validation.email.inuse")
);
then the i18n tag output by setValidationError() looks like this:

	validation.email.inuse

which means that any custom validation errors pretty much have to be
kept in WoodyMessages which could well be inconvenient 
Is it really necessary for Woody to set the catalogue attribute in 
this
situation?
Yes and no. The reason is historical: ValidationErrors were only 
created
by Woody classes themselves, so all their messages would come from the
woody catalogue.
OK

Now that setValidationError is a public method, it is indeed necessary
to add some more flexibility to the ValidationError class.
That would make it easier to re-use "WoodyMessages" now it's being put 
in the .jar.

BTW. Is there a plan to add a generic form validation message tag to
woody?
ie. not tied to a particular field widget.
As Sylvain also replied, this has been brought up already, even as
recently as a couple of days ago on the user mailing list:
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=106821138010096&w=2

I suppose you should know since you even replied to it ;-)
but I was confused as to what was happening about it ...

I've actually implemented it already but I want to clean up some other
things first before committing it.
Cool, many thanks.

regards Jeremy

Re: [vote] forbidding flowscripts with no sendpage redirects (was Re:Saving pipeline output to a temp file...)

[Geoff Howard]

Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:

On 11 Nov 2003, at 05:47, Antonio Gallardo wrote:

Sylvain Wallez dijo:

Let's reformulate this into a proper vote.

Do you want to enforce the fact that flowscript calls (either 
"function"
or "continuation") *must* redirect using sendPage, sendPageAndWait or
redirectTo and that, should it not be the case, a 
ProcessingException be
raised?

[ ] no, let the sitemap execution continue after the  if 
there
was no redirect.
  [X] yes, enforce it in 2.1.3

[ ] yes, enforce it in 2.1.4
Earlier means less pain in the future.
Agreed, +1
I'm -0 on "yes, enforce". Not sure why it should be disabled.
I'm the same.  In fact, I think that flow in some cases needlessly 
complicates the composition of a pipeline.  Now I have to have two 
pipelines where I used to need one.  I have to have one that matches the 
external request and calls the flow function, and another one for the 
default result of that pipeline.  So far this has felt like needless 
additional complexity to me (and I think will to others).

To try to make this point a little clearer:
Part of the beauty of the sitemap prior to flow was that you could at a 
glance see what each request url was triggering.  Now, I look at the 
sitemap, have to locate the flowscript, parse through it for the various 
sendPage etc. and then back to the sitemap to find where the action 
really happens.  This could perhaps be handled with some best practice 
naming conventions.  Perhaps a practice of passing in the various 
possible view uris to the flowscript should be considered.  I don't know.

I'm not negative on flow, and not positive on actions - just pointing 
out a loss of readability of the sitemap that has resulted from our move 
forward.

So actually, I'll say I'm -.5 on the need to enforce this at all.

Geoff

Re: [woody] validation error messages

[Jeremy Quinn]

On 11 Nov 2003, at 14:21, Bruno Dumon wrote:

Concerning the i18n confusion, it's probably best to read the i18n
transformer docs,
I had not picked up on this subtlety.

though it's quite simple: a message is retrieved from
the catalogue you specify, and if no catalogue is specified, it is
retrieved from the default catalogue (which is specified in the
configuration of the i18n transformer).
Oh dear  it is less flexible than I had thought . I had assumed 
it would look in all catalogues setup in the sitemap  this is 
probably the cause of some of the problems I have been having ;)

Thanks for pointing this out.

regards Jeremy


On Tue, 2003-11-11 at 15:03, Jeremy Quinn wrote:

BTW. Is there a plan to add a generic form validation message tag to
woody? ie. not tied to a particular field widget.


A widget that would collect all error messages? IIRC, this has been
discussed.
Collect?
Ah yes, that still something else. An example of this was also posted 
to
the user mailing list:
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=106820190901404&w=2

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

DO NOT REPLY [Bug 23585] - Localton of ev_cache.ser file in DefaultEventRegistryImpl class

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23585

Localton of ev_cache.ser file in DefaultEventRegistryImpl class





--- Additional Comments From [EMAIL PROTECTED]  2003-11-11 15:14 ---
Actually, I initially stayed away from the idea of storing the event info in the
Store/Cache because I hadn't worked out whether there would be "issues" doing so
and the serialization was just a quick solution while I worked that out
mentally.  After you (?) suggested it again in our discussions I went back and
coded a solution that did just that and committed it.  It worked in my initial
tests but there are these outstanding issues which I can't address right now
because of time constraints: 

1) Really test the thing to make sure there are no weird problems.
2) Work out the naming convention mess I created by naming the serializing
solution the "Default".
3) Change the default configuration for the block to use the
StoreEventRegistryImpl instead of the serializing version.

My proposed solution for 2) would be to copy the existing code in
DefaultEventRegistryImpl to a new SerializingEventRegistryImpl, remove all code
from DefaultEventRegistryImpl, make it extend the new Serializing Impl and mark
Default as deprecated.  That may be overkill but would maintain
back-compatibility for anyone already using it and isn't any real work.  

If someone can fully test the new Store version, I can do the rest pretty
quickly.  I'll leave the bug open for now since I can't act right away.

Geoff

DO NOT REPLY [Bug 24463] - [PATCH] Petstore sample: bug fixes + completions

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24463

[PATCH] Petstore sample: bug fixes + completions





--- Additional Comments From [EMAIL PROTECTED]  2003-11-11 16:03 ---
David, looks like the patch is not correclty applied. 
The sitemap looks horrible ATM and is not wellformed. I'm not so experieced creating 
diffs, so I 
ask you to do this better using the the cleaned working copy (id=9020). Apart from the 
images, 
this copy contains everything the app needs, all other stuff can be (re)moved from the 
repositore.
/Leo

Woody: moded templates (Re: WoodyTransformer: radio buttons)

[Joerg Heinicke]

On 11.11.2003 15:15, Vadim Gritsenko wrote:

BTW, is anybody against replacing  with  ? It's not possible to override in the including 
stylesheet named templates, but you can override match="" templates.
Some time ago I also started to do this, but I lost these changes (did I 
do this only in build/webapp and made a buil clean afterwards? :-( ). 
The named templates are not the problem if you use  instead 
of . The real problem are special cases.


  


  
..
..
..
  

while with modes:


  







and now imagein importing this stylesheet in another one. While you have 
to rewrite the complete named template, with the moded stylesheet you 
can overload exactly one special case.

I volunteer doing this!

Joerg

DO NOT REPLY [Bug 24463] - [PATCH] Petstore sample: bug fixes + completions

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24463

[PATCH] Petstore sample: bug fixes + completions





--- Additional Comments From [EMAIL PROTECTED]  2003-11-11 17:11 ---
forget the last comment, probably it was only my local mess. After I deleted petstore 
in my src dir 
and got a new copy from the CVS everythin is fine now.

I wanted to find the problem Bertrand encountered, but I can't reproduce this error on 
my machine 
linux/java 1.4.2. 
/Leo

Re: [woody] validation error messages

[Bruno Dumon]

On Tue, 2003-11-11 at 15:15, Bruno Dumon wrote:
> On Tue, 2003-11-11 at 12:47, Jeremy Quinn wrote:
> > Dear All
> > 
> > I noticed that when you use something like :
> > 
> > form.getWidget ("email").setValidationError (
> > new ValidationError ("validation.email.inuse")
> > );
> > 
> > then the i18n tag output by setValidationError() looks like this:
> > 
> > validation.email.inuse
> > 
> > which means that any custom validation errors pretty much have to be 
> > kept in WoodyMessages which could well be inconvenient 
> > 
> > Is it really necessary for Woody to set the catalogue attribute in this 
> > situation?
> 
> Yes and no. The reason is historical: ValidationErrors were only created
> by Woody classes themselves, so all their messages would come from the
> woody catalogue.
> 
> Now that setValidationError is a public method, it is indeed necessary
> to add some more flexibility to the ValidationError class.

I did some refactorings for this, will commit them after the code
freeze.

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

DO NOT REPLY [Bug 24463] - [PATCH] Petstore sample: bug fixes + completions

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24463

[PATCH] Petstore sample: bug fixes + completions





--- Additional Comments From [EMAIL PROTECTED]  2003-11-11 17:52 ---
Everything works for me after fixing Bertrand's issue with number formatting.

Prices like 155.29 were formatted by the JXTemplate(Transformer | Generator) to
155,29, which XSLT can not handle as numbers. The stylesheet site2html.xsl
should handle the number formatting and I have changed it in this way.

Please further testings.

DO NOT REPLY [Bug 24463] - [PATCH] Petstore sample: bug fixes + completions

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24463

[PATCH] Petstore sample: bug fixes + completions

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

Re: Random comments and bugfixes

[J.Pietschmann]

Stefano Mazzocchi wrote:
... 0xd800 is not a legal XML character.
...
   𐀀

Now: whose problem is this Slide's or JDOM's?
JDOM, I'd guess without looking at the code. This is a very general
problem: The surrogate Unicode codepoints are illegal for itself in
XML, but of course in Java strings there is no way to express
non-baseplane characters other than as two surrogates. Problem:
if the test for illegal surrogates is before character reference
expansion, illegal surrogates may sneak in as char refs. If the test is
after character reference expansion, a non-baseplane character may
trigger a false positive. Obviously, the test has to be done twice,
once for literal characters and once as part of dealing with character
references.
I personally wouldn't loose much sleep over this particular problem.
Unless you are into MathML or obscure historic scripts, non-baseplane
characters are more of a curiosum.
J.Pietschmann

DO NOT REPLY [Bug 24463] - [PATCH] Petstore sample: bug fixes + completions

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24463

[PATCH] Petstore sample: bug fixes + completions





--- Additional Comments From [EMAIL PROTECTED]  2003-11-11 18:15 ---
Confirmed, cart and checkout pages look ok here as well.

Re: [IMP] Code Freeze

[Joerg Heinicke]

On 11.11.2003 12:38, Stefano Mazzocchi wrote:

Carsten, what is the status of the component proxy? If we have such a 
big memory leak, I think we should get it solved before doing the release.
http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=106821042709285&w=2

Joerg

Re: DO NOT REPLY [Bug 23299] - [PATCH] UTFDataFormatException: String cannot be longer than 32k.

[Joerg Heinicke]

On 08.11.2003 18:22, Torsten Curdt wrote:

...we duplicate events here and the thereby modify the SAX stream.
Should be no problem but who knows ;)
with the patch:

 characters(36k)
->
 event
 string 32k
 event
 string 4k
I guess it would be better to have it like this:

 characters(36k)
->
 event
 string 32k
 string 4k
So what goes in comes out the same way.

We could also increasing the max length of a stored
character event in general. ...but that would waste
2 bytes per event. Hm...
What do you think?
This was what I meant when writing "If we split the text node here into
littler parts, will they be re-read as *one* text node when reading the
XMLByteStream?"
Where exactly is the XMLByteStream used? If it is possible to apply a 
transformation step afterwards I see possible unexpected behaviour:


  

If we talk about the same problem I see, there will possibly be later 
more  than there should be. It should be fixed then.

Joerg

Re: [PATCH] docs pages containing are sometimes too wide

[Joerg Heinicke]

Answering David's and Conal's mails in one mail:

On 09.11.2003 04:34, David Crossley wrote:

>>I had no look on the code, only on the samples, where David shows the 
possible
>>use cases - and these are really extreme samples :-)
>
>
> They are deliberately extreme to ensure that the bugs get triggered.
> Did i go overboard?

No, nothing bad. Only *impressive* :-)

>>It's almost not possible to handle both indenting and line length for 
every type
>>of source. IMO we should simply replace the s with some simple 
s and
>>replace the line breaks in the text nodes of the s with s - 
this way we
>>do it in our intranet. The layout is up to the browsers.
>
>
> The problem is that that is going to break a lot of existing websites,
> because they probably rely on the current behaviour of 
> rendering.

In which way breaking them? The possible fix is only about additional 
linebreaks, everything else stays the same. But, yes, while writing 
this, the styling could change, because they don't style this paragraphs 
like pre's. I would add a class="pre" or similar.



On 09.11.2003 19:57, Conal Tuohy wrote:

It's almost not possible to handle both indenting and line
length for every type of source.
Absolutely true.

We just need XSLT templates to handle specific types of . I don't
think it's too hard for a type-specific template to recognise it's own
flavour of , and the actually existing  template can handle
anything else.
Sounds good in general.

The DTD says that  is normally displayed in a fixed-width font, so
in general I think authors have the right to expect . But for sitemap
snippets etc. this is really not good, because there are long class-names
like org.apache.cocoon.generation.WebServiceProxyGenerator and attributes
like xmlns:dir="http://apache.org/cocoon/directory/2.0"; and in a fixed-width
font these are much wider than they need to be.
Here I don't go with you. Reading sources in non-fixed-with fonts (how 
are they called? proportional?) is a pain IMO. But of course we can 
provide alternative stylesheets and the user can select them as at 
http://www.w3.org/Style/CSS/ (in Mozilla: View > Use Style > ...).

The wrap2para.xsl which I wrote was originally for Cocoon's docs in which
the  elements almost always contain representations of XML markup. I
think it does a reasonable job of that, though it could of course be
improved.
Eh, did I miss something or what is wrap2para.xsl? At the bug there is 
only a patch to document2html.xsl.

But it turned out that  has a wider applicability than I realised.
My suggestion is clearly no good for the "ascii-art" example of a
file-system hierarchy. That kind of  requires a fixed-width font,
and the current templates are fine for that.
So I plug for the "sniff content" option, and

1) for  which is xml/html/dtd use wrap2para.xsl
2) for everything else use the actually existing stylesheet (i.e. pre)
I don't think there's much need for split.xsl, but it could be used for (2)
where I guess it would usually produce the same output, and would
occasionally have to split a long line.
Potential enhancements would be:

For XML:
Allow browser to wrap lines only in the whitespace inside element tags.
Syntax highlighting of elements and attributes.
For Java:
Prevent line-wrapping in //-style comments.
Syntax highlighting for string literals, operators, comments, etc.
The problem I see is that there is no structured content. It's only 
text. You always have to parse that stuff. Isn't it exaggerated?

I suggest replacing


  


  

(elements inside  must be escaped of course)

with


  


  

(elements from above must be escaped, s not.)

So you have normal text flow and must only scroll vertical if there is 
an attribute="reeeaaayyllloonnnggg" 
or something similar.

The above is really simple and a light weight solution. But it's 
additionally support to committer's ability to forget the line legnths :-)

Joerg

Re: Migrating TreeProcessor to Fortress

[Joerg Heinicke]

I guess I simply mix all and everything: the sitemap, your pseudo xconf, 
XML in general and the "object model". I do not understand much of it 
and maybe I should shut up because of this :-)

Read on, you seemed to hit my concern:

On 11.11.2003 12:33, Unico Hommes wrote:


Do you mean:

parent.xmap:

  

  

  

child.xmap:

  

  


  

  

?
Yes, exactly.

No this is not a problem because the ServiceManager of the parent
processor acts as the parent to the ServiceManager of the child
processor. The match node will ask the child ServiceManager for the file
generator, and if the child ServiceManager doesn't find it among its own
components it asks the parent ServiceManager for it. This is also how it
is handled today.
The tree-like lookup is clear.

The sitemap components will actually be handled a little different from
the pipeline nodes. The above parent.xmap translated into a fortress
configuration will look like:
parent.xconf:

  

And the child.xmap looks like:

child.xconf:

  ...
  
   
  

  
and here I thought of idref="file-generator", which does not exist from 
an XML POV.


In which form will the fortress configuration exist? Do you want to 
start a transformation or is the above only an XML representation for a 
completely hidden and automatically handled "feature"?

Joerg

Makes flow script the sitemap ugly? (was: Re: [vote] forbidding flowscripts with no sendpage redirects)

[Joerg Heinicke]

On 11.11.2003 15:48, Geoff Howard wrote:

In fact, I think that flow in some cases needlessly 
complicates the composition of a pipeline.  Now I have to have two 
pipelines where I used to need one.  I have to have one that matches the 
external request and calls the flow function, and another one for the 
default result of that pipeline.
I have exactly the same feeling about the flow. I talked about exactly 
the same with Sylvain in private communication (btw: Did you ignore my 
last email or didn't you receive it, Sylvain. I sent it on the day you 
had problems with Anywhere mail to your Apache account - which is 
probably forwarded to Anywhere :-( ). In German slang I would call the 
flow "drangepappt". How can this be translated into English: The flow is 
not integrated into the sitemap very well and makes the sitemap flow 
somewhat opaque or obfusicated. How must look into the flow to 
understand what's going on in the sitemap. And if it is so why not 
integrating the flow script into the sitemap directly? No, I don't want 
to have Javascript in the sitemap, it's only a bad feeling about that. 
Especially because of the two-side dependency from sitemap to flow to 
sitemap.

So far this has felt like needless 
additional complexity to me (and I think will to others).

To try to make this point a little clearer:
Part of the beauty of the sitemap prior to flow was that you could at a 
glance see what each request url was triggering.  Now, I look at the 
sitemap, have to locate the flowscript, parse through it for the various 
sendPage etc. and then back to the sitemap to find where the action 
really happens.  This could perhaps be handled with some best practice 
naming conventions.  Perhaps a practice of passing in the various 
possible view uris to the flowscript should be considered.  I don't know.
Naming conventions is to weak to handle this IMHO.

I'm not negative on flow, and not positive on actions - just pointing 
out a loss of readability of the sitemap that has resulted from our move 
forward.
I can not be negative on flow, because I don't have participated in flow 
discussions at that time. But it's my bad feeling about this stuff.

Any comments or flames ;-)

Joerg

[RT] ComponentizedProcessor (was RE: Migrating TreeProcessor to Fortress)

[Sylvain Wallez]

Hi all,

Here's a RT about Unico's proposal of "flattening" the sitemap for the 
migration to Fortress. Please read carefully, this has a lot of 
implications.

Introduction

Today isn't worked in France. We "celebrate" (should we enjoy of that?) 
the end or Word War I, and this is the occasion to explain children what 
their grand-grand-fathers went through a century ago, hoping this won't 
happen again. I was doing some DIY at home, and manual work freezes my 
brain. So while digging in the garden, I was thinking of Unico's 
"iconoclast" proposal about the sitemap engine. Yes, the treeprocessor 
is still somehow "my baby", and seeing it shaked as it is these days 
makes me think a lot about it.

And then came the sudden revelation: Unico's idea is brilliant and its 
implications go far beyond the migration to Fortress.

Implications

Considering every sitemap statement as a component allows to very easily 
implement a number of features that are either were wanted for long but 
were never implemented because of their complexity, or that will be 
needed for blocks:

1/ Virtual components
Virtual components are sitemap snippets that can be used in place of 
"regular" components. I many languages, these are called "macros". With 
sitemap statements as components, virtual components are a breeze to 
implement: just lookup the component, and see if what's returned is a 
regular sitemap component (e.g. a Serializer) or if it's a 
ProcessingNode. If it's a regular sitemap component, add it to the 
pipeline, and otherwise invoke the ProcessingNode.

What I'm not sure about here, is if its possible (or even desirable) 
that we can have two different implementation interfaces for a single role.

2/ Resources inheritance
Resources are nothing more than untyped virtual components (yeah 
Stefano, I know, they should be serializers). So if a resource isn't 
defined in a sitemap, we go up to the parent sitemap's component manager 
and lookup the resource there.

3/ Block-defined sitemap components
A block can provide sitemap (and other) components to other blocks, 
including virtual components. Nothing special here actually, but the 
fact that block inheritance is implemented, once again, by the parent 
relationship of component managers.

3/ View inheritance
Views are nothing more than virtual serializers, with the main 
difference that their hint is defined at runtime by the "cocoon-view" 
parameter. And since these are components, lookup goes up to the parent 
sitemap if a view is not declared in a given sitemap, thus providing 
inheritance.

Side note: relative URIs

The various considerations about inheritance above leads to the question 
of resolution of relative source URI (Carsten raised this issue some 
time ago): what is the base URI that should be used by the resolver?

My opinion is that the base URI should be the one of the sitemap 
_handling_ the request. This means that "jumping" to another sitemap 
through virtual components or view inheritance should not affect the 
base URI.

However, there are many situations where we want to use a source 
relative to the _current_ sitemap regardless on how it's called. For 
this, I propose a new protocol similar to how "context:" behaves with 
the root sitemap, but for non-root sitemaps. The "sitemap:" protocol 
comes to mind, but I'm not sure this is a good name.

Performance considerations
--
When writing the TreeProcessor, great care was taken to pre-analyse 
everything that is possible to achieve maximum runtime speed. I 
currently found only two performance degradation points with this new 
approach:

- it's not possible to choose the ProcessingNode implementation 
depending on the class of a component as, e.g. in MatchNodeBuilder. The 
cost is finally just an "instanceof" check to choose the right behaviour.

- mapping from view names to their labels is pre-computed in the 
TreeProcessor for each individual sitemap component, so that the view's 
ProcessingNode (if any) can be found directly with the view name (see 
SitemapLanguage.getViewsForStatement and e.g.GenerateNode.invoke()). 
But, considering that views are marginally used in a production 
environment, the few extra lookups can be considered as negligible.

Implementation
--
The implementation mainly consists in merging the code of 
ProcessingNodeBuilder classes in the corresponding ProcessingNode class.

The initial "flattening" transformation can be implemented in XSL, whose 
simplicity will allow to implement at this level some semantic checks 
that can be difficult to implement otherwise.

However, an important requirement is to keep location information of 
sitemap statements. For this I suggest to augment the sitemap SAX stream 
by adding Locator information in a "location" attribute on every 
element. This augmentation can be useful in several other contexts such 
as Woody (would avoid the dependency on Xerces in

Re: DO NOT REPLY [Bug 23299] - [PATCH] UTFDataFormatException: String cannot be longer than 32k.

[Torsten Curdt]

Where exactly is the XMLByteStream used? 
Lots of places. Caching in general

> If it is possible to apply a
transformation step afterwards I see possible unexpected behaviour:


  

If we talk about the same problem I see, there will possibly be later 
more  than there should be. It should be fixed then.
Yes, I guess this is a problem with the current patch.
Maybe we even should revert it for the release.
I already have something sitting on my disk.
Will try and commit it after the code freeze.
cheers
--
Torsten

Re: Random comments and bugfixes

[Sylvain Wallez]

J.Pietschmann wrote:



I personally wouldn't loose much sleep over this particular problem. 
Unless you are into MathML or obscure historic scripts, non-baseplane 
characters are more of a curiosum.


Ermm... not that I will loose sleep, but what is a "baseplane" character

Sylvain

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

Re: DO NOT REPLY [Bug 23299] - [PATCH] UTFDataFormatException: String cannot be longer than 32k.

[Sylvain Wallez]

Torsten Curdt wrote:

...I was wondering - is this a bug of the component that produces the
SAX events or the XMLByteStreamCompiler? I mean: now it's ok - but 
should we
silently ignore the problem?


Torsten, I don't understand your concerns. Isn't the fix simply about 
handling text nodes longer than 32 k? Ok, they shouldn't occur that 
often (it's half a novel :-) ), but it's possible.


we duplicate events here and the thereby modify the SAX stream.
Should be no problem but who knows ;)
with the patch:

 characters(36k)
->
 event
 string 32k
 event
 string 4k
I guess it would be better to have it like this:

 characters(36k)
->
 event
 string 32k
 string 4k
So what goes in comes out the same way.


According to the SAX spec, a single text node can be split in an 
sequence of consecutive character() events, and all SAX handling code 
should be written to take care of this.

So sending two events should really not be a problem.

Sylvain

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

Re: [RT] ComponentizedProcessor (was RE: Migrating TreeProcessor to Fortress)

[Tony Collen]

Sylvain Wallez wrote:

3/ View inheritance
Views are nothing more than virtual serializers, with the main 
difference that their hint is defined at runtime by the "cocoon-view" 
parameter. And since these are components, lookup goes up to the parent 
sitemap if a view is not declared in a given sitemap, thus providing 
inheritance.
Is this really needed, or desirable?  Views are not currently inherited, 
and making them inherited may break something that people already have 
setup.  Were views made uninheritable on purpose?

Consider an environment where you have subsitemaps delegated out for 
separate departments or people to use.  If you have some views in the 
main sitemap, I wouldn't neccesarily want them propagating down to 
subsitemaps.

Would an empty  tag would override any views in a sitemap?

But maybe this isn't really a problem, if you have everything in a 
subsitemap, even your "main" one, then you wouldn't have to worry. 
Likewise, just declare no components in the supersitemap and you're good 
to go.

Thoughts?

Tony

Re: DO NOT REPLY [Bug 23299] - [PATCH] UTFDataFormatException: String cannot be longer than 32k.

[Joerg Heinicke]

On 11.11.2003 22:07, Sylvain Wallez wrote:

According to the SAX spec, a single text node can be split in an 
sequence of consecutive character() events, and all SAX handling code 
should be written to take care of this.

So sending two events should really not be a problem.
But what about my simple sample


  

?? Who should fix it that it works like expected, i.e. one text node in 
one p element?

Joerg

Re: [RT] ComponentizedProcessor (was RE: Migrating TreeProcessor to Fortress)

[Sylvain Wallez]

Tony Collen wrote:

Sylvain Wallez wrote:

3/ View inheritance
Views are nothing more than virtual serializers, with the main 
difference that their hint is defined at runtime by the "cocoon-view" 
parameter. And since these are components, lookup goes up to the 
parent sitemap if a view is not declared in a given sitemap, thus 
providing inheritance.


Is this really needed, or desirable?  Views are not currently 
inherited, and making them inherited may break something that people 
already have setup.  Were views made uninheritable on purpose?

Consider an environment where you have subsitemaps delegated out for 
separate departments or people to use.  If you have some views in the 
main sitemap, I wouldn't neccesarily want them propagating down to 
subsitemaps.

Would an empty  tag would override any views in a sitemap?


Nope. You will only define no local views, meaning it will have no 
effect of any kind.

But maybe this isn't really a problem, if you have everything in a 
subsitemap, even your "main" one, then you wouldn't have to worry. 
Likewise, just declare no components in the supersitemap and you're 
good to go.


That's a solution. Another one may be to take advantage of the 
public/private component managers I suggested. We could declare 
"private" views and resources that would be only visible in the current 
sitemap. But I'm not sure we need this extra semantic complexity.

Sylvain

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

Re: DO NOT REPLY [Bug 23299] - [PATCH] UTFDataFormatException: String cannot be longer than 32k.

[Joerg Heinicke]

On 11.11.2003 22:01, Torsten Curdt wrote:

Where exactly is the XMLByteStream used? 


Lots of places. Caching in general

 > If it is possible to apply a

transformation step afterwards I see possible unexpected behaviour:


  

If we talk about the same problem I see, there will possibly be later 
more  than there should be. It should be fixed then.


Yes, I guess this is a problem with the current patch.
Maybe we even should revert it for the release.
I already have something sitting on my disk.
Will try and commit it after the code freeze.
We don't break anyone's code with the current patch, at least I guess no 
one is relying on the exception thrown until now :-) But if you have 
already something working, that's better than the current one let's fix 
the current behaviour after the release. Or does this temporary solution 
do any harm?

Joerg

Re: [RT] ComponentizedProcessor (was RE: Migrating TreeProcessor to Fortress)

[Tony Collen]

Sylvain Wallez wrote:

Tony Collen wrote:



But maybe this isn't really a problem, if you have everything in a 
subsitemap, even your "main" one, then you wouldn't have to worry. 
Likewise, just declare no components in the supersitemap and you're 
good to go.


That's a solution. Another one may be to take advantage of the 
public/private component managers I suggested. We could declare 
"private" views and resources that would be only visible in the current 
sitemap. But I'm not sure we need this extra semantic complexity.
Hmm,

 ?

Seems simple enough for me.  Not too keen on the implementation details 
though ;)

PS, here in the US it's Veteran's Day, which seems very similar to your 
holiday in France.  I had to go to the Department of Motor Vehicles and 
transfer the title for a car I just bought, but I found out it's a 
government holiday, so the important stuff is all closed today ;(

Sylvain



Tony

RE: [IMP] Code Freeze

[Carsten Ziegeler]

Stefano Mazzocchi wrote:
> 
> Carsten, what is the status of the component proxy? If we have such a 
> big memory leak, I think we should get it solved before doing the 
> release.
> 
I have applied all the changes during our FirstFriday and I'm waiting
on some feedback, if the changes fixed the problem and if everything
is working well - but I guess from the "no response at all" that 
at least everything is working well :)

> Also note that there seems to be consensus on making Sylvain's 
> restricted flowscript calling policy in 2.1.3
Yepp, I saw it.

> 
> These two might just well "unfreeze" the tree? WDYT?
Yes, of course - I still think, if someone is really sure that a
patch/fix - whatever you call it - will not break other parts,
it's ok to apply it. But I think we agreed last time, we discussed
the code freeze, that a vote is required.
As Sylvain has started this voted and as the outcome of this
vote seems to be to apply it before the release, it's ok anyway.

The only question is: do we stick to the release date of thursday?
*I* can do the release on thursday or on friday. Due to the ApacheCon
and some holidays :) I won't be able to do it in the following
three weeks. So if we want to shift the date for one or two weeks
someone else has to do it.

WDYAT?

Carsten

Re: Random comments and bugfixes

[J.Pietschmann]

Sylvain Wallez wrote:
Ermm... not that I will loose sleep, but what is a "baseplane" 
character
A sloppy phrase :-)
The Unicode base plane covers the code points U+..U+,
i.e. characters which can be represented using a 16 bit value.
There are characters assigned to code points above 65536.
Check http://www.unicode.org for details.
J.Pietschmann

Re: DO NOT REPLY [Bug 23299] - [PATCH] UTFDataFormatException: String cannot be longer than 32k.

[J.Pietschmann]

Joerg Heinicke wrote:
?? Who should fix it that it works like expected, i.e. one text node in 
one p element?
XSLT processors generally hide the issue, whether by normalizing
the input while or after the tree is built or by other means.
The interesting stuff of course are XPath processors working on
potentially unnormalized DOM structures, in particular Cocoons
XInclude processor and the XPath transformer. I'd say you'll get
all kind of interesting behaviour.
J.Pietschmann

Re: DO NOT REPLY [Bug 23299] - [PATCH] UTFDataFormatException: String cannot be longer than 32k.

[Torsten Curdt]

J.Pietschmann wrote:
Joerg Heinicke wrote:

?? Who should fix it that it works like expected, i.e. one text node 
in one p element?
this depends on the xslt processor or
the transformer in general
XSLT processors generally hide the issue, whether by normalizing
the input while or after the tree is built or by other means.
exactly

The interesting stuff of course are XPath processors working on
potentially unnormalized DOM structures, in particular Cocoons
XInclude processor and the XPath transformer. I'd say you'll get
all kind of interesting behaviour.
as I said: better let's get out what goes in

cheers
--
Torsten

Re: DO NOT REPLY [Bug 23299] - [PATCH] UTFDataFormatException: String cannot be longer than 32k.

[Torsten Curdt]

We don't break anyone's code with the current patch, at least I guess no 
one is relying on the exception thrown until now :-)  But if you have
already something working, that's better than the current one let's fix 
the current behaviour after the release. Or does this temporary solution 
do any harm?
Well, alright: let's keep it and I'll test and
commit it after the code freeze
cheers
--
Torsten

Re: [vote] forbidding flowscripts with no sendpage redirects (was Re: Saving pipeline output to a temp file...)

[Sylvain Wallez]

Sylvain Wallez wrote:

Let's reformulate this into a proper vote.

Do you want to enforce the fact that flowscript calls (either 
"function" or "continuation") *must* redirect using sendPage, 
sendPageAndWait or redirectTo and that, should it not be the case, a 
ProcessingException be raised?


So far, we have the following results :

8 votes to enforce it in 2.1.3,
1 vote to enforce it in 2.1.4,
and a "-0" and "-0.5" on enforcing (Vadim and Geoff)
So, the community has decided that this should be enforced sooner than 
later. Quoting Antonio, "earlier means less pain in the future".

I just committed the patch. Samples seem to behave correctly. Please 
cross-check.

Sylvain

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

Re: [IMP] Code Freeze

[Joerg Heinicke]

On 11.11.2003 22:31, Carsten Ziegeler wrote:

The only question is: do we stick to the release date of thursday?
*I* can do the release on thursday or on friday. Due to the ApacheCon
and some holidays :) I won't be able to do it in the following
three weeks. So if we want to shift the date for one or two weeks
someone else has to do it.
WDYAT?
Now as everything important is committed: Thursday.

Joerg

Using a generic sitemap + flow (was: Makes flow script the sitemap ugly?)

[Antonio Gallardo]

Hi:

I read the lastest comments about flow and I want to share with the rest
of you my own experiences.

We are developing database oriented webapp. We are using, well I will
repeat it again :-), Flow+Woody+OJB, JXGenerator and Druid.

And I think Flow help us in the SoC. I will try to explain it:

1-Main sitemap: Just declare all the components that the application need.
Here we have all the  + some pipelines that manage:

a) transition to business objects (subsitemaps)
b) All the common resources: images (*.gif, *.png), *.css, *.js (client).
c) Handle errors.

In the main sitemap you will not find any flow script at all.

2-"Business Object": They contains all the forms needed to manage the
particular object inside the webapp. Each Businnes Objects have the same
structure. Also they have the same sitemap. That way we don't need to
create a new sitemap every time we start one Business Object. You can also
have other forms (for example "list" not showed in the below sample). Here
is the structure of each business object:

ModuleName
+--- forms
|   +--- create
|   |   +--- bind.xml
|   |   +--- definition.xml
|   |   +--- flow.js
|   |   +--- template.xml
|   +--- search
|   +--- remove
|   +--- update
+---sitemap.xmap

Every business object has his own BOH (Business Object Handler) written in
Java. The BOH is used inside the flow. The BOH contains all the functions
needed to manipulate beans used in the forms of the Business Object. The
BOH must contains the CRUD operations related to the object.

All BOHs are almost similars thanks to OJB-JDO.

The underlying part of the O/R mapping is done using Druid (hey?! here is
again Druid!).

Here is some flow script:

**
Create:
**
function createform(form) {
form.showForm("create-form-display");

var factory = cocoon.getComponent(Packages.o.a.cJdoPMF.ROLE);
var bean = new Packages.test.forms.area.Bean();
var handler = new Packages.test.forms.area.Handler();

form.save(bean);
handler.insert(bean, factory);
cocoon.releaseComponent(factory);
success("Areas", "Area procesada con éxito",
"¿Desea procesar una nueva área?","create");
}

**
Search:
**

function searchform(form) {
form.showForm("search-form-display");
cocoon.sendPage("list",
   {"criteria" : form.getWidget("criteria").getValue()});
}

**
List:
**
function listform(form) {
var factory = cocoon.getComponent(Packages.o.a.c.JdoPMF.ROLE);
var bean = new Packages.test.forms.area.List();
var handler = new Packages.test.forms.Handler();
var criteria = new String (cocoon.request.criteria);

handler.getList(bean, criteria, factory);

form.load(bean);
form.showForm("list-form-display");
var nuevoBean = new Packages.test.forms.area.List();
form.save(bean);
handler.setList(bean, criteria, factory);
cocoon.releaseComponent(factory);
success("Administración de Areas", "Actualización de Áreas",
   "Todos los cambios se procesaron existosamente. ¿Desea volver a
procesar la lista de áreas?", "search");
}


The sitemap looks:


  
  
  



  
  

  
  
  
  
  
  
  



  
  

  

  
  

  


   
   
 
   
   
   
   
 
   
 


We are still developing this idea. The "Business Objects" modules and the
best generic structure for them in any webapp.

If we found it, then we will try to develop a tool for building database
oriented webapp using Cocoon. We tought the start must be the form
definition. Based on the form definition the tool will generate the
database script, the woody forms, the java classes, the O/R mapping etc.
It would be very nice, is it? Here again, I see druid as an important part
of the overall tool helping us in the database arena.

We are now developing 2 webapp at the same time and we are trying to
follow some technics that will help us in the automatization of the code.
Under this approach we don't see to the sitemap as the most dynamic part
of the application. Or maybe?

As I told you I am lazy enough to write the same code over and over just
changing some names. :-D

Comments are welcome.

Best Regards,

Antonio Gallardo.

Re: Saving pipeline output to a temp file...everything you wanted to know but were afraid to ask!

[Sylvain Wallez]

Andrzej Jan Taramina wrote:

Will this be in place in 2.1.3?  If not then I would suggest that precluding the use of this unspecified behaviour prior to delivering the flowscript action is irresponsible to large, devoted Cocoon users and will win you little good will in the community.  Regardless of how "philosopically" right the course of action might be in your eyes.
 

Sorry Andrzej, but the community has decided with a vote.

One of the values of the Cocoon project is to try to be philosophically 
right. And this is by fixing this kind of issues sooner than later that 
Cocoon tries to keep a clean architecture. Sure, the docs aren't what 
they should be to clearly document what we consider "clean". But 
enforcing it in the code somehow circumvents the lack of docs. Sorry if 
you have to cope with the consequences of this attitude this time.

The flowscript action is not in place, but you may find a convenient 
replacement with the ScriptAction (bsf block) that relies on BSF and as 
such accepts JavaScript code also. There's no "cocoon" object, but all 
usefull objects you normally access through "cocoon" are directly 
visible, such as "request", "manager", "logger", "resolver", etc.

Sylvain

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

Re: Makes flow script the sitemap ugly?

[Sylvain Wallez]

Joerg Heinicke wrote:

On 11.11.2003 15:48, Geoff Howard wrote:

In fact, I think that flow in some cases needlessly complicates the 
composition of a pipeline.  Now I have to have two pipelines where I 
used to need one.  I have to have one that matches the external 
request and calls the flow function, and another one for the default 
result of that pipeline.


I have exactly the same feeling about the flow. I talked about exactly 
the same with Sylvain in private communication (btw: Did you ignore my 
last email or didn't you receive it, Sylvain. I sent it on the day you 
had problems with Anywhere mail to your Apache account - which is 
probably forwarded to Anywhere :-( ).


I received it, but was so swamped with work and mail problems that I 
failed to answer...

In German slang I would call the flow "drangepappt". How can this be 
translated into English: The flow is not integrated into the sitemap 
very well and makes the sitemap flow somewhat opaque or obfusicated. 
How must look into the flow to understand what's going on in the 
sitemap. And if it is so why not integrating the flow script into the 
sitemap directly? No, I don't want to have Javascript in the sitemap, 
it's only a bad feeling about that. Especially because of the two-side 
dependency from sitemap to flow to sitemap.

So far this has felt like needless additional complexity to me (and I 
think will to others).

To try to make this point a little clearer:
Part of the beauty of the sitemap prior to flow was that you could at 
a glance see what each request url was triggering.  Now, I look at 
the sitemap, have to locate the flowscript, parse through it for the 
various sendPage etc. and then back to the sitemap to find where the 
action really happens.  This could perhaps be handled with some best 
practice naming conventions.  Perhaps a practice of passing in the 
various possible view uris to the flowscript should be considered.  I 
don't know.


Naming conventions is to weak to handle this IMHO.


Exactly. My personal way of doing things is very close to Antonio's: 
here's a typical sitemap of my flow+woody applications:


 
 
   
 
   
 
 
 
   
 
   
  
   
   
 
   
 
   
 other matchers...
 

Several noticeable things:
- internal pipeline is placed first. It makes things faster, as it's 
checked first for internal request, and ignored for external ones
- "_" prefix for internal URIs avoids most name clashes with external URIs.
- prefixing externally-callable flow functions with the "public_" prefix 
(or something else) prevents hackers to call non public flow functions
- Distinguishing call/continue with the request method allows to have 
. This is convenient when writing form templates and 
keeps the browser location bar clean (the address doesn't change)

Sylvain

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

Re: DO NOT REPLY [Bug 24463] - [PATCH] Petstore sample: bug fixes + completions

[David Crossley]

bugzilla wrote:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24463
> 
> --- Additional Comments From Leo Leonid  2003-11-11 16:03 ---
> David, looks like the patch is not correclty applied. 
> The sitemap looks horrible ATM and is not wellformed.

It sounds like you have been bitten by the 'cvs update' gotcha.
Whenever a committer accepts a patch, then they may make their
own tweaks to the code. They may even totally re-write some sections.

When you, the contributor, does their 'cvs update' then they need
to be doubly sure to check for "conflict" messages.

Anyway, your sitemap may have had conflict markers inserted by cvs
to deliberately break your copy.

As you did, the best way is to delete your offending files and
do the update again.

> I'm not so experieced creating diffs, ...

On the contrary. Your diff was fine. The trouble was the update.

--David

Re: DO NOT REPLY [Bug 24463] - [PATCH] Petstore sample: bug fixes + completions

[David Crossley]

bugzilla wrote:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24463
> 
> --- Additional Comments From Leo Leonid  2003-11-11 16:03 ---
> David, looks like the patch is not correclty applied. 
> The sitemap looks horrible ATM and is not wellformed.

It sounds like you have been bitten by the 'cvs update' gotcha.
Whenever a committer accepts a patch, then they may make their
own tweaks to the code. They may even totally re-write some sections.

When you, the contributor, does their 'cvs update' then they need
to be doubly sure to check for "conflict" messages.

Anyway, your sitemap may have had conflict markers inserted by cvs
to deliberately break your copy.

As you did, the best way is to delete your offending files and
do the update again.

> I'm not so experieced creating diffs, ...

On the contrary. Your diff was fine. The trouble was the update.

--David

Re: whitespace cleanup and efficiency drive

[Joerg Heinicke]

The result of this thread: let's care only about white spaces.

It's my opinion too. But the editor should do this automatically, not by 
running a task by hand. IDEA does it pretty good: Removes trailing 
spaces when saving a file, replaces existing tabs with spaces on save, 
when using the key TAB it adds spaces to the file. But unfortunately 
IDEA is not for free.

The editors I use at the moment are Eclipse and jEdit. Both can insert 
spaces instead of TAB when using the key. But both do not handle the 
other two things. And even worse for XML with Eclipse and SunBow: it 
does not even handle the TAB => spaces issue.

Even if this leads not to additional results my conclusion:
Having the right tools we would not have such problems.
Joerg

On 10.11.2003 05:52, David Crossley wrote:

It might sound pedantic, but it is about efficiency.

I have wasted a lot of time during my committer life with
confusing patches that contain mainly whitespace changes.
Not to criticise the patcher or their tools, but today
was a classic. With some manual tweaks to whitespace,
i managed to bring one diff down from 450 lines to 120 lines.
What caused this grief? Well the files in cvs had inconsistent
whitespace, most indentations were 4-space, some were 3-space,
some line of text had two spaces between words rather than one,
and other spurious issues. Now when the developer edited that
file, their text editor must have tried to fix the whitespace,
but in many cases made it worse.
Therefore the diff was full of clutter. If i had committed
it then no-one would have been able to review the changes.
It would look like almost every line had changed. Also the cvs
files would have been in a worse state and then perpetuate it.
I suppose that it is a dream, but does anybody know about a
tool that would automatically apply say 4-space indentation
and whitespace clean up? We could apply that to our whole
cvs say once per month.
--David

Re: Saving pipeline output to a temp file...everything you wanted to know but were afraid to ask!

[Andrzej Jan Taramina]

> Why do you need flowscript to fire a vb script? It should be possible to do it
> in Java, and the action code should not be far from a cut'n paste of the
> flowscript code.

I don't...it was just more convenient rather than compiling Java code.  I 
plan to turn my flowscript into a Java action as a result.

> There's been a discussion about this, and we agreed on the fact that he 
> semantics of  and  continuation implied 
> that it _must_ redirect somewhere using sendPage, sendPageAndWait or 
> redirectTo.

True...but why lock it down in 2.1.3 and piss of a VERY large customer/user 
base?  I think the gradual phasing out, where it's discouraged in 2.1.3 and 
prevented in 2.1.4 makes a lot of sense.

> The semantics you would like is the one of an action. I proposed to add 
> a "flowscript action" that would share function and global variable 
> scopes with the flowscript but have the appropriate contract of 
> returning a Map of values to the sitemap.

Will this be in place in 2.1.3?  If not then I would suggest that precluding 
the use of this unspecified behaviour prior to delivering the flowscript 
action is irresponsible to large, devoted Cocoon users and will win you 
little good will in the community.  Regardless of how "philosopically" right 
the course of action might be in your eyes.

> So the flowscript call semantics will be strengthened in the 2.1.4 to 
> avoid abuses of this unspecified behaviour. And the fact that you 
> already rely on this behaviour shows that we must correct things quickly.
> 
> If it was only me, we would forbid it ASAP for the 2.1.3 release. What 
> do others think?

Only if you deliver the flowscript action in 2.1.3.  Then I won't have a 
problem with you forbidding it sooner.

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: Saving pipeline output to a temp file...everything you wanted to know but were afraid to ask!

[Sylvain Wallez]

Sylvain Wallez wrote:

Andrzej Jan Taramina wrote:

Will this be in place in 2.1.3?  If not then I would suggest that 
precluding the use of this unspecified behaviour prior to delivering 
the flowscript action is irresponsible to large, devoted Cocoon users 
and will win you little good will in the community.  Regardless of 
how "philosopically" right the course of action might be in your eyes.


Sorry Andrzej, but the community has decided with a vote.

One of the values of the Cocoon project is to try to be 
philosophically right. And this is by fixing this kind of issues 
sooner than later that Cocoon tries to keep a clean architecture. 
Sure, the docs aren't what they should be to clearly document what we 
consider "clean". But enforcing it in the code somehow circumvents the 
lack of docs. Sorry if you have to cope with the consequences of this 
attitude this time.

The flowscript action is not in place, but you may find a convenient 
replacement with the ScriptAction (bsf block) that relies on BSF and 
as such accepts JavaScript code also. There's no "cocoon" object, but 
all usefull objects you normally access through "cocoon" are directly 
visible, such as "request", "manager", "logger", "resolver", etc.


And ever simpler solution (how did I miss this?) that came to me when 
going to bed (it's 11:45 pm here). Just split your request in two 
phases: the first one will call the flowscript in which you just add a 
sendPage() to the second part. This even allows you to pass the VB 
execution result or other flow values to the view.

As you can see, Cocoon enforces clean architectures but doesn't neglect 
its users. I hope the gazillion users of your multi-million project will 
be thankfull for the free (as in both "free beer" and "free speech") 
private time I dedicated to them.

Really going to bed now...

Sylvain

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

Re: [RT] ComponentizedProcessor (was RE: Migrating TreeProcessor to Fortress)

[Niclas Hedhman]

On Wednesday 12 November 2003 04:48, Sylvain Wallez wrote:
> I'm wondering if we should write this new sitemap engine in the 2.2
> branch or if it should go in the 2.1. Fortress isn't a requirement to
> implement this, and it will allow us to provide views and resource
> inheritance before the 2.2 is out.

It is time for Cocoon to adapt the Linux-dev versioning scheme of 2.odd = 
development, 2.even=release...

Cheers,

Re: Woody sample bug

[Antonio Gallardo]

Timothy Larson dijo:
> --- Antonio Gallardo <[EMAIL PROTECTED]> wrote:
> 
>> In Fedora core 1 (BTW, I installed it right now :-D ) using mozilla
>> 1.4.1
>> I don't have the related problem.
>
> Could you check your Cocoon logs to see if your mozilla is sending two
> submits
> in sequence?  That is the only way I can think of that you would not get
> the
> error.

I setted the woody log to debug and nothing is in woody.log. In
catalina.out, there is a log: "Was here!" Also the "Add contact" button
does not added a new row to the grid.

Is this info enough?

Best Regards,

Antonio Gallardo

Re: GT 2003 talks: audio only example, please test ogg version

[Bertrand Delacretaz]

Le Mardi, 11 nov 2003, à 12:31 Europe/Zurich, Antonio Gallardo a écrit :
...I would prefer ogg because MP3 has copyright issues.
Ok, I have prepared an ogg version of the example, please test on your 
platforms:

http://www.codeconsult.ch/clients/gt2003/00-introduction.ogg

I've tested it on macosx with ITunes and ogg plugin, plays ok, title 
and copyright are shown in the info fields.
To me it sounds worse than the mp3 version (which is about the same 
size), but is still understandable.

Encoding was done as follows:
oggenc -q1 -M16 --downmix --resample 8000 \
-t "Cocoon GT 2003, Steven Noels, introduction" \
-a "Copyright (C) 2003, Apache Software Foundation" \
00-introduction.wav
What do people think then, do we want to publish both mp3 and ogg (I 
can easily do both once I get going), or just ogg?

Also, do we have to ask before distributing this on the ASF mirrors? 
The whole low-fi audio files should take about 60 MB per format.

-Bertrand

Random comments and bugfixes

[Stefano Mazzocchi]

[copying [EMAIL PROTECTED] because many people are in search for a serious 
versioned content repository these days]

Hello everyone,

I find myself in the need for a serious WebDAV/DeltaV/DASL content 
repository and after having searched land and sea and having tried all 
possible combinations out there [pure mod_dav, catacomb and 
subversion], I decided to use invest my effort in Slide, also because 
of the familiarity with the java language compared to mod_dav which 
isn't really friendly for me]

I've looked into the tree for a few days now and I found several things 
that puzzle me.

[note, I'm running slide as of CVS checkout of yesterday morning, on 
Jetty 4.2.14rc1, on MacOS X 10.3.1 with JVM 1.4.2_01]

First of all, I think that "org.apache.slide.util.Configurations" 
should *not* be abstract... because it's used directly (via static 
methods) from the WebDAVServlet. This caused the "litmus" tests (see 
http://www.webdav.org/neon/litmus/) to fail and DeltaV clients to go 
nuts since the system was triggering 500 errors while trying to access 
the configuration classes.

After patching this, Slide passes all the litmus tests but one:

16. prophighunicode... FAIL (PROPPATCH of property with high 
unicode value)
17. propget... FAIL (No value given for property 
{http://webdav.org/neon/litmus/}high-unicode)

il motivo e' il seguente: org.jdom.IllegalDataException: The data "?" 
is not legal for a JDOM character content: 0xd800 is not a legal XML 
character.

Here is the HTTP request

PROPPATCH /files/litmus/prop2 HTTP/1.1
Host: 127.0.0.1:1
User-Agent: litmus/0.9.4 neon/0.24.2
Connection: TE
TE: trailers
Content-Length: 185
X-Litmus: props: 16 (prophighunicode)


 
  
   𐀀
  
 


[Note that I reformatted the output, so the content-length is broken]

Now: whose problem is this Slide's or JDOM's?

  - o -

Now a few random questions:

1) what's the status of the tree? I found out that contributed 
WebDAVGUI is out of synch with the various libraries and it seems dead. 
I also find the distribution way too tomcat centric.

2) I saw the archives and I heard about the 2.0 release proposal, 
what's the status of that?

3) also, what's the status of the variuos stores? are they usable?

4) now a more detailed question: does the DASL implementation provided 
with Slide scale? are the content metadata stored in the DB or are 
stored along with the files?

[I'm going to investigate #4 myself, but I would like to hear your 
opinion]

Thanks for any help that you might give me.

ah, and prepare for a load of patches ;-) [there are tons of import 
statements to cleanup, javadocs warnings and unused variables... note: 
I don't have CVS access on the slide CVS module, otherwise I would 
commit them myself]

--
Stefano.