date:20040226

Antonio Gallardo wrote:

We already have map:action to this. With map:action the sitemap
complexity grows very fast in some times to unreadable sizes.
 

Yes, but why using Java on the one hand and JavaScript on the other? Why 
not using for both solutions JavaScript as alternative way? This mix 
makes it much more complicated to get involved into cocoon for newbies.

Regards
Stephan

Re: Flowscript and return to pipeline

2004-02-26 Thread Antonio Gallardo

Stephan Coboos dijo:
 Antonio Gallardo wrote:

We already have map:action to this. With map:action the sitemap
complexity grows very fast in some times to unreadable sizes.


 Yes, but why using Java on the one hand and JavaScript on the other? Why
 not using for both solutions JavaScript as alternative way? This mix
 makes it much more complicated to get involved into cocoon for newbies.

AFAIK, there as an initiative to use javascript in XSP. But for a lack of
interest there is not fully developed.

For historical reasons flow was introduced with flowscript for
convenience. Later was found the advantages of using Javascript in Flow.
There was hard discusion. You can search cocoon-dev mailarchives about
this topic.

Best Regards,

Antonio Gallardo

 Regards
 Stephan

RE: cvs commit: cocoon-2.1/src/blocks/slide/samples flow.js

2004-02-26 Thread Unico Hommes


Yes windows. Running from the command line with the linotype block
included does not give me the same error, so it must have to do with
something else too.

Unico

 -Original Message-
 From: Christopher Oliver [mailto:[EMAIL PROTECTED] 
 Sent: woensdag 25 februari 2004 19:12
 To: [EMAIL PROTECTED]
 Subject: Re: cvs commit: cocoon-2.1/src/blocks/slide/samples flow.js
 
 
 Maybe this is a conflict between the package repository and 
 the class 
 Repository (there's one in the Linotype block). Does this occur on 
 windows?
 
 Unico Hommes wrote:
 
 After a little more research it looks like it also has to do with a 
 classloader problem because it only occurs when I run Cocoon 
 inside of 
 Eclipse.
 
 The exception I am seeing is java.lang.NoClassDefFoundError: 
 org/apache/cocoon/components/repository (wrong name:
 org/apache/cocoon/components/Repository)
 
 This wrong name message had me thinking it had something to 
 do with the 
 Rhino interpreting the repository string. Why does it capitalize the 
 first r in repository for instance?
 
 Also, this particular flow script imports other packages 
 from different 
 blocks without this error occurring. It only occurs when using the 
 repository package.
 
 Unico
 
   
 
 -Original Message-
 From: Christopher Oliver [mailto:[EMAIL PROTECTED]
 Sent: woensdag 25 februari 2004 16:47
 To: [EMAIL PROTECTED]
 Subject: Re: cvs commit: cocoon-2.1/src/blocks/slide/samples flow.js
 
 What error did you get with repository? It is not a JS keyword.
 
 Chris
 
 [EMAIL PROTECTED] wrote:
 
 
 
 unico   2004/02/25 01:48:35
 
  Modified:src/blocks/slide/samples flow.js
  Log:
  rhino seems to barf on 'repository' keyword
  
  Revision  ChangesPath
  1.12  +1 -2  cocoon-2.1/src/blocks/slide/samples/flow.js
  
  Index: flow.js 
  
 ===
  RCS file: /home/cvs/cocoon-2.1/src/blocks/slide/samples/flow.js,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- flow.js   17 Feb 2004 00:02:43 -  1.11
  +++ flow.js   25 Feb 2004 09:48:35 -  1.12
  @@ -4,9 +4,8 @@
   
   
 
 importPackage(Packages.org.apache.cocoon.components.source.helpers);
 
 
   importPackage(Packages.org.apache.cocoon.samples.slide);
   importPackage(Packages.org.apache.excalibur.source);
  -importPackage(Packages.org.apache.cocoon.components.repository);
   
  -var repository = cocoon.getComponent(SourceRepository.ROLE);
  +var repository =
   
 
 cocoon.getComponent('org.apache.cocoon.components.repository.S
 ourceRepository');
 
 
   var resolver = cocoon.getComponent(SourceResolver.ROLE);
   var global = cocoon.getComponent(InputModule.ROLE +
   
 
 Selector).select(global);
 
 
   var namespace = global.getAttribute(namespace,null,null);

Re: Flowscript and return to pipeline

Antonio Gallardo wrote:

AFAIK, there as an initiative to use javascript in XSP. But for a lack of
interest there is not fully developed.
 

Yes, I know. But I dont like XSP. I think XSP is not the best way to 
integrate logic.

For historical reasons flow was introduced with flowscript for
convenience. Later was found the advantages of using Javascript in Flow.
There was hard discusion. You can search cocoon-dev mailarchives about
this topic.
 

Yes. But what I want to say is: Why should I use the one language to 
integrate this logic and the other language to integrate other logic? 
Why not bring it all together? Why cant I use a JavaScript like an 
action? Or did you ever seen a car which only can turn left? ;-))

The more different types of integrating logic are possible the more 
complicated cocoon will become.

To put it all in a nutshell:

I think a solution like this:

map:match pattern=first
  map:call function=getValues return=true/
  map:transform type=jxt/
  map:serialize/
/map:match
is more easier to understand than this:

map:match pattern=first
  map:call function=getValues/
/map:match
map:match pattern=second
  map:generate type=jxt/
  map:serialize/
/map:match
ok, this is possible, too:

map:match pattern=first
  map:act type=getValues/
  map:transform type=jxt/
  map:serialize/
/map:match
But here I have to use two different languages. In our company we have 
many html-developers who can use JavaScript but nowone is able to using 
Java. So we have to realize the simple logic part by the expensive 
web-developers, too!

Regards
Stephan

Re: Flowscript and return to pipeline

2004-02-26 Thread Leszek Gawron

On Thu, Feb 26, 2004 at 10:22:12AM +0100, Stephan Coboos wrote:
 I think a solution like this:
 
 map:match pattern=first
   map:call function=getValues return=true/
   map:transform type=jxt/
   map:serialize/
 /map:match

 is more easier to understand than this:
 
 map:match pattern=first
   map:call function=getValues/
 /map:match
 
 map:match pattern=second
   map:generate type=jxt/
   map:serialize/
 /map:match
 
 ok, this is possible, too:
 
 map:match pattern=first
   map:act type=getValues/
   map:transform type=jxt/
   map:serialize/
 /map:match
Not easier to understand at all as you are mixing concerns. With 2 lines of
code you have mixed model and view.

While with flow it looks like this: 

 map:match pattern=first
   map:call function=getValues/
 /map:match

This means that some part of the controller should be initiated

The controler first builds up a data model (your getValues function) and then
basing on it's current state/model content etc. chooses what view to use to
render the data.

Sitemap should only contain controller hooks and the info on how to render the
views. When using flow the sitemap is not the controller any more - if you
used your approach you would have the controller logic spread in two different
places.

What if getValues function fails to fetch the data? 

If you really want to You can always do it like this:

map:match pattern=first
map:act type=serverpages src=get_values.xsp
!-- the action puts the values in request attribute and now you can
 use it from within jxtemplate --
map:generate type=jx src=values.jx/
map:serialize type=html/
map:act
map:generate src=failed-to-get-data.xml/
map:serialize type=html/
/map:match

You have 3 options for your actions:
- pure Java
- XSP 
- BSF (you can use Javascript too) - I do not know what state the BSF block is
  in right now as really nobody used it before.

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

Re: Flowscript and return to pipeline

2004-02-26 Thread Antonio Gallardo

Stephan Coboos dijo:
 is more easier to understand than this:

 map:match pattern=first
map:call function=getValues/
 /map:match

 map:match pattern=second
map:generate type=jxt/
map:serialize/
 /map:match



Did you already saw the advantage of this?:

map:pipeline
  map:match pattern=first
 map:call function=getValues/
  /map:match
/map:pipeline

map:pipeline internal-only=true
  map:match pattern=second
 map:generate type=jxt/
 map:serialize/
  /map:match
/map:pipeline

No matter how they will try to go to second they MUST go through
first. I like this feature of flow. :-D

AFAIK, in a webapp you can also review the authentication and authorization:

map:pipeline internal-only=true
  map:match pattern=fo-*.pdf
map:generate src=docs/informes/fo-{1}/
map:transform src=stylesheets/fo-{1}2fo.xsl/
map:serialize type=fo2pdf/
  /map:match
  ...
/map:pipeline

map:pipeline
  map:match pattern=*
map:call function=protect
  map:parameter name=handler value=authhandler/
  map:parameter name=protected-internal value={1}/
  map:parameter name=failure-redirect value=/login?resource={1}/
/map:call
  /map:match
/map:pipeline

Instead of the old approach using actions:

!-- PDF docs --
map:match pattern=*-*.pdf
  map:act type=auth-protect
map:parameter name=handler value=auth_handler/
map:act type=xsp-action
  src=resources/xsp-actions/auth-control-access.xsp
  map:parameter name=handler value=auth_handler/
  map:parameter name=authorisation value=pdf_docs/
  !-- Output PDF docs --
map:match pattern=fo-*.pdf
  map:generate src=docs/informes/fo-{1}/
  map:transform src=stylesheets/fo-{1}2fo.xsl/
  map:serialize type=fo2pdf/
/map:match
/map:act
  /map:act
/map:match

What is easier? For sure using Flow. :-D

Best Regards,

Antonio Gallardo.

Re: Flowscript and return to pipeline

Leszek Gawron wrote:

On Thu, Feb 26, 2004 at 10:22:12AM +0100, Stephan Coboos wrote:

I think a solution like this:

map:match pattern=first
map:call function=getValues return=true/
map:transform type=jxt/
map:serialize/
/map:match

is more easier to understand than this:

map:match pattern=first
map:call function=getValues/
/map:match
map:match pattern=second
map:generate type=jxt/
map:serialize/
/map:match
ok, this is possible, too:

map:match pattern=first
map:act type=getValues/
map:transform type=jxt/
map:serialize/
/map:match

Not easier to understand at all as you are mixing concerns. With 2 lines of
code you have mixed model and view.

What are the differences between this two solutions?

map:match pattern=first
map:call function=getValues return=true/
map:transform type=jxt/
map:serialize/
/map:match
and

map:match pattern=first
map:act type=serverpages src=get_values.xsp
!-- the action puts the values in request attribute and now you can
use it from within jxtemplate --
map:generate type=jx src=values.jx/
map:serialize type=html/
map:act
map:generate src=failed-to-get-data.xml/
map:serialize type=html/
/map:match
Therefore I wrote why not using flowscript like actions?

Please note the attribute return=true in the map:call/. This tells cocoon what the flow will always return into the sitemap at this position and is not able to use sendPage or sendPageAndWait. I think this would be a possible way to realize integration of flowscript.

What if getValues function fails to fetch the data?
Of course another way could be to to use a construct like this:

map:match pattern=first
map:act type=flowscript
!-- Do something here --
/map:act
map:transform type=jxt/
map:serialize/
/map:match
- BSF (you can use Javascript too) - I do not know what state the BSF block is
in right now as really nobody used it before.
OK. But this seems to be a problem. I have to use this option in a production environment and therefore it has to be stable.

It should be possible to say: Use flowscript for _all_ your logic problems. The one way should be to use it with sendPage, ... and another way to use it without this functions and instead with a if-else-construct within the pipeline like in actions. So you have one technique which solves the most problems.

Regards
Stephan

Re: Flowscript and return to pipeline

Antonio Gallardo wrote:

Stephan Coboos dijo:
 

is more easier to understand than this:

map:match pattern=first
  map:call function=getValues/
/map:match
map:match pattern=second
  map:generate type=jxt/
  map:serialize/
/map:match
   



Did you already saw the advantage of this?:

map:pipeline
 map:match pattern=first
map:call function=getValues/
 /map:match
/map:pipeline
map:pipeline internal-only=true
 map:match pattern=second
map:generate type=jxt/
map:serialize/
 /map:match
/map:pipeline
No matter how they will try to go to second they MUST go through
first. I like this feature of flow. :-D
 

Yes, of course. We are using this, too. But to decide, which 
internal-only pipeline was called from the flowscript you have to take a 
look into the script or create a good documentation of your sitemap! I 
want not to say using flowscript to call another pipeline in some ways 
is bad. I want to say it should be optional and marked in the sitemap in 
any way (with return=true for example).

1.) This flowscript comes back (it is not possible to switch within 
the flowscript):
map:call function=getValues return=true/

2.) This flowscript comes not back:
map:call function=getValues/
Thats all.

Regards
Stephan

RE: excalibur-component

2004-02-26 Thread Hamilton Verissimo de Oliveira (Engenharia - SPO)

I don't understand.  I'm looking for the source that matches the snapshot
sent out in Cocoon 2.1.4. 

 -Original Message-
From:   Hamilton Verissimo de Oliveira (Engenharia - SPO)
[mailto:[EMAIL PROTECTED] 
Sent:   Thursday, February 26, 2004 9:03 AM
To: [EMAIL PROTECTED]
Subject:Re: excalibur-component

Easy, Carsten and Leo Sutic are working on a release by now. It will be
ready real soon. 

regards,
hammett

-Mensagem original-
De: Ralph Goers [mailto:[EMAIL PROTECTED]
Enviada em: quinta-feira, 26 de fevereiro de 2004 13:55
Para: '[EMAIL PROTECTED]'
Assunto: excalibur-component

I guess Carsten is out of town?  Does anybody else know how to get the
source for the snapshot of excalibur-component used in Cocoon.  I looked at
the avalon-excalibur in CVS and didn't see any tags that match. Am I
supposed to check out by the date and hope that nothing else got changed
after it was checked out for Cocoon?

Re: excalibur-component


Easy, Carsten and Leo Sutic are working on a release by now. It will be
ready real soon. 


regards,
hammett

-Mensagem original-
De: Ralph Goers [mailto:[EMAIL PROTECTED]
Enviada em: quinta-feira, 26 de fevereiro de 2004 13:55
Para: '[EMAIL PROTECTED]'
Assunto: excalibur-component


I guess Carsten is out of town?  Does anybody else know how to get the
source for the snapshot of excalibur-component used in Cocoon.  I looked at
the avalon-excalibur in CVS and didn't see any tags that match. Am I
supposed to check out by the date and hope that nothing else got changed
after it was checked out for Cocoon?

DO NOT REPLY [Bug 27254] New: - Loader.java does not work well in Windows environment

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27254.
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=27254

Loader.java does not work well in Windows environment

   Summary: Loader.java does not work well in Windows environment
   Product: Cocoon 2
   Version: 2.1.4
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The cocoon bootstrap loader (in the tools/loader directory) does not work
if an absolute path is used for a repository passed to the loader with the
loader.jar.repositories system property.
If the repository path contains a drive letter, e.g. C:\foo\repository
the following parsing code of Loader jar splits the path in two parts

Loader.java
...
StringTokenizer st = new StringTokenizer(repositories,,;:);
while (st.hasMoreTokens()) {
classLoader.addRepository(new File(st.nextToken()));
}
...
/Loader.java

The result is, that the repositories C and \foo\repository are added to the 
loader (It even works in the case that the VM's current working directory is
somewhere on C:).

I would suggest to replace the ,;: with File.pathSeparator and modify
cocoon.bat and cocoon.sh accordingly.

DO NOT REPLY [Bug 27249] - You cannot lookup components on a disposed ComponentLocator exception

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27249.
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=27249

You cannot lookup components on a disposed ComponentLocator exception





--- Additional Comments From [EMAIL PROTECTED]  2004-02-26 15:13 ---
Also from Christian Mayrhuber [EMAIL PROTECTED] on users@:

I had this issue too, both in 2.1.3 and 2.1.4.
I've the impression that this issue has something to do with sitemap
reloading.

The only hack I found was to disable the Disposable interface in
ExcaliburComponentManager.

RE: Flowscript and return to pipeline

2004-02-26 Thread Hunsberger, Peter

Stephan Coboos [EMAIL PROTECTED] writes:

 
 Christopher Oliver wrote:
 
  Um, how much harder is this:
 
  map:match pattern=listProducts
   map:generate type=file src=products.xml/
   map:call function=readProductBeans/
  /map:match
 
  map:match pattern=listProducts-result-pipeline
   map:generate type=jxt/
   map:transform type=xslt/
   map:serialize/
  /map:match
 
 
 Yes we had tried this solution, too. But we have much more 
 flowscripts 
 than only readProductBeans and for each one we have to split our 
 pipeline. 

Well there's one problem, if you look through the archives you'll see
that you can do at least half of this generically:

map:match pattern=*/**
map:call function=main
map:parameter name=p1 value={1}/ 
map:parameter name=p2 value={2}/ 
/map:call
/map:match

Though I prefer the more general pattern that also selects on the
request method and calls the continuation on POST.  That aside, your
flowscript then can do things like:

function main( source, screen ) // p1, p2 from sitemap...
{
/*
Apply any screen specific overrides
*/
var sFunc = this[ screen ];
  if ( sFunc != undefined )
{
  var args = new Array( source, screen );
sFunc.apply( this, args );
}
else
{
while ( true )
{
if ( _sendPageAndValidate( run/_page/ + screen, source
) )
_performAction( );
}
}
}
}

function readProductBeans( source, screen )   // Page specific logic

{
.
.
.
}

It might not be possible for all your returns into the sitemap to be
generic, 80% of our pages are handled by a pipeline that resembles:

map:match pattern=*/_page/**
map:call resource=default/
map:act set=default
map:transform
src=stylesheets/resolveobjectswithdata.xsl/
map:transform src=stylesheets/renderhtml.xsl
map:parameter name=dataId value={dataId}/
map:parameter name=parentId value={parentId}/
map:parameter name=refId value={refId}/
/map:transform
map:serialize/
/map:act
/map:match

However, in some cases the page specific logic calls other sitemap
patterns.  
 
 Therefore the sitemap will become a unreadable 
 size. The other 
 point is, if you (as designer or htmler) dont know, what function 
 readProductBeans does you cant decide which pipeline will be called 
 next. In you example, it is easy. In real projects it is possible to 
 become a terrible find action. It would be more understanding for the 
 html-designer if you can say: Here are your templates and 
 with this call 
 you can get all your data you need. Do it.
 
 We want to creat a more generic way in which the 
 html-designer is able 
 to plug-in his on pipelines. No we are doing something like 
 this and I 
 think this is not the best solution:
 
 map:match pattern=listProducts
  map:generate type=file/
  map:act type=listProductAction/
  map:transform type=xslt/
  map:serialize/
 /map:match
 

I think if you're creating many different sitemap matches your
application logic is not generalized enough.  Actions, flowscript, XSLT
and every component of Cocoon that I can think of can all be parameter
driven, there should be no reason to have dozens of page specific
matchers in the pipeline.  

Part of the trick here is not to directly use XSLT to build pages but
rather to render templates to build pages.  You turn your html design
process into a process of describing templates that are turned into HTML
by an XSLT.  Desigerns add generic logic to the XSLT to get new page
design elements and then add new elements to the templates to invoke
these elements, but all design elements are available to all pages and
specific page logic isn't needed.

Re: PDF Encryption

Without looking into it...

What about a wiki page how you got this working?

Sounds like a good addition!

cheers
--
Torsten

Re: FOP with embeded SVG doesn't render at correct size in Cocoon

I've got a weird problem generating pdfs using FOP from xml containing 
SVG; but only when processed through Cocoon (2.1.2). Generation directly 
with FOP is problem free.
Same FOP version? Do you imply other Cocoon versions are working?

cheers
--
Torsten

DO NOT REPLY [Bug 27260] New: - Stackoverflow using xslt from subsitemap with cocoon://-protocol

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27260.
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=27260

Stackoverflow using xslt from subsitemap with cocoon://-protocol

   Summary: Stackoverflow using xslt from subsitemap with cocoon://-
protocol
   Product: Cocoon 2
   Version: 2.1.4
  Platform: PC
   URL: http://localhost:/anything.except.test
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When upgrading from 2.1.3 to 2.1.4 I got an infinite loop in my application 
that resulted in out-of-memory.

I have narrowed it down to the following simple test-case. This simple test 
eventually results in a stackoverflow at my system, running WinXP with suns 
j2sdk1.4.2_02.

The testcase works in 2.1.3, so to me this seems to have been introduced in 
2.1.4.

If I change cocoon://test/test.xslt to http://localhost/test/test.xslt; in 
the parent sitemap the problem vanishes.

Accessing http://localhost:/anything.except.test; results in an 
stackoverflow

Snippet of main sitemap:
-
map:match pattern=test/**
map:mount check-reload=no src=test/ uri-prefix=test/ 
/map:match
map:match pattern=**
map:generate type=file src=test/test.xml/
map:transform type=xslt src=cocoon://test/test.xslt/
map:serialize type=xml/
/map:match

Snippet of sub-sitemap in test/:
--
map:pipelines
map:pipeline
map:match pattern=test.xslt
map:generate type=file src=test.xslt/
map:serialize type=xml/
/map:match
/map:pipeline
/map:pipelines


test.xml in test/
-
?xml version=1.0 encoding=UTF-8?
testHello world??/test

test.xslt in test/
--
?xml version=1.0 encoding=UTF-8?
xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:output method=xml version=1.0 encoding=UTF-8 indent=yes/
xsl:template match=test
modified.test.result
xsl:value-of select=./
/modified.test.result
/xsl:template
/xsl:stylesheet

Re: ASF Board Summary for February 18, 2004

So what about the following...

+ the boilerplate

--
/*
 Copyright 1999-2004 The Apache Software Foundation. All rights reserved.
 Licensed under the Apache License, Version 2.0 (the License);
 you may not use this file except in compliance with the License.
 You may obtain a copy of the License at
  http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an AS IS BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and
 limitations under the License.
*/
--
+ copy of http://www.apache.org/licenses/LICENSE-2.0.txt
  as LICENCE file the root dir
+ the NOTICE file in the root dir

--
 This product includes software developed by
 The Apache Software Foundation (http://www.apache.org/).
 It consists of voluntary contributions made by many individuals
 on behalf of the Apache Software Foundation and was originally created
 by Stefano Mazzocchi [EMAIL PROTECTED]. Please visit the project
 homepage (http://cocoon.apache.org) for more information.
--
+ and we remove all author tags

cheers
--
Torsten

RE: Flowscript and return to pipeline

If you really want to use JavaScript in an action instead of Java, write an
action (in Java) that calls an arbitrary JavaScript function.  Maybe that's
what BSF does, I don't know.

Ralph

 -Original Message-
From:   Stephan Coboos [mailto:[EMAIL PROTECTED] 
Sent:   Thursday, February 26, 2004 2:28 AM
To: [EMAIL PROTECTED]
Subject:Re: Flowscript and return to pipeline

Therefore I wrote why not using flowscript like actions?

Re: ASF Board Summary for February 18, 2004

2004-02-26 Thread Steven Noels

On 26 Feb 2004, at 17:12, Torsten Curdt wrote:

+ and we remove all author tags
I find this just a little bit too reactionary - especially for the 
little known/used areas of code. We haven't had ownership issues 
because of them in the past, not? These tags sometimes help to find a 
contact, when questions remain unanswered on the list.

/Steven
--
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: excalibur-component

2004-02-26 Thread Geoff Howard

Ralph Goers wrote:

I guess Carsten is out of town?  Does anybody else know how to get the
source for the snapshot of excalibur-component used in Cocoon.  I looked at
the avalon-excalibur in CVS and didn't see any tags that match. Am I
supposed to check out by the date and hope that nothing else got changed
after it was checked out for Cocoon? 
 

Yes, though.  Check out by date should work and I'm pretty sure you'll 
find by browsing the cvs that the volume of commits on 
excalibur-component is low enough that you won't have any commits around 
that date.

Geoff

RE: excalibur-component

Thanks for the info.  
Maybe I misunderstood, but I had requested before the release that the
source for snapshots be made available from Cocoon's site.  I thought that
this had been agreed to.  It is a royal pain for me to do CVS checkouts from
work.  Also, I'd like to know with 100% certainty that I actually have the
same source Cocoon used to build with.  I see snapshots for commons-jexl,
commons-jxpath, excalibur-store, and rhino along with excalibur-component.
Am I supposed to do the same thing and hope for the best with them as well?

Ralph 

 -Original Message-
From:   Geoff Howard [mailto:[EMAIL PROTECTED] 
Sent:   Thursday, February 26, 2004 9:13 AM
To: [EMAIL PROTECTED]
Subject:Re: excalibur-component

Ralph Goers wrote:

I guess Carsten is out of town?  Does anybody else know how to get the
source for the snapshot of excalibur-component used in Cocoon.  I looked at
the avalon-excalibur in CVS and didn't see any tags that match. Am I
supposed to check out by the date and hope that nothing else got changed
after it was checked out for Cocoon? 
  


Yes, though.  Check out by date should work and I'm pretty sure you'll 
find by browsing the cvs that the volume of commits on 
excalibur-component is low enough that you won't have any commits around 
that date.

Geoff

Re: ASF Board Summary for February 18, 2004

2004-02-26 Thread Tim Larson

On Thu, Feb 26, 2004 at 07:00:09PM +0100, Torsten Curdt wrote:
 Steven Noels wrote:
 On 26 Feb 2004, at 17:12, Torsten Curdt wrote:
 
 + and we remove all author tags
 
 
 I find this just a little bit too reactionary - especially for the 
 little known/used areas of code. We haven't had ownership issues 
 because of them in the past, not? These tags sometimes help to find a 
 contact, when questions remain unanswered on the list.
 
 Well, a lot of people gave their +1
 
 I am far from pushing this - actually I see it exactly like you do.
 
 ...but IIRC the board explicitly discouraged the author tag and
 we also had a lengthy discussion about this. Since we need to
 update the license anyway, I thought this might be the right time
 to follow the board's advice.

Just to clarify my +1...
I do NOT think removing the author tags is a generally good idea.
I voted +1 because since (unless I misinterpreted) the board is
just about requiring it, so I thought why not do it now.

An author tag just says this person put significant work into this
file.  Since there is no copyright notice next to the @author tag,
and there IS a clear license or reference to a license right above
it *with a copyright notice and the name of the copyright holder*
I have a hard time seeing how the board finds a problem with the
presence of the author tags.

If the board makes us (or convinces us that it is best to) remove
the tags then I do not have a problem with my name leaving with
the rest of the names, but I will think this is a silly way to
encourage voluntary collaborative development.

--Tim Larson

Re: PDF Encryption

2004-02-26 Thread J.Pietschmann

Torsten Curdt wrote:
What about a wiki page how you got this working?
See
 http://xml.apache.org/fop/pdfencryption.html
for how to set up the infrastructure and the relevant
cocoon pages for passing options to the renderer.
J.Pietschmann

RE: excalibur-component



So how can I formally request that this be a requirement in future builds -
and possibly get something for 2.1.4 as well.  

Suppose I was to deploy my product now base on 2.1.4 and I didn't capture
all the source for the dependent components and  in 6 months or so a bug is
reported.  To debug the problem I could need the source for anything that
might be involved.  If I didn't have the foresight to grab the source now
I'd be SOL if the component in question had done anything to their cvs
repository.  So obviously, I want to grab the source for each of the
components Cocoon uses when I upgrade to a new Cocoon version.  This is
pretty easy for formally released components - I just go to their website
and download the corresponding zip file.  But for snapshots Cocoon really is
the owner of the exact source used.  So it should be zipped up and available
from Cocoon's website.  At least, that's my opinion.

Ralph 

 -Original Message-
From:   Geoff Howard [mailto:[EMAIL PROTECTED] 
Sent:   Thursday, February 26, 2004 10:16 AM
To: [EMAIL PROTECTED]
Subject:Re: excalibur-component


Unfortunately, that's probably exactly what you'll need to do.  I don't 
recall whether there was a consensus on keeping the sources with the 
snapshots but I think you're right about that.  Unfortunately, consensus 
that something should happen does not translate always to action - 
especially when there is no formal [VOTE] thread.  Sorry about that - I 
think it's a pain too.  However, the chance that you could do a checkout 
by date and get different sources is a lower probability threat - you 
can review the commit logs (many of them are sent to a publicly archived 
mail list such as [EMAIL PROTECTED]) and usually determine with 
confidence that what you have is correct.  The big arguments in favor of 
the source-snapshot were: 1) firewall cvs checkout problems 2) cvs 
history lost by repository reshuffling.  The second won't be a problem 
with recent snapshots.

Of course, maybe Carsten did do a source snapshot of those projects but 
he just did the release.  Most of those were probably checked in before 
the release and before that discussion.

Geoff

Re: [RT] Cocoon Input Model

2004-02-26 Thread Guido Casper

Daniel Fagerstrom wrote:

So a pipeline for input handling could look like:

g - t* - store - act - [select] - g - t* - s.
I'm still not convinced by this symmetry thing :-)

The requirements for inbound data flow seems to be too different from
those of outbound data flow.
For outbound data flow everything is converted to a string which is
quite easy and nicely supported by XML's weakly typed nature (IMO one
major reason for XMLs power and success) and a powerful transformation
language.
For inbound data flow (as you already mentioned) you need strongly typed
data which requires parsing, validation and error handling. I do see
value in putting this data - once grabbed and converted by the forms
framework - into some sort fo pipeline. What I'm unsure about is if
these pipelines will be of similar power as weakly typed pipelines. I
believe Cocoon's pipelines achieve this level of component reusability
because of its weakly typed (and therefore loosely coupled) nature.
Now IIUC you suggest a pipelining architecture for inbound data flow
with a DOM-like data model.
Since AFAIK there is no standard DOM-like data model/API carrying 
strongly typed data we would have to come up with our own and I feel it 
might eventual look similar to the Woody widget hierarchy.

So what exactly is it that makes the Woody widget hierarchy unsuitable
for being the data model of the inbound pipelining architecture?
Having said all that it ocurred to me that what you are describing is
what in parts may correspond to an XForms-like architecture.
Ignoring for a moment that XForms is a client side technology and
thinking about the artifacts a developer has to create.
There is a form description which has its datatypes and validation rules
described by an XML Schema (IIUC). After data validation and everything
is done the data is sent to the server as a (weakly typed) XML document
which may be fed into a pipeline. When entering the pipeline the
document may be validated against the very same XML schema that
validates the form on the client-side. The XML flowing through the
pipeline is still weakly typed yet might be treated in a strongly typed
manner (such as the XPath 2.0 data model to be accessed by XSLT 2.0 or
XQuery or some super-duper XUpdate-like whatever next generation XML
manipulation language). However as it stands today there is no standard
way to access such a strongly typed data model (like XML schema's PSVI 
Post Schema Validation Infoset) via Java (AFAIK). Maybe XMLBeans (as 
Steven suggested) could help here?

So what about an XML-adaptor-like component (you could even today do a 
processPipelineToDOM(pipelineWithWoodyGenerator)) instead of changing 
Woody's internal data model?

Guido

Re: [RT] Cocoon Input Model

2004-02-26 Thread Alan

* Guido Casper [EMAIL PROTECTED] [2004-02-26 20:41]:
 Daniel Fagerstrom wrote:
 
 So a pipeline for input handling could look like:
 
 g - t* - store - act - [select] - g - t* - s.
 
 I'm still not convinced by this symmetry thing :-)
 
 The requirements for inbound data flow seems to be too different from
 those of outbound data flow.
 
 For outbound data flow everything is converted to a string which is
 quite easy and nicely supported by XML's weakly typed nature (IMO one
 major reason for XMLs power and success) and a powerful transformation
 language.
 
 For inbound data flow (as you already mentioned) you need strongly typed
 data which requires parsing, validation and error handling. I do see
 value in putting this data - once grabbed and converted by the forms
 framework - into some sort fo pipeline. What I'm unsure about is if
 these pipelines will be of similar power as weakly typed pipelines. I
 believe Cocoon's pipelines achieve this level of component reusability
 because of its weakly typed (and therefore loosely coupled) nature.
 
 Now IIUC you suggest a pipelining architecture for inbound data flow
 with a DOM-like data model.

What do you mean by strongly typed? Are we discussiong form posts
here?

For some time now, I've wondered how one would post XML to
Cocoon and start out with it in the pipeline. Cocoon would make
short work of REST implementations.

(Trying to get up to speed.)

-- 
Alan / [EMAIL PROTECTED] / http://engrm.com/
aim/yim: alanengrm - icq: 228631855 - msn: [EMAIL PROTECTED]

Re: [RT] Cocoon Input Model

2004-02-26 Thread Geoff Howard

Alan wrote:

* Guido Casper [EMAIL PROTECTED] [2004-02-26 20:41]:
 

Daniel Fagerstrom wrote:

   

So a pipeline for input handling could look like:

g - t* - store - act - [select] - g - t* - s.
 

I'm still not convinced by this symmetry thing :-)

The requirements for inbound data flow seems to be too different from
those of outbound data flow.
For outbound data flow everything is converted to a string which is
quite easy and nicely supported by XML's weakly typed nature (IMO one
major reason for XMLs power and success) and a powerful transformation
language.
For inbound data flow (as you already mentioned) you need strongly typed
data which requires parsing, validation and error handling. I do see
value in putting this data - once grabbed and converted by the forms
framework - into some sort fo pipeline. What I'm unsure about is if
these pipelines will be of similar power as weakly typed pipelines. I
believe Cocoon's pipelines achieve this level of component reusability
because of its weakly typed (and therefore loosely coupled) nature.
Now IIUC you suggest a pipelining architecture for inbound data flow
with a DOM-like data model.
   

What do you mean by strongly typed? Are we discussiong form posts
   here?
   For some time now, I've wondered how one would post XML to
   Cocoon and start out with it in the pipeline. Cocoon would make
   short work of REST implementations.
   (Trying to get up to speed.)
 

There are a couple of ways to do this now.  Stream generator, and I 
think an input module both handle that.  Don't think the request 
generator does, but I could be wrong.  Don't think that's what is being 
discussed though.

Geoff

RE: [RT] Cocoon Input Model

Daniel's message got me to thinking. In our case we don't really need the
power of Cocoon forms as we are perfectly happy using XSLT to generate html.
All we'd like is something a little better than the FormValidatorAction.  I
could easily see a new action that that invokes a pipeline to process the
input parameters, much like the authentication framework does. I could
visualize a generator that converts the request parameters into XML and then
uses an XML Schema to validate them. Further transforms could then be used
to further validate or transform the data.  Ideally, the resulting XML could
then be used to populate a Java object or just be passed on to other
actions, etc.

Ralph

 -Original Message-
From:   Guido Casper [mailto:[EMAIL PROTECTED] 
Sent:   Thursday, February 26, 2004 12:47 PM
To: [EMAIL PROTECTED]
Subject:Re: [RT] Cocoon Input Model

Daniel Fagerstrom wrote:

 So a pipeline for input handling could look like:
 
 g - t* - store - act - [select] - g - t* - s.

I'm still not convinced by this symmetry thing :-)

The requirements for inbound data flow seems to be too different from
those of outbound data flow.

For outbound data flow everything is converted to a string which is
quite easy and nicely supported by XML's weakly typed nature (IMO one
major reason for XMLs power and success) and a powerful transformation
language.

For inbound data flow (as you already mentioned) you need strongly typed
data which requires parsing, validation and error handling. I do see
value in putting this data - once grabbed and converted by the forms
framework - into some sort fo pipeline. What I'm unsure about is if
these pipelines will be of similar power as weakly typed pipelines. I
believe Cocoon's pipelines achieve this level of component reusability
because of its weakly typed (and therefore loosely coupled) nature.

Now IIUC you suggest a pipelining architecture for inbound data flow
with a DOM-like data model.

Since AFAIK there is no standard DOM-like data model/API carrying 
strongly typed data we would have to come up with our own and I feel it 
might eventual look similar to the Woody widget hierarchy.

So what exactly is it that makes the Woody widget hierarchy unsuitable
for being the data model of the inbound pipelining architecture?

Having said all that it ocurred to me that what you are describing is
what in parts may correspond to an XForms-like architecture.

Ignoring for a moment that XForms is a client side technology and
thinking about the artifacts a developer has to create.
There is a form description which has its datatypes and validation rules
described by an XML Schema (IIUC). After data validation and everything
is done the data is sent to the server as a (weakly typed) XML document
which may be fed into a pipeline. When entering the pipeline the
document may be validated against the very same XML schema that
validates the form on the client-side. The XML flowing through the
pipeline is still weakly typed yet might be treated in a strongly typed
manner (such as the XPath 2.0 data model to be accessed by XSLT 2.0 or
XQuery or some super-duper XUpdate-like whatever next generation XML
manipulation language). However as it stands today there is no standard
way to access such a strongly typed data model (like XML schema's PSVI 
Post Schema Validation Infoset) via Java (AFAIK). Maybe XMLBeans (as 
Steven suggested) could help here?

So what about an XML-adaptor-like component (you could even today do a 
processPipelineToDOM(pipelineWithWoodyGenerator)) instead of changing 
Woody's internal data model?

Guido

Re: ASF Board Summary for February 18, 2004

2004-02-26 Thread David Crossley

Torsten Curdt wrote:
 Steven Noels wrote:
  Torsten Curdt wrote:
  
  + and we remove all author tags
  
  
  I find this just a little bit too reactionary - especially for the 
  little known/used areas of code. We haven't had ownership issues 
  because of them in the past, not? These tags sometimes help to find a 
  contact, when questions remain unanswered on the list.
 
 Well, a lot of people gave their +1
 
 I am far from pushing this - actually I see it exactly like you do.
 
 ...but IIRC the board explicitly discouraged the author tag and
 we also had a lengthy discussion about this. Since we need to
 update the license anyway, I thought this might be the right time
 to follow the board's advice.

IIRC, when we talked about author tags last time, one of
the main points was that people can look at the Changes
page to find out who was the major contributer for a certain
facility and who has been working on it. This is also by far
the best way to give encouragement to the community. We do not
need the author tags in code and docs.

There is an added benefit to this approach. It makes us devs
be more mindful of keeping Changes up-to-date.

--David

@author tags (WAS: RE: ASF Board Summary for February 18, 2004)

2004-02-26 Thread Conal Tuohy

I agree with Antonio about the utility of @author tags (I have also found them very 
useful), and I also think that the ASF board's concerns about the dangers of 
ownership are probably overblown.

I don't think the ASF should discourage developers from keeping useful metadata about 
the code inside the source files. What better place to put the metadata than in the 
code? This makes it more likely to be used and kept up to date than if it was stored 
somewhere else, IMHO. 

I don't agree with the idea that banning author tags would make the changes file 
more useful because it would encourage developers to keep it up to date. On the 
contrary, I think people are encouraged when you make things easy; I don't think 
requiring people to do things the hard way constitutes encouragement. :-)

If the board insists then ... OK ... but if the board only discourages the use of 
@author tags on the grounds that they COULD cause problems, then I think Cocoon should 
note their concern but keep the @author tags because in THIS CASE they have NOT caused 
problems.

Just my 2c.

Con

 -Original Message-
 From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
 Sent: Friday, 27 February 2004 7:53 a.m.
 To: [EMAIL PROTECTED]
 Subject: Re: ASF Board Summary for February 18, 2004
 
 
 Steven Noels dijo:
  On 26 Feb 2004, at 17:12, Torsten Curdt wrote:
 
  + and we remove all author tags
 
  I find this just a little bit too reactionary - especially for the
  little known/used areas of code. We haven't had ownership issues
  because of them in the past, not? These tags sometimes help 
 to find a
  contact, when questions remain unanswered on the list.
 
 [RT]:
 
 Will be enough to browse the CVS to find the folks involved 
 in a concrete
 file or block? No, we cannot trace many files to the first post. The
 original file, who made changes, etc?
 
 When I started to use the auth-fw, the @author tags allow me 
 to know the
 names of people that was involved in this. After this I also used the
 names to harvest the mailarchives looking for help about the auth-fw.
 
 Best Regards,
 
 Antonio Gallardo.

Re: ASF Board Summary for February 18, 2004

--
/*
 Copyright 1999-2004 The Apache Software Foundation. All rights reserved.
 Licensed under the Apache License, Version 2.0 (the License);
 you may not use this file except in compliance with the License.
 You may obtain a copy of the License at
  http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an AS IS BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and
 limitations under the License.
*/
--


Why the leading spaces?
Well, the old header had spaces, too
...but we can omit them :)
Will we just have all files as 1999-2004 or do we need to
determine the actual first and last modification date of
each file? The latter is an awful lot of work, but if we
need to do it then there are some tools in the CVS module
committers/tools which might help.
Nah... we never cared about that before. I don't think...
...does anyone think we have to??
Obviously the boilerplate for *.xml etc. will be different
comment markers.
Of course!

Actually i have noticed a trend that people are focussing
on the *.java files only (see the current scripts in
committers/relicense) and are forgetting the big job
of every other text file.
Hm does really each and every file need the boilerplate??
...code for sure - but usual text files?
--
 This product includes software developed by
 The Apache Software Foundation (http://www.apache.org/).
 It consists of voluntary contributions made by many individuals
 on behalf of the Apache Software Foundation and was originally created
 by Stefano Mazzocchi [EMAIL PROTECTED]. Please visit the project
 homepage (http://cocoon.apache.org) for more information.
--


I think that the Stefano entry should not have special treatment
at the top, but rather be one entry in the list that would follow,
presumably the first entry.
If that's ok with him... Stefano?

+ and we remove all author tags


I suppose so, and in both *.java and *.xml
Well, this seems to need some more discussion ;)

cheers
--
Torsten

Re: ASF Board Summary for February 18, 2004

2004-02-26 Thread Antoine Lévy-Lambert

I noticed your discussion regarding the new licenses.

Torsten Curdt wrote:

Nah... we never cared about that before. I don't think...
...does anyone think we have to??
About the copyright dates, you can read the email of Conor McNeill.
http://article.gmane.org/gmane.comp.jakarta.ant.devel/26477/match=copyright+years
Both the java and the python program to update the license boiler plates 
pay attention to the respect of prior copyright dates information.
(they are in the committers repository)

Cheers,

Antoine

Re: ASF Board Summary for February 18, 2004

2004-02-26 Thread David Crossley

Vadim Gritsenko wrote:
 Torsten Curdt wrote:
 David Crossley wrote:
 
  Will we just have all files as 1999-2004 or do we need to
  determine the actual first and last modification date of
  each file? The latter is an awful lot of work, but if we
  need to do it then there are some tools in the CVS module
  committers/tools which might help.
 
  Nah... we never cared about that before. I don't think...
  ...does anyone think we have to??

 I don't think so. Last time we had blind upgrade to (c) -2003.

The beginning date is the main problem. Some files would
not come into existence until say 2002. Blindly putting
an erroneous start date of 1999 may lead to legal issues,
but IANAL.

--David

DO NOT REPLY [Bug 27279] - [PATCH] LDAPTransformer

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27279.
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=27279

[PATCH] LDAPTransformer





--- Additional Comments From [EMAIL PROTECTED]  2004-02-27 03:16 ---
Created an attachment (id=10580)
LDAPTransformation.java diff patch

Re: ASF Board Summary for February 18, 2004

2004-02-26 Thread Stefano Mazzocchi

Antonio Gallardo wrote:

Steven Noels dijo:

On 26 Feb 2004, at 17:12, Torsten Curdt wrote:


+ and we remove all author tags
I find this just a little bit too reactionary - especially for the
little known/used areas of code. We haven't had ownership issues
because of them in the past, not? These tags sometimes help to find a
contact, when questions remain unanswered on the list.


[RT]:

Will be enough to browse the CVS to find the folks involved in a concrete
file or block? No, we cannot trace many files to the first post. The
original file, who made changes, etc?
When I started to use the auth-fw, the @author tags allow me to know the
names of people that was involved in this. After this I also used the
names to harvest the mailarchives looking for help about the auth-fw.
Yes, the author tag says something about who started the code, but 
nothing about how knows about that particular version of it and it 
creates copyright problems and increases spam.

+1 to remove them and +1 to pay back with our credits in the 
Changes/Credits page.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: ASF Board Summary for February 18, 2004

2004-02-26 Thread Vadim Gritsenko

Torsten Curdt wrote:

--
/*
 Copyright 1999-2004 The Apache Software Foundation. All rights 
reserved.

 Licensed under the Apache License, Version 2.0 (the License);
 you may not use this file except in compliance with the License.
 You may obtain a copy of the License at
  http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an AS IS BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 
implied.
 See the License for the specific language governing permissions and
 limitations under the License.
*/
--


Why the leading spaces?


Well, the old header had spaces, too
...but we can omit them :)


Can we please add leading stars (*)?

/*
* Copyright 1999-2004 The Apache Software Foundation. All rights reserved.
...
It autoformats better.


Will we just have all files as 1999-2004 or do we need to
determine the actual first and last modification date of
each file? The latter is an awful lot of work, but if we
need to do it then there are some tools in the CVS module
committers/tools which might help.


Nah... we never cared about that before. I don't think...
...does anyone think we have to??


I don't think so. Last time we had blind upgrade to (c) -2003.

Vadim

Re: ASF Board Summary for February 18, 2004

2004-02-26 Thread David Crossley

Torsten Curdt wrote:
 So what about the following...
 
 + the boilerplate
 
 --
 /*
   Copyright 1999-2004 The Apache Software Foundation. All rights reserved.
 
   Licensed under the Apache License, Version 2.0 (the License);
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at
 
http://www.apache.org/licenses/LICENSE-2.0
 
   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an AS IS BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.
 */
 --

Why the leading spaces?

Will we just have all files as 1999-2004 or do we need to
determine the actual first and last modification date of
each file? The latter is an awful lot of work, but if we
need to do it then there are some tools in the CVS module
committers/tools which might help.

Obviously the boilerplate for *.xml etc. will be different
comment markers.

Actually i have noticed a trend that people are focussing
on the *.java files only (see the current scripts in
committers/relicense) and are forgetting the big job
of every other text file.

 + copy of http://www.apache.org/licenses/LICENSE-2.0.txt
as LICENCE file the root dir
 
 + the NOTICE file in the root dir
 
 --
   This product includes software developed by
   The Apache Software Foundation (http://www.apache.org/).
 
   It consists of voluntary contributions made by many individuals
   on behalf of the Apache Software Foundation and was originally created
   by Stefano Mazzocchi [EMAIL PROTECTED]. Please visit the project
   homepage (http://cocoon.apache.org) for more information.
 --

I think that the Stefano entry should not have special treatment
at the top, but rather be one entry in the list that would follow,
presumably the first entry.

 + and we remove all author tags

I suppose so, and in both *.java and *.xml

--David

Change List, Re: ASF Board Summary for February 18, 2004

2004-02-26 Thread Vadim Gritsenko

David Crossley wrote:

Torsten Curdt wrote:
 

Steven Noels wrote:
   

Torsten Curdt wrote:

 

+ and we remove all author tags
   

I find this just a little bit too reactionary - especially for the 
little known/used areas of code. We haven't had ownership issues 
because of them in the past, not? These tags sometimes help to find a 
contact, when questions remain unanswered on the list.
 

Well, a lot of people gave their +1

I am far from pushing this - actually I see it exactly like you do.
   

...

IIRC, when we talked about author tags last time, one of
the main points was that people can look at the Changes
page to find out who was the major contributer for a certain
facility and who has been working on it.
Then it will have to be significantly extended. Currently it does not 
indicate in coherent (searchable) way what cocoon component or sitemap 
component or cocoon block this change relates to. And you need better 
granularity then simply core, cforms block; you need something which 
goes at least to the level of package (and author tags are on the class 
level).

Vadim

DO NOT REPLY [Bug 27275] New: - xsl:sort not sorting correctly

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27275.
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=27275

xsl:sort not sorting correctly

   Summary: xsl:sort not sorting correctly
   Product: Cocoon 2
   Version: 2.1.2
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Major
  Priority: Other
 Component: general components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The XSL Sort function is sorting the data in the correct order. It seems like 
it is random.

Re: PDF Encryption

 http://xml.apache.org/fop/pdfencryption.html
for how to set up the infrastructure and the relevant
cocoon pages for passing options to the renderer.
Excellent, thanks for the pointer...

...I put it into the wiki and added a new
way to configure the renderer...
http://wiki.cocoondev.org/Edit.jsp?page=FOPPDFEncryption

The new parameter passing works.

But the way through the user config
file seems to fail. Maybe someone
else has an idea why?
cheers
--
Torsten

RE: excalibur-component

Carsten,

I'm all for using only formal releases of dependent components.  I asked
about that several months ago and was told it was not possible, so instead I
asked for a way to get the same source that was used by the person who
integrated it into Cocoon.  If 2.1.5 and on will only use formal releases
that will suffice for me.

Ralph

 -Original Message-
From:   Carsten Ziegeler [mailto:[EMAIL PROTECTED] 
Sent:   Thursday, February 26, 2004 11:30 AM
To: [EMAIL PROTECTED]
Subject:RE: excalibur-component

As already said in this thread, the only working way to get 
the sources of the developer builds for excalibur-components
(and some others) is to check out the state from exactly 
the specified date. That's why a jar contains the date
in the name.

Now, we discussed this topic, but never agreed to anything :)
And I personally don't want to also store hundreds of sources
of other projects in the cocoon cvs.

Anyway, I asked the Avalon guys to release all relevant projects
for us and they are currently in the process of exactly doing
that for us - or more precisly Leo Sutic is doing most of the
work with some help from others. Thanks Leo!

So, I have the hope that starting with 2.1.5 we will stick
to a vote we made ages ago Only use released versions of other
projects :)

The current release process at Avalon has one main advantage:
making releases of those parts in the future becomes much easier.
So, if we need a release, at can simply be done.

Carsten

RE: excalibur-component

2004-02-26 Thread Carsten Ziegeler

As already said in this thread, the only working way to get 
the sources of the developer builds for excalibur-components
(and some others) is to check out the state from exactly 
the specified date. That's why a jar contains the date
in the name.

Now, we discussed this topic, but never agreed to anything :)
And I personally don't want to also store hundreds of sources
of other projects in the cocoon cvs.

Anyway, I asked the Avalon guys to release all relevant projects
for us and they are currently in the process of exactly doing
that for us - or more precisly Leo Sutic is doing most of the
work with some help from others. Thanks Leo!

So, I have the hope that starting with 2.1.5 we will stick
to a vote we made ages ago Only use released versions of other
projects :)

The current release process at Avalon has one main advantage:
making releases of those parts in the future becomes much easier.
So, if we need a release, at can simply be done.

Carsten

excalibur-component

I guess Carsten is out of town?  Does anybody else know how to get the
source for the snapshot of excalibur-component used in Cocoon.  I looked at
the avalon-excalibur in CVS and didn't see any tags that match. Am I
supposed to check out by the date and hope that nothing else got changed
after it was checked out for Cocoon?

Re: Flowscript and return to pipeline

If you really want to use JavaScript in an action instead of Java, write an
action (in Java) that calls an arbitrary JavaScript function.  Maybe that's
what BSF does, I don't know.
We already have a ScriptAction in the BSF block

cheers
--
Torsten

Re: USQL [was: Future of XSP and ESQL]

First, let's collect what we like about the two components


It would be very cool if we could provide something that helps with flow
applications.
 I like the combination of OR-Mapping/CForms/Flow but this
is for many beginners overkill. They shouldn't be forced to write Java
code e.g. in order to implement a simple register form.
...I see no reason why you could not use a possible
new USQL for easy flow stuff.
But first we need to find out what we like about
one or the other.
Why do *you* e.g. use ESQL rather the SQLTransformer
or the other way round? Or why do *you* use the
DatabaseActions...
Things like that
--
Torsten

Re: FOP with embeded SVG doesn't render at correct size in Cocoon

2004-02-26 Thread Steve Schwarz

Hi
I've got a weird problem generating pdfs using FOP from xml containing 
SVG; but only when processed through Cocoon (2.1.2). Generation directly 
with FOP is problem free.
Same FOP version? Do you imply other Cocoon versions are working?
Nope, I'm implying FOP standalone with the same FOP version as Cocoon uses 
works correctly :^)
It looks like when invoked through Cocoon FOP is still reserving the right 
amount of space (based on the svg with/height attributes) but then when 
Batik is invoked it is rendering the image at the incorrect scale(my 
guess?).

I tried dropping in the fop and batik jar files from Cocoon 2.1.4 and Cocoon 
still doesn't render the embedded SVG at large viewBox values correctly.

Can anyone tell me how the Cocoon fop and batik jar files are generated and 
how that is different from the jars supplied with FOP?

Thanks for the reply!
Steve
_
Get fast, reliable access with MSN 9 Dial-up. Click here for Special Offer! 
http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/

DO NOT REPLY [Bug 27249] New: - You cannot lookup components on a disposed ComponentLocator exception