Re: [VOTE] Give all Cocoon committers CVS access?
David Crossley wrote, On 25/06/2003 4.26: ... One disadvantage with moving Cocoon and Forrest away from xml.apache.org is that all Cocoon and Forrest committers are already automatically committers on xml-commons and could be helping that important project to find its feet. This is a good point, but a much wider issue IMHO. Cocoon committers have the same issue, so I'd favor a rule by which projects that have to do with xml have auto access to xml-commons, as it just makes sense. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Apache account request: Reinhard Poetz
Welcome Reinhard. As you know the new account has been established. The next step is to sign and send in the Contributors License Agreement (CLA). Then set up your CVS access over SSH and put a ~/.forward file at your cvs.apache.org home directory to forward your @apache.org email. There are some general background documents for new committers. Here is an effort to bring them together: http://nagoya.apache.org/wiki/apachewiki.cgi?PoliciesAndProcedures There is a communityatapache.org mailing list for all Apache committers that has occasional spurts of Apache-wide discussion. There is the committersatapache.org (announce-only) which has occasional broadcasts. There are some Cocoon-specific things to do, such as join the cocoon-cvs mailing list so that you see all cvs messages and join the Cocoon PMC. If there is anything that i have forgotten, just ask on cocoon-dev. --David
cvs commit: cocoon-2.1 status.xml
upayavira2003/06/25 00:40:22 Modified:.status.xml Log: Added CVS tag and added completed action for permanent redirects Revision ChangesPath 1.62 +5 -0 cocoon-2.1/status.xml Index: status.xml === RCS file: /home/cvs/cocoon-2.1/status.xml,v retrieving revision 1.61 retrieving revision 1.62 diff -u -r1.61 -r1.62 --- status.xml25 Jun 2003 00:58:39 - 1.61 +++ status.xml25 Jun 2003 07:40:21 - 1.62 @@ -4,6 +4,7 @@ !ENTITY ouml #x000F6; !ENTITY uuml #x000FC; ] +!-- CVS $Id$:-- status developers @@ -45,6 +46,7 @@ person name=Diana Shannon email=[EMAIL PROTECTED] id=DS/ person name=Davanum Srinivas email=[EMAIL PROTECTED] id=DM/ person name=Jeff Turner email=[EMAIL PROTECTED] id=JT/ + person name=Upayavira email=[EMAIL PROTECTED] id=UV/ person name=Sylvain Wallez email=[EMAIL PROTECTED] id=SW/ person name=Carsten Ziegeler email=[EMAIL PROTECTED] id=CZ/ person name=Volunteer needed email=[EMAIL PROTECTED] id=open/ @@ -260,6 +262,9 @@ action dev=BRD type=update fixes-bug=15312 due-to=Unico Hommes due-to-email=[EMAIL PROTECTED] Dispose the parent Component Manager if it implements Disposable. Happens when the Cocoon servlet shuts down or when Cocoon is reloaded. + /action + action dev=UV type=add +Added support for permanent redirects in lt;map:redirect-togt; /action /release release version=2.1m2 date=May 20 2003
cvs commit: cocoon-2.1/src/blocks/portal/samples/skins/common/css - New directory
cziegeler2003/06/25 01:23:07 cocoon-2.1/src/blocks/portal/samples/skins/common/css - New directory
cvs commit: cocoon-2.1/src/blocks/portal/samples/skins/basic/images - New directory
cziegeler2003/06/25 01:23:07 cocoon-2.1/src/blocks/portal/samples/skins/basic/images - New directory
cvs commit: cocoon-2.1/src/blocks/portal/samples/skins/basic/styles - New directory
cziegeler2003/06/25 01:23:07 cocoon-2.1/src/blocks/portal/samples/skins/basic/styles - New directory
cvs commit: cocoon-2.1/src/blocks/portal/samples/skins/basic/css - New directory
cziegeler2003/06/25 01:23:07 cocoon-2.1/src/blocks/portal/samples/skins/basic/css - New directory
cvs commit: cocoon-2.1/src/blocks/portal/samples/skins/basic - New directory
cziegeler2003/06/25 01:23:07 cocoon-2.1/src/blocks/portal/samples/skins/basic - New directory
cvs commit: cocoon-2.1/src/blocks/portal/samples/skins/basic/css page.css
cziegeler2003/06/25 01:23:17
Modified:src/blocks/portal/samples/skins/common/styles tab.xsl
window.xsl
src/blocks/portal/samples sitemap.xmap
Added: src/blocks/portal/samples/skins/common/styles
portal-page.xsl
src/blocks/portal/samples/skins/basic/styles tab.xsl
window.xsl login-html.xsl column.xsl row.xsl
portal-page.xsl
src/blocks/portal/samples/skins/basic/images maximize.gif
delete.gif space.gif minimize.gif show.gif
customize.gif
src/blocks/portal/samples/skins/common/css page.css
src/blocks/portal/samples/skins/basic/css page.css
Removed: src/blocks/portal/samples/skins/common/styles header.xsl
Log:
Adding second skin
Revision ChangesPath
1.4 +21 -14cocoon-2.1/src/blocks/portal/samples/skins/common/styles/tab.xsl
Index: tab.xsl
===
RCS file:
/home/cvs/cocoon-2.1/src/blocks/portal/samples/skins/common/styles/tab.xsl,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- tab.xsl 28 May 2003 07:14:40 - 1.3
+++ tab.xsl 25 Jun 2003 08:23:16 - 1.4
@@ -6,8 +6,11 @@
!-- Process a tab --
xsl:template match=tab-layout
!-- ~ Begin body table ~ --
-table summary=tab bar border=0 cellpadding=0 cellspacing=0 width=100%
+table border=0 cellpadding=0 cellspacing=0 width=100%
!-- ~ Begin tab row ~ --
+ tr
+ td
+ table summary=tab bar border=0 cellpadding=0 cellspacing=0 width=100%
tr vAlign=top
xsl:for-each select=named-item
xsl:choose
@@ -15,7 +18,7 @@
!-- ~ begin selected tab ~ --
!-- ~ begin spacer between tabs ~ --
td width=5 Valign=bottom bgcolor=#294563
- table summary=non selected tab style=height:
1.8em border=0 cellpadding=0 cellspacing=0
+ table summary=spacer style=height: 1.8em
border=0 cellpadding=0 cellspacing=0
tr
td height=99%img height=5
src=space.gif width=5//td
/tr
@@ -25,8 +28,8 @@
/table
/td
!-- ~ end spacer between tabs ~ --
- td width=1
- table summary=selected tab style=height: 2.0em
border=0 cellpadding=0 cellspacing=0
+ td width=1 Valign=bottom bgcolor=#294563
+ table summary=selected tab style=height: 1.8em
border=0 cellpadding=0 cellspacing=0
tr
td valign=top width=5
bgcolor=#FF
img height=5 width=5
alt= src=tabSel-left.gif/
@@ -89,31 +92,35 @@
/xsl:choose
/xsl:for-each
td width=99% bgcolor=#294563
- !-- ~ last blank tab, contains logout button ~ --
+ !-- ~ last blank tab~ --
table style=height: 2.0em border=0 cellpadding=0
cellspacing=0 width=100%
tr
td height=99% bgcolor=#294563 width=99%
align=right valign=center
- a href=logoutimg src=logout-door.gif
width=18 height=22 border=0//aimg height=10 src=sunspotdemoimg-space.gif
width=5/
- /td
- td height=99% bgcolor=#294563 width=1%
align=right valign=center
- a href=logout
style=color:#4C6C8F;font-size:75%;Logout/a
+ img height=10 src=space.gif width=1/
/td
/tr
tr
td height=1 bgcolor=#4C6C8F width=99%
img height=10 src=space.gif width=1/
/td
- td height=1 bgcolor=#4C6C8F width=1%
- img height=10 src=space.gif width=1/
- /td
/tr
/table
/td
/tr
+ /table
+ /td
+ /tr
!-- ~ End tab row ~ --
tr
-td colSpan={count(named-item)*2+1} bgcolor=#FF
- xsl:apply-templates select=named-item/
+td bgcolor=#FF
+ table cellpadding=0 cellspacing=0 width=100%
+
RE: [VOTE] Give all Cocoon committers CVS access?
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Nicola Ken Barozzi Jeff Turner wrote, On 24/06/2003 13.38: As most of you probably saw, there's a thread on cocoon-dev suggesting that Forrest ought to be a Cocoon subproject, with the consensus being it makes sense. AFAICT the only practical difference would be that Cocoon committers would automatically become Forrest committers. Sounds fine to me. Can we vote on these issues then? Vote 1: Cocoon committers automatically become Forrest committers +1 +1 Vote 2: Forrest should become a subproject of Cocoon (http://cocoon.apache.org/forrest) +1 I vote +1 and +/-0. Both make sense, but 2) seems slightly more pain than gain, unless there's some advantage I've overlooked. Well, when this issue first came out, I agreed that Forrest could become different from Cocoon, and eventually use something else. Reality has shown us that we are tied double-rope with Cocoon, and this is being a good thing. Xml and Cocoon PMCs are both very nice to be in, and as for communities we are already cooperating anyways. But now that Lenya is under Cocoon, I tend to think that it changes things. And the more we go forward, the more we will be integrating new parts of the Cocoon Project, assimilating things like Linotype and Lenya, and becoming more and more part of the changes. We are a strong use case of Cocoon and I hope also Lenya and Linotype soon, hence we can be the reality check for all Cocoon projects. The question I ask myself is: community-wise, where do we belong? The answer is very easy: Cocoon. As for the future, were will we belong community-wise? Now I think that it also quite evident: Cocoon. This is the reason why I vote Cocoon. I don't think it will be a major change for us now practically, so it may seem more hassle than gain, but when things will start playing out, it will IMHO become more evident that we belong with the Cocoon community. +1 (Forrest should become a subproject of Cocoon) Reinhard
DO NOT REPLY [Bug 21075] New: - Wrong link to Lenya
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=21075. 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=21075 Wrong link to Lenya Summary: Wrong link to Lenya Product: Cocoon 2 Version: Current CVS 2.1 Platform: Other URL: http://cocoon.apache.org/ OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Lenya on the middle of http://cocoon.apache.org/ is pointing to http://cocoon.apache.org instead of http://cocoon.apache.org/lenya/
RE: FOM, views, and input modules
From: Christopher Oliver [mailto:[EMAIL PROTECTED]
I modified the FOM implementation in the scratchpad to make the FOM
available to the view layer, thinking that the view author
also should
see the FOM (See FOM_JavaScriptFlowHelper.java), rather than the raw
Request, Response, etc. Do others agree with this?
The same is valid for the view layer as explained from you below!
You can still pass parameters to generators or transformers of pipelines
called by the flow layer.
Additionally you can call pipelines that contain actions. Do we want
this?
I'm worried that people start to work around the restrictions of the FOM
...
I also modified the GarbageGenerator to use the FOM.
So because of the FOM you can't do this in a flow script anymore:
cocoon.request.sitemapURI
likewise in a Garbage view template you can no longer do this:
page whatever={$request/sitemapURI}
in both cases because the FOM doesn't expose the sitemapURI
property
of the Request.
However the input modules give full access to the original
Java Request
object, so in the sitemap you can still do this:
map:call function=whatever
map:parameter name=whatever value={request:sitemapURI}/
and pass it as a parameter to your flowscript, bypassing the FOM (!)
This seems inconsistent to me. What do others think?
Yes, you are right! Maybe we should disable input module substituion
within
call elements of the sitemap. (I don't know if this is possible at all.)
What do you think?
Reinhard
Problem generating Cocoon site
Hi, I currently have a problem generating the cocoon site with forrest. I get the following error: --- * [0] - [broken page] index.html - No pipeline matched request: tab.xml Total time: 0 minutes 5 seconds I'm using latest forrest from cvs and I can generate other sites with it without problems. Does anyone have a clue? Carsten
Re: TreeProcessor:BUG
Hi Sylvian, it works now I checked out and build the new cvs and test it. test with: map:pipeline cached and noncached map:pipeline internal-only=true cached and noncached Klaus Klaus Bertram wrote: Klaus Bertram wrote: Sylvain Wallez wrote: Klaus Bertram wrote: Hi Joerg yes I found it by debugging an action where the breakpoint was stoped twice. So I wrote a small test sidemap with an xsp side and database actions By request the map:aggregation match, an action in map:part add a row to the databse and then the xsp read the table entrys. The browser show the insertred row, but the database had 2 new rows The sitemap.log shows the complete match handling twice After that I test the match form the part direkt with a request and it works. (1 row added) When needed I can send you my test sides. Some questions to help us track the problem : - do you use a caching pipeline - if yes, does it still happen if you use a non-caching pipeline ? Yes I had the same idea and checked both, same result Oh, the called map:part match is in different pipeline than the map:aggregation and I checked map:pipeline internal-only=true and map:pipeline but I tryed not the match in the same pipeline I check it in the afternoon checked with same result - can you provide us the two stack trace when you hit the breakpoint ?
cvs commit: cocoon-2.1/src/documentation sitemap.xmap
jefft 2003/06/25 04:56:07
Modified:src/documentation sitemap.xmap
Log:
Update overridden sitemap to work with Forrest 'stable-20030625' tag.
Revision ChangesPath
1.8 +148 -140 cocoon-2.1/src/documentation/sitemap.xmap
Index: sitemap.xmap
===
RCS file: /home/cvs/cocoon-2.1/src/documentation/sitemap.xmap,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- sitemap.xmap 29 May 2003 11:49:32 - 1.7
+++ sitemap.xmap 25 Jun 2003 11:56:07 - 1.8
@@ -18,6 +18,9 @@
/map:transformer
map:transformer name=linkrewriter
logger=sitemap.transformer.linkrewriter
src=org.apache.cocoon.transformation.LinkRewriterTransformer
+link-attrshref src/link-attrs
+schemessite ext/schemes
+
input-module name=site
input-module name=linkmap
file src={src} reloadable=false /
@@ -78,13 +81,8 @@
map:matcher name=regexp src=org.apache.cocoon.matching.RegexpURIMatcher/
/map:matchers
-map:actions
- map:action logger=sitemap.action.resource-exists name=resource-exists
src=org.apache.cocoon.acting.ResourceExistsAction/
-/map:actions
-
-map:selectors default=exists
- map:selector logger=sitemap.selector.exists name=exists
-src=org.apache.cocoon.selection.ResourceExistsSelector /
+map:selectors
+ map:selector logger=sitemap.selector.exists name=exists
src=org.apache.cocoon.selection.ResourceExistsSelector /
/map:selectors
map:pipes default=caching
@@ -115,6 +113,7 @@
map:parameter name=isfaq value={notoc}/
map:parameter name=nopdf value={nopdf}/
map:parameter name=path value={path}/
+map:parameter name=obfuscate-mail-links value=false/
!-- Can set an alternative project skinconfig here
map:parameter name=config-file value=../../../../skinconf.xml/
--
@@ -131,91 +130,60 @@
map:pipeline internal-only=false
!-- --
- !-- OUTPUT FORMATS --
- !-- Serves content directly to the user --
- !-- +==+ --
+ !-- SOURCE FORMATS --
+ !-- Raw XML sources, typically doc-v11 format--
+ !-- --
- !-- COCOON SPECIFIC --
- map:match pattern=**.txt
-!-- Handle .txt files (incorrectly) placed in xdocs. Forrest will
-eventually evolve to handle mixed-content scenarios (JT) --
-map:read src=content/xdocs/{0} mime-type=text/plain/
+ map:match pattern=changes.xml
+map:mount uri-prefix= src=status.xmap check-reload=yes /
/map:match
- !-- /COCOON SPECIFIC --
- map:match type=regexp pattern=^.+$
-map:select type=exists
- map:when test=content/{0}
-map:mount uri-prefix= src=raw.xmap check-reload=yes /
- /map:when
-/map:select
+ map:match pattern=todo.xml
+map:mount uri-prefix= src=status.xmap check-reload=yes /
/map:match
- map:match pattern=*.html
-map:aggregate element=site
- map:part src=cocoon:/tab-{1}.xml/
- map:part src=cocoon:/menu-{1}.xml/
- map:part src=cocoon:/body-{1}.xml/
-/map:aggregate
-map:call resource=skinit
- map:parameter name=type value=site2xhtml/
- map:parameter name=path value={0}/
-/map:call
- /map:match
-
- map:match pattern=**/*.html
-map:aggregate element=site
- map:part src=cocoon:/{1}/tab-{2}.xml/
- map:part src=cocoon:/{1}/menu-{2}.xml/
- map:part src=cocoon:/{1}/body-{2}.xml/
-/map:aggregate
-map:call resource=skinit
- map:parameter name=type value=site2xhtml/
- map:parameter name=path value={0}/
-/map:call
+ map:match pattern=**dtdx.xml
+map:mount uri-prefix= src=dtd.xmap check-reload=yes /
/map:match
+ map:match pattern=**linkmap*
+map:mount uri-prefix= src=linkmap.xmap check-reload=yes /
+ /map:match
- !-- Special matcher for FAQ PDFs, so we can pass an extra
- 'numbersections' param into document2fo.xsl --
- map:match pattern=**faq.pdf
-map:generate src=cocoon:/{1}faq.xml/
-map:transform src=skins/{forrest:skin}/xslt/fo/document2fo.xsl
- map:parameter name=numbersections value=false/
- map:parameter name=ctxbasedir value={realpath
Re: Problem generating Cocoon site
Carsten Ziegeler wrote, On 25/06/2003 12.26: I get the following error: --- * [0] - [broken page] index.html - No pipeline matched request: tab.xml Do you have tab.xml? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Problem generating Cocoon site
Nicola Ken Barozzi wrote: Carsten Ziegeler wrote, On 25/06/2003 12.26: I get the following error: --- * [0] - [broken page] index.html - No pipeline matched request: tab.xml btw, I am having the same problem when generating the Lenya site using Forrest from CVS. (We currently do it with an older Forrest version) Do you have tab.xml? no, so I guess I need to create it ;-) any pointer where I can copy and modify one? Thanks Michael
Re: Problem generating Cocoon site
On Wed, Jun 25, 2003 at 12:26:21PM +0200, Carsten Ziegeler wrote: Hi, I currently have a problem generating the cocoon site with forrest. I get the following error: --- * [0] - [broken page] index.html - No pipeline matched request: tab.xml Total time: 0 minutes 5 seconds I'm using latest forrest from cvs and I can generate other sites with it without problems. Does anyone have a clue? Cocoon overrides the main Forrest sitemap (src/documentation/sitemap.xmap), which means that every time the Forrest CVS sitemaps change, the Cocoon one would need synching. To avoid this, there is a 'stable' tag on Forrest, the theory being that Cocoon docs should always build with the 'stable' Forrest. Anyway, I've just synched Cocoon's overridden sitemap with that from Forrest CVS, and updated the Forrest 'stable' tag. After doing a 'cvs up -r stable' on Forrest and rebuilding it, running 'build forrest' in Cocoon should now work (without munged mailto: links). --Jeff Carsten
RE: Problem generating Cocoon site
Jeff Turner wrote: Cocoon overrides the main Forrest sitemap (src/documentation/sitemap.xmap), which means that every time the Forrest CVS sitemaps change, the Cocoon one would need synching. To avoid this, there is a 'stable' tag on Forrest, the theory being that Cocoon docs should always build with the 'stable' Forrest. Ah, thanks for the info. Anyway, I've just synched Cocoon's overridden sitemap with that from Forrest CVS, and updated the Forrest 'stable' tag. After doing a 'cvs up -r stable' on Forrest and rebuilding it, running 'build forrest' in Cocoon should now work (without munged mailto: links). Yes, it works without munged mailto: links and without the xml.apache.org logo! Great! Thanks! Carsten
cvs commit: cocoon-2.1/src/documentation/xdocs/developing/portal - New directory
cziegeler2003/06/25 05:59:53 cocoon-2.1/src/documentation/xdocs/developing/portal - New directory
cvs commit: cocoon-2.1/src/blocks/linkrewriter/samples/bookdemo/docs book.xml
cziegeler2003/06/25 06:00:01 Modified:src/documentation/xdocs index.xml src/documentation/xdocs/developing book.xml src/blocks/linkrewriter/samples/bookdemo/docs book.xml Added: src/documentation/xdocs/developing/portal book.xml index.xml Log: Adding some docs to the new portal framework Revision ChangesPath 1.4 +1 -1 cocoon-2.1/src/documentation/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/index.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- index.xml 29 Apr 2003 22:58:21 - 1.3 +++ index.xml 25 Jun 2003 13:00:00 - 1.4 @@ -42,7 +42,7 @@ /s1 s1 title=More News about Cocoon p -Check out our link href=news.htmlnews page/link for more up-to-date news about Cocoon. +Check out our link href=http://cocoon.apache.org/news/;news page/link for more up-to-date news about Cocoon. /p /s1 figure src=images/cocoon-built.gif alt=Built with Apache Cocoon/ 1.1 cocoon-2.1/src/documentation/xdocs/developing/portal/book.xml Index: book.xml === ?xml version=1.0? !DOCTYPE book PUBLIC -//APACHE//DTD Cocoon Documentation Book V1.0//EN ../../dtd/book-cocoon-v10.dtd book software=Apache Cocoon title=Apache Cocoon Webapps Developer Documentation copyright=@year@ The Apache Software Foundation menu label=Navigation menu-item label=Main href=../../index.html/ menu-item label=Dev Guide href=../index.html/ /menu menu label=Portal menu-item label=Introduction href=index.html/ menu-item label=Authentication href=../webapps/authentication.html/ /menu /book 1.1 cocoon-2.1/src/documentation/xdocs/developing/portal/index.xml Index: index.xml === ?xml version=1.0? document header titleConfiguring the Cocoon Portal/title authorsperson email=[EMAIL PROTECTED] name=Joel Greenyer/person /authors noticeThis document is under development./notice abstract This document describes the use and configuration of the cocoon portal /abstract /header body section titleIntroducing the Cocoon Portal/title section titleImportant parts of the Cocoon Portal/title /section section titleHow is a portal page created by Cocoon?/title /section section titleI want to build my own portal! An approach/title /section /section section titleConfiguring the Portal contents/title section titleConfiguring Coplets/title /section section titleConfiguring the arrangement of the defined Coplets/title /section section title.../title /section /section section titleCreate a new skin for your portal/title pThis section will explain the concepts of the portal layout, considering the codeskins/basic//code skin provided with cocoon, and will describe how to create a new skin by extending the existing stylesheets./p noteThe skin path can be changed in the portal's sitemap. There is a codeglobal-variable/code specifying the path to the skin folder./note pThe basic cocoon portal skin is a nice and simple example how to visualize a portal. There are several elements that allow to customize the look and feel of the portal. A portal with the basic skin consists of ul lia emheader/em/li lia emtab row/em/li lia emcontent section/em containing the coplet windows/li liand a emfooter /em/li /ul /p figure alt=Parts of the portal height=300 src=/images/portal-parts.gif width=400/figure pThe tab row is actually a part of the content section. As well, a tab row can be provided to any coplet window./p section titleThe skinapos;s stylesheets/title pIf we take a look at the codeskins/basic/styles/code directory, we find a number of stylesheets: ul
FlowScript Question
Hi All, Does anyone know how to write a call from FlowScript to a Java Method, when the method name is the same as a keyword in JavaScript? I am trying to invoke the following Java Method from JavaScript and it refuses to interpret: var sess = Packages.org.iniva.Persistance.getSession(); sess.delete(coverage); error line The interpreter complains: SyntaxError: missing name after . operator I assume it is the presence of the 'delete' keyword. Is there any way to 'trick' the JavaScript interpreter to call this? thanks for any help regards Jeremy
cvs commit: cocoon-site/src/documentation/content/xdocs index.xml
cziegeler2003/06/25 06:09:12 Modified:src/documentation/content/xdocs index.xml Log: Correcting link to lenya Revision ChangesPath 1.5 +1 -1 cocoon-site/src/documentation/content/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/cocoon-site/src/documentation/content/xdocs/index.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- index.xml 27 May 2003 20:20:00 - 1.4 +++ index.xml 25 Jun 2003 13:09:11 - 1.5 @@ -23,7 +23,7 @@ lilink href=http://cocoon.apache.org/2.1/;Apache Cocoon/link itself,/li - lilinkLenya/link, an incubating website content management + lilink href=http://cocoon.apache.org/lenya/;Lenya/link, an incubating website content management framework based on Cocoon./li !--
cvs commit: cocoon-2.1/src/documentation/xdocs/developing/portal index.xml
cziegeler2003/06/25 06:10:15 Modified:src/documentation/xdocs/developing/portal index.xml Log: Updating docs Revision ChangesPath 1.2 +8 -4 cocoon-2.1/src/documentation/xdocs/developing/portal/index.xml Index: index.xml === RCS file: /home/cvs/cocoon-2.1/src/documentation/xdocs/developing/portal/index.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- index.xml 25 Jun 2003 13:00:00 - 1.1 +++ index.xml 25 Jun 2003 13:10:15 - 1.2 @@ -7,13 +7,19 @@ noticeThis document is under development./notice abstract This document describes the use and configuration - of the cocoon portal + of the (new) cocoon portal block. /abstract /header body section titleIntroducing the Cocoon Portal/title +p + This document describes the use and configuration + of the (new) cocoon portal that you can find in the portal block. + (Don't mix this with the older portal version that you can + find in the portal-fw block.) +/p section titleImportant parts of the Cocoon Portal/title /section @@ -387,13 +393,11 @@ /xsl:if /td /tr - xsl:if test=status!=0 tr td colSpan=2 xsl:apply-templates select=content/ /td /tr - /xsl:if /table /xsl:template ...]]/source @@ -401,7 +405,7 @@ /section section - titleFurter topics/title + titleFurther topics/title /section /body
Re: looking at linotype
On Monday, June 23, 2003, at 03:13 PM, Ricardo Rocha wrote: Jeremy Quinn wrote: Since the login() method calls 'cocoon.createSession()', should the 'logout()' method not invalidate the Session? Is there a method available in the FOM to do that? I could not work out what I guess cocoon.session.invalidate() should do the trick? got it! thanks Jeremy
Re: FlowScript Question
See http://marc.theaimsgroup.com/?l=xml-cocoon-devm=104498961922321w=2 - thanks Christopher ;-) Reinhard Hi All, Does anyone know how to write a call from FlowScript to a Java Method, when the method name is the same as a keyword in JavaScript? I am trying to invoke the following Java Method from JavaScript and it refuses to interpret: var sess = Packages.org.iniva.Persistance.getSession(); sess.delete(coverage); error line The interpreter complains: SyntaxError: missing name after . operator I assume it is the presence of the 'delete' keyword. Is there any way to 'trick' the JavaScript interpreter to call this? thanks for any help regards Jeremy -- +++ GMX - Mail, Messaging more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
cvs commit: cocoon-2.1/src/documentation/xdocs/developing/portal index.xml
cziegeler2003/06/25 06:33:25 Modified:src/targets docs-build.xml src/documentation/xdocs/developing/portal index.xml Added: src/documentation/xdocs/dtd document-v11.dtd document-v12.mod ISOnum.pen ISOtech.pen ISOlat1.pen ISOpub.pen document-v12.dtd common-charents-v10.mod ISOgrk1.pen ISOdia.pen document-v11.mod Log: Adding document-11 dtds Fixing document Making docs build target use forrest Comment out printer-docs target (Do we still need this?) Revision ChangesPath 1.1 cocoon-2.1/src/documentation/xdocs/dtd/document-v11.dtd Index: document-v11.dtd === !-- === Apache Documentation DTD (Version 1.1) PURPOSE: This DTD was developed to create a simple yet powerful document type for software documentation for use with the Apache projects. It is an XML-compliant DTD and it's maintained by the Apache XML project. It has now been superceded by v1.2. TYPICAL INVOCATION: !DOCTYPE document PUBLIC -//APACHE//DTD Documentation V1.1//EN document-v11.dtd where x := major version y := minor version NOTES: Many of the design patterns used in this DTD were take from the W3C XML Specification DTD edited by Eve Maler [EMAIL PROTECTED]. Where possible, great care has been used to reuse HTML tag names to reduce learning efforts and to allow HTML editors to be used for complex authorings like tables and lists. EXTENSIBILITY: This DTD includes several empty placeholders that can be used to extend it. These placeholders are implemented with empty entities. Here is the list of those empty entities and what they are used for: - local.inline: this entity should contain extended definitions of elements that can be used 'inline', or directly inside the content. An example for this entity could be !ENTITY % local.inline |citation - local.blocks: this entity should contain extended definitions of elements that behave as 'blocks', thus can be visually rendered as areas on the canvas. An example for this entity could be: !ENTITY % local.blocks |poem - local.sections: this entity should contain extended definitions of elements that behave as 'sections', thus can be considered containers of block-level elements. An example for this entity could be: !ENTITY % local.sections |chapter - local.headers: this entity should contain extended definitions of elements that behave as parts of the document header. An example for this header could be: !ENTITY % local.headers , notes? - local.footers: this entity should contain extended definitions of elements that behave as parts of the document footer. An example for this header could be: !ENTITY % local.footers , annotations* AUTHORS: Stefano Mazzocchi [EMAIL PROTECTED] Steven Noels [EMAIL PROTECTED] FIXME: - should form tags be included? CHANGE HISTORY: [Version 1.0] 19991121 Initial version. (SM) 19991123 Replaced res with more standard strong for emphasis. (SM) 19991124 Added fork element for window forking behavior. (SM) 19991124 Added img-inline element to separate from img. (SM) 19991129 Removed affiliation from author. (SM) 19991129 Made author empty and moved name|email as attributes. (SM) 19991215 Simplified table section. (SM) 19991215 Changed img-block in more friendly figure. (SM) 2125 Added the icon image. (SM) 2126 Allowed anchor in all levels. (SM) 2404 Removed the role attribute from common-xxx.att. (SM) 2815 Allowed code inside strong and em. (SM) [Version 1.1] 20011212 Used public identifiers for external entities. (SM) 20011212 Removed xlink attributes since not used. (SM) 20011212 Removed connect since not required at this level. (SM) 20011218 Added warning as a block level object. (SM) 20011218 Removed explicitly numbered sections (s1|s2|s3|s4). (SM) 20011218 Added section element. (SM) 20011218 Allowed body to have blocks without a section. (SM) 20011218 Removed sl since not really different from ul. (SM) 20020214 Moved empty placeholder entity declarations up front (SNS) 20020214 Corrected content model of content.mix parameter entity (SNS) 20020519 The DTDs are now modular so
cvs commit: cocoon-site/src/documentation/content/xdocs whoweare.xml history.xml
crossley2003/06/25 06:59:41 Modified:src/documentation/content/xdocs whoweare.xml history.xml Log: Add missing newlines at EOF. Revision ChangesPath 1.3 +1 -1 cocoon-site/src/documentation/content/xdocs/whoweare.xml Index: whoweare.xml === RCS file: /home/cvs/cocoon-site/src/documentation/content/xdocs/whoweare.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- whoweare.xml 27 May 2003 20:20:00 - 1.2 +++ whoweare.xml 25 Jun 2003 13:59:41 - 1.3 @@ -82,4 +82,4 @@ pThe Cocoon PMC can be contacted at codepmc#60;at#62;cocoon.apache.org/code and is currently chaired by Steven Noels./p /body -/document \ No newline at end of file +/document 1.2 +1 -1 cocoon-site/src/documentation/content/xdocs/history.xml Index: history.xml === RCS file: /home/cvs/cocoon-site/src/documentation/content/xdocs/history.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- history.xml 17 May 2003 09:27:40 - 1.1 +++ history.xml 25 Jun 2003 13:59:41 - 1.2 @@ -9,4 +9,4 @@ body pFor nostalgia#39;s sake, a short overview of Cocoon#39;s history./p /body -/document \ No newline at end of file +/document
cvs commit: cocoon-site/src/documentation/content/xdocs incubation.xml index.xml
crossley2003/06/25 07:06:06 Modified:src/documentation/content/xdocs index.xml Added: src/documentation/content/xdocs incubation.xml Log: Added new doc to help explain incubation. Content gleaned from cocoon-dev: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105641055101484 Revision ChangesPath 1.6 +5 -8 cocoon-site/src/documentation/content/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/cocoon-site/src/documentation/content/xdocs/index.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- index.xml 25 Jun 2003 13:09:11 - 1.5 +++ index.xml 25 Jun 2003 14:06:06 - 1.6 @@ -21,14 +21,11 @@ ul lilink href=http://cocoon.apache.org/2.1/;Apache Cocoon/link - itself,/li + itself./li - lilink href=http://cocoon.apache.org/lenya/;Lenya/link, an incubating website content management - framework based on Cocoon./li - - !-- -liLinotype, a web logging toolkit/li - -- + lilink href=http://cocoon.apache.org/lenya/;Lenya/link, an + link href=incubation.htmlincubating/link + website content management framework based on Cocoon./li /ul /body -/document \ No newline at end of file +/document 1.1 cocoon-site/src/documentation/content/xdocs/incubation.xml Index: incubation.xml === ?xml version=1.0 encoding=UTF-8? !DOCTYPE document PUBLIC -//APACHE//DTD Documentation V1.2//EN document-v12.dtd document header titleThe meaning of Cocoon sub-project incubation/title /header body p After years of software development and hundreds of developers coming in and out, a concept crystallized around the ASF and it basically says: /p p strongA development community is more important than the software that it develops/strong /p p The reason for this is simple: Software does not evolve by itself. Since software lives in an environment which is continously changing, then software that is perfect for the job today, might not be so in the future. /p p The existence of a healthy development community around code guarantees that software evolution will evolve to fit the environmental constraints. /p p What does make a community healthy? /p p Again, after years of successes and failures, there is general consensus that a development community is healthy if: /p p 1) it exhibits diversity /p p 2) it presents an open attitude toward confrontation, changes, and new committers /p p Note that the above rules do *NOT* take into consideration technological concepts: the ASF is *very* open to technological differences, so much so, in fact, that technical considerations are left to the users or to the markets, but are not filtered out by the Foundation itself. /p p The ASF cares *exclusively* about the quality of the communities and the reason is mainly because a healthy community brings back more energy to the foundation than it consumes (positive engine!), while a non-healthy community is very likely to drain more energy from the foundation than it is able to donate back. /p p The ASF can sustain its growth only if new efforts bring more energy into the system than they use, thus contributing positively to the entire energetic equation. /p p However building a community takes time and effort, expecially if it was never done before. /p p For this reason, the ASF created the concept of incubation to allow healthy communities to be bootstrapped. /p p A project under incubation is basically a project that is not yet considered healthy enough to be able to give back to the Foundation more energy that it consumes. /p p Many times incubation is done because lack of diversity. For example, if one entity (company, group or individual) donates software to the Foundation, but only people belonging to that entity work on it. /p p Diversity is important because it creates long-term stability. It has happened in the past that, for example, a company goes bankrupt and all the people who worked on the project are gone, leaving the project with no development community. This is unacceptable because a project without a working community drains an incredible amount of human resources and energy from the foundation to fix things and normally much more than the
Re: Syncing rhino
David Crossley wrote: Gianugo Rabellino wrote: snip/ ...Anyway, given that you are the only one showing some interest, I'm starting to think that I'm just being paranoid... No, you are definitely not. All the issues that you and Christopher are attending to are extremely important. I, for one, do not think that i can help much, but i am avidly following this thread. +1 I'm following this thread with high interest too. High respect to those who brought the flow where it is today, it would be sad to leave it there. The only real solution I see is to integrate continuations into the Rhino CVS, even if it initially means some high ammount of work. Unfortunately my knowledge is not (yet) reaching to be able to contribute, but perhaps in the future ... Please keep up that good! Bye, Andreas --David
DTDs for document-v11
[EMAIL PROTECTED] wrote: cziegeler2003/06/25 06:33:25 Modified:src/targets docs-build.xml src/documentation/xdocs/developing/portal index.xml Added: src/documentation/xdocs/dtd document-v11.dtd document-v12.mod ISOnum.pen ISOtech.pen ISOlat1.pen ISOpub.pen document-v12.dtd common-charents-v10.mod ISOgrk1.pen ISOdia.pen document-v11.mod Log: Adding document-11 dtds Fixing document Making docs build target use forrest Comment out printer-docs target (Do we still need this?) Why do we need DTDs to be included here? If they need to be in Cocoon CVS, then shouldn't they be in WEB-INF/entities. --David
Re: doc to explain incubation of sub-projects
Stefano Mazzocchi wrote: David Crossley wrote: I think that we need a document that clearly explains what it means to be a Cocoon sub-project under incubation. This would go at the top-level of the cocoon website and help to explain the mysterious statements on the Cocoon and Lenya home pages. All right, since I feel in write-mood these days, I'll try to come up with something. snip/ Feel free to edit/add/change at will. Wikifiers/docifiers are always welcome ;-) That is a good start. I put everything that you had into a top-level xdoc called incubation.xml We need to add a section that says how/when a sub-project is deemed ready to leave incubation. --David
RE: DTDs for document-v11
David Crossley wrote: Why do we need DTDs to be included here? If they need to be in Cocoon CVS, then shouldn't they be in WEB-INF/entities. The validate-xdocs task validates all our documents and uses the DTDs from the documentation directory. As the old document-10 dtd was already there, I thought it would be the natural place to put the newer dtd. Now, I guess if we are using forrest for document generation we could completly remove the DTDs and the validation task as well as forrest will do that for us. Carsten
RE: DTDs for document-v11
Carsten Ziegeler wrote: David Crossley wrote: Why do we need DTDs to be included here? If they need to be in Cocoon CVS, then shouldn't they be in WEB-INF/entities. The validate-xdocs task validates all our documents and uses the DTDs from the documentation directory. As the old document-10 dtd was already there, I thought it would be the natural place to put the newer dtd. Since we use the entity resolver, the main location for DTDs is over at WEB-INF/entities and they need to be added to the catalog. The set of DTDs at xdocs/dtd/ is a relic from before we had the entity resolver. We should actually nuke the latter set ... too many copies of them. Yes i now see the problem with 'validate-xdocs'. Now, I guess if we are using forrest for document generation we could completly remove the DTDs and the validation task as well as forrest will do that for us. We are in a bind there. Even if we do use Forrest for the command-line docs building, then we still have the documentation in the webapp which does not use Forrest. I am not sure what the answer is here. --David
cvs commit: cocoon-site/src/documentation/content/xdocs/news index.xml
stevenn 2003/06/25 07:54:36 Modified:src/documentation/content/xdocs history.xml index.xml src/documentation/content/xdocs/news index.xml Log: some rephrasings which were stuck in my sandbox Revision ChangesPath 1.3 +2 -1 cocoon-site/src/documentation/content/xdocs/history.xml Index: history.xml === RCS file: /home/cvs/cocoon-site/src/documentation/content/xdocs/history.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- history.xml 25 Jun 2003 13:59:41 - 1.2 +++ history.xml 25 Jun 2003 14:54:36 - 1.3 @@ -7,6 +7,7 @@ /header body -pFor nostalgia#39;s sake, a short overview of Cocoon#39;s history./p +pFor nostalgia#39;s sake, a short overview of Cocoon#39;s history +might appear here./p /body /document 1.7 +3 -4 cocoon-site/src/documentation/content/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/cocoon-site/src/documentation/content/xdocs/index.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- index.xml 25 Jun 2003 14:06:06 - 1.6 +++ index.xml 25 Jun 2003 14:54:36 - 1.7 @@ -12,10 +12,9 @@ related technologies to a new level. Apache Cocoon, its main project, has been designed for performance and scalability around pipelined SAX processing. Cocoon offers a flexible environment based on a separation of -concerns between content, logic, and style. To top this all off, -Cocoon#39;s centralized configuration system and sophisticated caching -help you to create, deploy, and maintain rock-solid XML server -applications./p +concerns between content, logic, and style. Cocoon#39;s centralized +configuration system and sophisticated caching help you to create, deploy, +and maintain rock-solid XML server applications./p pThe Apache Cocoon project currently consists of:/p 1.3 +1 -1 cocoon-site/src/documentation/content/xdocs/news/index.xml Index: index.xml === RCS file: /home/cvs/cocoon-site/src/documentation/content/xdocs/news/index.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- index.xml 24 Jun 2003 11:09:34 - 1.2 +++ index.xml 25 Jun 2003 14:54:36 - 1.3 @@ -8,7 +8,7 @@ body section - titleMay 2003/title + titleJune 2003/title ul liNew Cocoon website to celebrate start of 2.1 Milestone releases./li
RE: Cocoon resource publishing
I think the alternative constructor would do it definitely. Although I would miss all the functionality that CocoonBean provides for creating and initializing Cocoon. uv So what functionality are you referring to here? Surely you don't want to go configuring the Cocoon instance if it has already been configured elsewhere (by its containing servlet). /uv uh No, but I could use it wherever I do create and configure it. Be that in a servlet or in an Avalon embedded component. Although it wouldn't be a problem to do that without the help of a utility class and I am doing exactly that right now, my suggestion was that it might be useful. /uh Okay. But why do you want to create a Cocoon object as independent from the Cocoon bean? Why can't the bean create and configure it for you? 1) because CocoonBean is single threaded and I need to run concurrent requests. 2) because I want to share the same Cocoon instance for performance. uv Are you suggesting that we might want the bean to be able to generate a page from a webapp that isn't being served by the servlet? /uv uh I'm saying that I see two separate areas of concern that CocoonBean could be useful for me. One is to help create and configure Cocoon, the other is to help run Cocoon and gather information about these runs. The former would be useful for me in a thread safe type component where I create and manage a shared cocoon instance, the latter I'd like to use in the per-thread situation of a publication request. /uh I'm afraid I don't quite understand. Can you explain more? I don't quite understand what you mean by these two scenarios. You want the bean to create and configure cocoon (which I presume it already does). By the latter, are you referring to stuff like following links? Yes. The code in CocoonBean can be seperated into two categories. One is for creating and configuring the Cocoon instance it is going to use, the other is using it. Cocoon is thread-safe. CocoonBean is not. uv So, what do you mean by 'shared between clients'? /uv uh I mean that the same Cocoon instance be accessible from different locations in the system. One client of this Cocoon service would the HttpServlet that handles regular http calls. Another a mail system that publishes pages over smtp, and yet another that receives commands to push pages onto a remote server as part of a publication action. Why do you want to share the same Cocoon instance? Is it a performance thing? Yes. Actually that was what I started out from, because the publication system I have now follows this exact approach. It accesses the same Cocoon instance that is used to handle http requests as well. Since it is separated from the http servlet I needed to put the Cocoon instance somewhere from where I could access it from both locations. So are you saying that you create a CocoonBean around the Cocoon instance created by the HTTP Servlet and hand that bean over to other systems for them to use in rendering URIs? No I have an Avalon component that creates and manages Cocoon. The http servlet and publishing service get it from a ServiceManager they receive. I don't use CocoonBean now. But it isn't necessarily required for me to keep these two clients separated. It's just the way it works for me now, and divorcing Cocoon management from the code using it, is something that would be generally useful I think. /uh That is the primary purpose of the bean. Except that it's not useable in a multi-threaded environment unless you create one CocoonBean per thread. The basic requirement that I have is that of a webservice that pushes files onto a target location such as a remote FTP server. I consider two different approaches. One is to integrate the service with Cocoon as it now runs as a servlet or come up with an implementation that is separate from it. This is exactly what I have in mind for the bean/cli. I made the bean write to ModifiableSources so that it can write directly to such things as remove FTP servers. So I would create a PublishingGenerator or PublishingTransformer that takes in a configuration (like the current cli.xconf) which tells the publisher what to do. The first generation of my publisher was actually triggered by a Cocoon Action. Sitemap parameters controlled the way the publisher was run. We experienced problems with it because it ate memory thus crashing our system when publication requests came in concurrently. Apart from that configuration was becoming a drag for our sitemap editors and clogged up the sitemaps with unreadable action logic. The problem with running the publisher from sitemap components is that there is no access to Cocoon object from there (would be rather awkward design too). So requests can't be run locally. That then gets hold of a Bean and
Re: doc to explain incubation of sub-projects
On 25/06/2003 16:16 David Crossley wrote: We need to add a section that says how/when a sub-project is deemed ready to leave incubation. Gee. That sounds as untangible as the criteria upon which proposals are judged before they can actually go into incubation. Can't we just say that projects leave incubation if they feel ready to defend their exit intentions when needed? That's the way Tapestry has been following, with Andy C. Oliver as their 'exit sponsor'. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
RE: Cocoon resource publishing
Unico, Okay. But why do you want to create a Cocoon object as independent from the Cocoon bean? Why can't the bean create and configure it for you? 1) because CocoonBean is single threaded and I need to run concurrent requests. Fair enough. 2) because I want to share the same Cocoon instance for performance. Fair enough. uh I'm saying that I see two separate areas of concern that CocoonBean could be useful for me. One is to help create and configure Cocoon, the other is to help run Cocoon and gather information about these runs. The former would be useful for me in a thread safe type component where I create and manage a shared cocoon instance, the latter I'd like to use in the per-thread situation of a publication request. /uh I'm afraid I don't quite understand. Can you explain more? I don't quite understand what you mean by these two scenarios. You want the bean to create and configure cocoon (which I presume it already does). By the latter, are you referring to stuff like following links? Yes. The code in CocoonBean can be seperated into two categories. One is for creating and configuring the Cocoon instance it is going to use, the other is using it. Cocoon is thread-safe. CocoonBean is not. Sounds reasonable. The code in the bean is not that well organised. It is written in Java, but it is pretty procedural. It could do with being broken down into clearer parts. That is probably the most obvious first split. So are you saying that you create a CocoonBean around the Cocoon instance created by the HTTP Servlet and hand that bean over to other systems for them to use in rendering URIs? No I have an Avalon component that creates and manages Cocoon. The http servlet and publishing service get it from a ServiceManager they receive. I don't use CocoonBean now. Sorry, I meant 'is that how you would do it' rather than 'is that how you do it now'. So you would create another cocoon instance and have the bean handle and share that, rather than sharing the servlet's cocoon instance? But it isn't necessarily required for me to keep these two clients separated. It's just the way it works for me now, and divorcing Cocoon management from the code using it, is something that would be generally useful I think. /uh That is the primary purpose of the bean. Except that it's not useable in a multi-threaded environment unless you create one CocoonBean per thread. Yes. But the bean is at a very early stage of its development. That is what it is intended for, but not necessarily what it is ready for. Your proposals and help could make it so. This is exactly what I have in mind for the bean/cli. I made the bean write to ModifiableSources so that it can write directly to such things as remove FTP servers. So I would create a PublishingGenerator or PublishingTransformer that takes in a configuration (like the current cli.xconf) which tells the publisher what to do. The first generation of my publisher was actually triggered by a Cocoon Action. Sitemap parameters controlled the way the publisher was run. We experienced problems with it because it ate memory thus crashing our system when publication requests came in concurrently. Apart from that configuration was becoming a drag for our sitemap editors and clogged up the sitemaps with unreadable action logic. I think the best place for the configuration is as an input to a sitemap component, either as incoming SAX events, or as a src attribute: map:generate type=publish src=publish.xconf/ The problem with running the publisher from sitemap components is that there is no access to Cocoon object from there (would be rather awkward design too). So requests can't be run locally. Ah. So how about we find a way for CocoonBean instances to share an instance of Cocoon? We can have an additional Cocon instance alongside that of the HTTPservlet. Otherwise we work out a way to get hold of the Cocoon instance of the servlet. So if you get it so that the Cocoon HTTP servlet can call the bean, you get delivery to multiple destinations via multiple protocols pretty much for free. If you need to create modifiableSources for your protocols, you can then also give those sources to the whole Avalon and Cocoon communities. :) As it happens I commited a patch for an FTPSource to Avalon a few days ago that was applied yesterday. Wow. What a treat! Looks great. That is going to make my life so much easier in the future. To my mind, the browser response in such a situation is a report saying whether or not the generation of pages was successful. That's an option. However, some publications can take a long time when it also involves crawling and the sites are large and/or slow. Also, publication processing like this is very resource intensive. For this reason we had to process the requests asynchronously, queueing them
cvs commit: cocoon-2.1/src/documentation/xdocs/developing/portal index.xml
cziegeler2003/06/25 12:47:38
Modified:src/targets docs-build.xml validate-build.xml
src/webapp/WEB-INF/entities catalog
src/documentation/xdocs/developing/portal index.xml
Added: src/webapp/WEB-INF/entities common-charents-v10.mod
document-v11.mod document-v11.dtd document-v12.mod
document-v12.dtd
Removed: src/documentation/xdocs/dtd document-v12.mod
specification-v10.dtd book-cocoon-v10.dtd README
ISOtech.pen ISOlat1.pen XMLSchema.dtd
document-v12.dtd datatypes.dtd faq-v10.dtd
document-v11.dtd ISOnum.pen javadoc-v04draft.dtd
svg10.dtd ISOpub.pen document-v10.dtd
changes-v10.dtd characters.ent ISOgrk1.pen
ISOdia.pen todo-v10.dtd common-charents-v10.mod
svg-cocoon-v11.dtd document-v11.mod
Log:
Removing duplicate DTDs - the solution now is a little bit cleaner, but not the
optimum.
Unfortunately, the xmlcatalog task can't be used as for example Jing does not use it,
but the xml parser (reader) for jing still wants to look at the dtd.
Revision ChangesPath
1.15 +6 -0 cocoon-2.1/src/targets/docs-build.xml
Index: docs-build.xml
===
RCS file: /home/cvs/cocoon-2.1/src/targets/docs-build.xml,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- docs-build.xml25 Jun 2003 13:33:24 - 1.14
+++ docs-build.xml25 Jun 2003 19:47:38 - 1.15
@@ -47,6 +47,12 @@
fileset dir=${webapp}/WEB-INF/classes/
/copy
copy todir=${build.context} filtering=on
file=${webapp}/WEB-INF/logkit.xconf/
+
+!-- copy dtds for validation --
+mkdir dir=${build.context}/xdocs/dtd/
+copy todir=${build.context}/xdocs/dtd filtering=on
+ fileset dir=${webapp}/WEB-INF/entities/
+/copy
/target
!-- Set a variable if the generated docs are already up-to-date. --
1.9 +1 -1 cocoon-2.1/src/targets/validate-build.xml
Index: validate-build.xml
===
RCS file: /home/cvs/cocoon-2.1/src/targets/validate-build.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- validate-build.xml6 Apr 2003 04:13:22 - 1.8
+++ validate-build.xml25 Jun 2003 19:47:38 - 1.9
@@ -76,7 +76,7 @@
xmlvalidate failonerror=true lenient=no warn=yes
!-- FIXME: we can use xmlcatalog with Ant-1.6 --
fileset dir=${build.context}/xdocs includes=**/*.xml
-
excludes=status.xml,drafts/*.xml,dictionary.xml,catalog-test.xml,ctwig/sample/**/*.xml,tabs.xml/
+
excludes=status.xml,drafts/*.xml,dictionary.xml,catalog-test.xml,ctwig/sample/**/*.xml,tabs.xml,dtd/**/
/xmlvalidate
echo message=Validating the documentation sitemap.xmap using RELAX NG .../
1.3 +4 -0 cocoon-2.1/src/webapp/WEB-INF/entities/catalog
Index: catalog
===
RCS file: /home/cvs/cocoon-2.1/src/webapp/WEB-INF/entities/catalog,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- catalog 15 May 2003 14:02:26 - 1.2
+++ catalog 25 Jun 2003 19:47:38 - 1.3
@@ -22,6 +22,10 @@
-- Document Type Definitions --
PUBLIC -//APACHE//DTD Documentation V1.0//EN
document-v10.dtd
+PUBLIC -//APACHE//DTD Documentation V1.1//EN
+ document-v11.dtd
+PUBLIC -//APACHE//DTD Documentation V1.2//EN
+ document-v12.dtd
PUBLIC -//APACHE//DTD Changes V1.0//EN
changes-v10.dtd
PUBLIC -//APACHE//DTD FAQ V1.0//EN
1.1 cocoon-2.1/src/webapp/WEB-INF/entities/common-charents-v10.mod
Index: common-charents-v10.mod
===
!-- ===
Apache Common Character Entity Sets (Version 1.0)
PURPOSE:
Common elements across all DTDs.
TYPICAL INVOCATION:
!ENTITY % common-charents PUBLIC
-//APACHE//ENTITIES Common Character Entity Sets Vx.y//EN
common-charents-vxy.mod
%common-charents;
where
x := major version
y := minor version
AUTHORS:
David Crossley [EMAIL PROTECTED]
FIXME:
CHANGE HISTORY:
[Version 1.0]
20020613 Initial version. (DC)
COPYRIGHT:
Copyright (c) 2002 The Apache Software Foundation.
Permission to copy in any form is granted provided this notice is
included in all copies. Permission to redistribute is granted
provided this file is distributed untouched in
Re: cvs commit: cocoon-2.1/src/documentation sitemap.xmap
Does this make the locally built docs use the new look as the website
does?
Geoff
At 07:56 AM 6/25/2003, you wrote:
jefft 2003/06/25 04:56:07
Modified:src/documentation sitemap.xmap
Log:
Update overridden sitemap to work with Forrest 'stable-20030625' tag.
Revision ChangesPath
1.8 +148 -140 cocoon-2.1/src/documentation/sitemap.xmap
Index: sitemap.xmap
===
RCS file: /home/cvs/cocoon-2.1/src/documentation/sitemap.xmap,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- sitemap.xmap 29 May 2003 11:49:32 - 1.7
+++ sitemap.xmap 25 Jun 2003 11:56:07 - 1.8
@@ -18,6 +18,9 @@
/map:transformer
map:transformer name=linkrewriter
logger=sitemap.transformer.linkrewriter
src=org.apache.cocoon.transformation.LinkRewriterTransformer
+link-attrshref src/link-attrs
+schemessite ext/schemes
+
input-module name=site
input-module name=linkmap
file src={src} reloadable=false /
@@ -78,13 +81,8 @@
map:matcher name=regexp
src=org.apache.cocoon.matching.RegexpURIMatcher/
/map:matchers
-map:actions
- map:action logger=sitemap.action.resource-exists
name=resource-exists src=org.apache.cocoon.acting.ResourceExistsAction/
-/map:actions
-
-map:selectors default=exists
- map:selector logger=sitemap.selector.exists name=exists
-src=org.apache.cocoon.selection.ResourceExistsSelector /
+map:selectors
+ map:selector logger=sitemap.selector.exists name=exists
src=org.apache.cocoon.selection.ResourceExistsSelector /
/map:selectors
map:pipes default=caching
@@ -115,6 +113,7 @@
map:parameter name=isfaq value={notoc}/
map:parameter name=nopdf value={nopdf}/
map:parameter name=path value={path}/
+map:parameter name=obfuscate-mail-links value=false/
!-- Can set an alternative project skinconfig here
map:parameter name=config-file
value=../../../../skinconf.xml/
--
@@ -131,91 +130,60 @@
map:pipeline internal-only=false
!--
--
- !-- OUTPUT
FORMATS --
- !-- Serves content directly to the
user --
- !--
+==+ --
+ !-- SOURCE
FORMATS --
+ !-- Raw XML sources, typically doc-v11
format--
+ !--
--
- !-- COCOON SPECIFIC --
- map:match pattern=**.txt
-!-- Handle .txt files (incorrectly) placed in xdocs. Forrest
will
-eventually evolve to handle mixed-content scenarios (JT) --
-map:read src=content/xdocs/{0} mime-type=text/plain/
+ map:match pattern=changes.xml
+map:mount uri-prefix= src=status.xmap check-reload=yes /
/map:match
- !-- /COCOON SPECIFIC --
- map:match type=regexp pattern=^.+$
-map:select type=exists
- map:when test=content/{0}
-map:mount uri-prefix= src=raw.xmap check-reload=yes /
- /map:when
-/map:select
+ map:match pattern=todo.xml
+map:mount uri-prefix= src=status.xmap check-reload=yes /
/map:match
- map:match pattern=*.html
-map:aggregate element=site
- map:part src=cocoon:/tab-{1}.xml/
- map:part src=cocoon:/menu-{1}.xml/
- map:part src=cocoon:/body-{1}.xml/
-/map:aggregate
-map:call resource=skinit
- map:parameter name=type value=site2xhtml/
- map:parameter name=path value={0}/
-/map:call
- /map:match
-
- map:match pattern=**/*.html
-map:aggregate element=site
- map:part src=cocoon:/{1}/tab-{2}.xml/
- map:part src=cocoon:/{1}/menu-{2}.xml/
- map:part src=cocoon:/{1}/body-{2}.xml/
-/map:aggregate
-map:call resource=skinit
- map:parameter name=type value=site2xhtml/
- map:parameter name=path value={0}/
-/map:call
+ map:match pattern=**dtdx.xml
+map:mount uri-prefix= src=dtd.xmap check-reload=yes /
/map:match
+ map:match pattern=**linkmap*
+map:mount uri-prefix= src=linkmap.xmap check-reload=yes /
+ /map:match
- !-- Special matcher for FAQ PDFs, so we can pass an extra
- 'numbersections' param into document2fo.xsl --
- map:match pattern=**faq.pdf
-map:generate src=cocoon:/{1}faq.xml/
-map:transform src=skins/{forrest:skin}/xslt/fo/document2fo.xsl
- map:parameter name
Re: commit access on Cocoon for sub project committers
Steven Noels wrote: On 24/06/2003 10:02 Michael Wechner wrote: snip / avail|stefano,balld,ricardo,rubys,ben,zvia,giacomo,gears,bmclaugh,bloritsch,rossb,jeremy,greenrd,dims,ssahuc,prussell,cziegeler,mman,sylvain,vgritsenko,haul,morrijr,crossley,ovidiu,tcurdt,gianugo,froehlich,huber,dirkx,butlermh,nicolaken,ivelin,kpiroumian,shannon,proyal,stephan,coliver,crafterm,acoliver,stevenn,bdelacretaz,mlangham,michaelm,jefft,pier,bruno,asavory,ghoward,andreas,alexmcl,egli,gregor,michi,edith,felix,liyanage,memo,thorsten,joerg,upayavira|xml-site,xml-commons,cocoon-1,cocoon-2-historical,cocoon-2.0,cocoon-2.1,cocoon-lenya,cocoon-site,avalon-excalibur,avalon-sandbox So Lenya peeps have access to ours, and we have access to theirs. The fact that it has been set up that way doesn't reflect any policy, it was just the guy who set it up who fancied this would be a decent setup. I find it reasonable as well. We are supposed to review commit messages anyhow, well, does that mean I should checkin the patched ResourceExistsAction? It seems to me that the whole dicussion about checking in the ResourceExistsAction got a bit sidetracked ;-) Thanks Michael and it seems like a nice way to warn people they should think twice before bringing on new subprojects or committers. IMHO, XML and Jakarta are impenetrable forests of projects because of overcompartimentalisation and putting large walls between cubicles. If anyone wants to see this changed, please speak up. /Steven
Re: commit access on Cocoon for sub project committers
On 25/06/2003 22:54 Michael Wechner wrote: well, does that mean I should checkin the patched ResourceExistsAction? It seems to me that the whole dicussion about checking in the ResourceExistsAction got a bit sidetracked ;-) Sure, go ahead. If you'd feel better by adding a [PATCH] in Bugzilla for peer review, fine as well. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Syncing rhino
on 6/24/03 12:30 PM Geoff Howard wrote: At 01:00 PM 6/24/2003, Gianugo wrote: Christopher Oliver wrote: OK... I spent some more time with the code and did some steps forward. Now, unfortunately, I'm stuck due to my ignorance: any further step would be just a wild bet from my part, and it would take me a lot of time to get acquainted with all the technologies involved (core javascript and hard-core continuation inners). Let's see if we can strike a deal, while we try to find a better solution with the Rhino guys (something that ATM seems unlikely to me, given also that they are in RC phase): If we integrate the continuations code with the current rhino cvs, I'm pretty sure Norris will commit it for us. But AFAIK that's not going to be easy. This is good news. I understand that it's very difficult, but I hope that it might be easier than you think, and I hope I can somehow help you in that. Anyway, given that you are the only one showing some interest, I'm starting to think that I'm just being paranoid... You are not being paranoid. I have been uneasy about the forked rhino code but have kept quiet because I'm such a junior member of this community, because I personally did not feel able (time or knowledge wise) to help fix the situation, and because I am so behind on really understanding flow and continuations. But I think the longer we go on building on this sand the more trouble we will be in when the inevitable happens. I for one am reading every word you two write. I'm with brother Geoff on this and have expressed my concerns in the past already. I've also being discussing this with Ricardo and we were going to take a look on synching back the continuation changes after finishing the FOM (which has a higher priority, IMO). So, no, you are not being paranoid but realistic in removing some of the sand we are building on. -- Stefano.
Re: Syncing rhino
on 6/24/03 2:29 PM Gianugo Rabellino wrote: Geoff Howard wrote: This is good news. I understand that it's very difficult, but I hope that it might be easier than you think, and I hope I can somehow help you in that. Anyway, given that you are the only one showing some interest, I'm starting to think that I'm just being paranoid... You are not being paranoid. I have been uneasy about the forked rhino code but have kept quiet because I'm such a junior member of this community, because I personally did not feel able (time or knowledge wise) to help fix the situation, and because I am so behind on really understanding flow and continuations. But I think the longer we go on building on this sand the more trouble we will be in when the inevitable happens. I for one am reading every word you two write. Thanks for supporting my position. :-) Just to make things clear, I want to stress that I have the highest respect for what Christopher has brought us so far: it's an impressive work, and it surely paved the way to a brighter future in web applications. I also fully understand his lack of resources/time to follow ATM the Rhino development However, I'm at a crossroads now: I have to decide wether limit myself to keep an eye on the flow or place a bet and use it for my daily job. Having such a core functionality rely heavily on an _unreleased_, _old_ and _third party_ software (though quite stable) is refraining me from using it more seriously. I might even say that, while not blocking the beta, this might be considered a showstopper for a final release of the flow. What I'm trying to do, here and now, is help wherever I can: I lack the skills and knowledge to approach right now such hard core stuff, so I'm willing to do whatever I can to ease other's efforts. Succeeding in having the continuations code in the Rhino tree will be a major success and overhaul for the Cocoon flow. Even greater would be having a community ownership on the flow as a whole, including the javascript core stuff. I can say I totally share your concerns and appreciate your words to summarize it. I also think that a direct development link between apache and mozilla might open the door for even more exciting opportunities in the future. And having the cocoon community pave the road for this, would be very exciting from both a software development and community development point of view. -- Stefano.
Re: Syncing rhino
on 6/24/03 3:48 PM Christopher Oliver wrote: Although I think it would be nice to sync with the Rhino cvs, I can tell you from personal experience that the Rhino code at cocoondev.org is more stable than Cocoon itself at this point. So I think trying to place the blame on Rhino for not using the flow is misguided. You also need to take into account that the Cocoon community is much stronger than the one supporting Rhino. Basically there are only two Rhino committers, Igor Bukanov and Norris Boyd, and only one (Igor) is currently active. You raise a really interesting point: what if synching back increases our political comfort but reduces our ability to control the software? I, for one, would not trade political comfort for software control. But in that case, our fork must be made explicit and the project name changed. I'm not sure I want that, also because it would shade a really bad light on us that kept on the fork without asking for convergence. You say that Cocoon's is a healthier community than Rhino. It's not hard to imagine, also given the limited scope (and use) of Rhino inside the mozilla organization. Now, it can be possible to propose a migration of Rhino into Apache, but would that really make sense? I think that the option of active and direct collaboration between Cocoon and Rhino would be better for both. It might increase their community, create a solid political link (that today is missing), give us a meritocratic control on the platform (cocoon is probably going to become one of the most important rhino customers). So, it might be good to start talking to them *before* we even attempt to do anything from a code perspective, maybe they have ideas on how to solve things easily or maybe even converge to a common point. In the past, Chris talked to them as a simple committer that added non-standard features on Rhino before it changed incompatibly. Today, we can approach them as a massive and well known development community that is willing to do whatever it takes to avoid a fork on rhino that might break their user base in two and therefore hurt both sides. The political impact is *way* different, their reaction this time might be as well. We don't want to harm Rhino, but we might well end up doing it if the two branches are not synched back. Chris alone didn't create much of a forking threat for Rhino, Cocoon seriosly does. This means that it's not only *our* interest to keep things in synch (as it was only Chris' in the past), but it might well become *their* interest as well, as we put much more pressure as a visible and recognized community. So, I suggest that we explain to them what the problem is, propose our solution and see how the react and what they have to propose back, hopefully willing to settle on a common ground to avoid the fork. We won't use the fork as a threat, it's not our intention, but if we don't synch back, shit may happen and we want to avoid it. What do you think? -- Stefano.
DO NOT REPLY [Bug 21075] - Wrong link to Lenya
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=21075. 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=21075 Wrong link to Lenya [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-06-25 21:31 --- Carsten fixed it in the CVS.
DO NOT REPLY [Bug 21075] - Wrong link to Lenya
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=21075. 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=21075 Wrong link to Lenya [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED
Re: FOM, views, and input modules
on 6/25/03 4:35 AM Reinhard Pötz wrote:
From: Christopher Oliver [mailto:[EMAIL PROTECTED]
I modified the FOM implementation in the scratchpad to make the FOM
available to the view layer, thinking that the view author
also should
see the FOM (See FOM_JavaScriptFlowHelper.java), rather than the raw
Request, Response, etc. Do others agree with this?
I see no disadvantage.
The same is valid for the view layer as explained from you below!
You can still pass parameters to generators or transformers of pipelines
called by the flow layer.
Additionally you can call pipelines that contain actions. Do we want
this?
if someone wants to use actions in their pipelines, it's their choice,
we should not restrict anything in the sitemap from the flow.
I'm worried that people start to work around the restrictions of the FOM
We should not think we know it all. The FOM can be designed to limit
the ability to abuse, but there is no way we can prevent abuse even if
we want to and, besides, what we consider abuse today, might become good
practice tomorrow (or viceversa).
So, don't be too concerned.
I also modified the GarbageGenerator to use the FOM.
That's awesome.
So because of the FOM you can't do this in a flow script anymore:
cocoon.request.sitemapURI
likewise in a Garbage view template you can no longer do this:
page whatever={$request/sitemapURI}
in both cases because the FOM doesn't expose the sitemapURI
property
of the Request.
Yes.
However the input modules give full access to the original
Java Request
object, so in the sitemap you can still do this:
map:call function=whatever
map:parameter name=whatever value={request:sitemapURI}/
and pass it as a parameter to your flowscript, bypassing the FOM (!)
This seems inconsistent to me. What do others think?
Having a completely consistent architecture in an open source project is
impossible, because it's developped in an incremental way and it's hard
to deprecate things because people get used to them.
Inconsistency is not, again, necessarely a bad thing from an design
evolution perspective.
The reason not to expose sitemapURI is to promote the use of link
translation, that is IOC applied to URI referencing.
But I expect this to take a while to catch up, so i think it's good
there is a way to bypass what is now considered as a FOM limitation
without requiring deprecation of methods in the future.
Yes, you are right! Maybe we should disable input module substituion
within
call elements of the sitemap. (I don't know if this is possible at all.)
What do you think?
-1, it's too harsh and people would not understand why we are doing this.
i simply expect people to stop asking for URI fragments to the request
to assemble the URI calls by themselves and let the link translation
transformers do it for them.
But again, we have to show what we consider a best practice so that
people can follow.
--
Stefano.
Re: Syncing rhino
Stefano Mazzocchi wrote: I think that the option of active and direct collaboration between Cocoon and Rhino would be better for both. It might increase their community, create a solid political link (that today is missing), give us a meritocratic control on the platform (cocoon is probably going to become one of the most important rhino customers). So, it might be good to start talking to them *before* we even attempt to do anything from a code perspective, maybe they have ideas on how to solve things easily or maybe even converge to a common point. Hmmm... don't forget that this is Open Source (oh well, I bet you know that ;-)) and as NKB loves to say, discussions get forgotten, just code remains. :-) I would say then that it would be nice to go to the Rhino community with suggestions *and* some code. I have been looking at it more thouroughly and as of now I think that the real problem is not really Rhino missing continuations, but Rhino being coded not to be extensible: most classes we need to extend are final, and members we need access to are private. So far Cristopher and I went quite the easy way, changing accesses and declarations just when needed, but it won't take a huge effort to refactor the few classes we need in order (adding getter/setters and the like) to make them really extensible. Once this is done, the continuation-specific code might happily live in the Cocoon CVS as a Rhino extension if the Mozilla community is not willing to accept it (and actually I don't really see a real reason for them to include it ATM since Cocoon would be the only customer for that) and we might control it with Gump guarding against back-incompatible changes. This will take no more than a few hours of (boring) coding, and I'm willing undertake the effort if it sounds reasonable to us all, and produce a first working extensible JavaScript interpreter that might be committed in Rhino. Meanwhile, we can start approaching the Rhino guys and see what they think aboout it. How does it sound? -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RFI] Garbage
on 6/23/03 8:29 PM Pier Fumagalli wrote:
SetAttribute vs Well-formedness:
Briefly, I wanted to check with you people if a functionality like the XSLT
setattribute is required, or the non-well-formedness of Garbage is better
(see previous messages on this thread)... Both approaces have advantages,
but it's either an out-out choice: either we have non-well-formedness a-la
#if {something}
paragraph class=myClass
#else
paragraph type=outerType
#end
/paragraph
Or we have setattribute a-la:
paragraph
#if {something}
[EMAIL PROTECTED]myClass}
#else
[EMAIL PROTECTED]outerType}
#fi
/paragraph
Think also in the case in which the attribute starts with xmlns, so, the
attribute defines a namespace scoping... I don't know... I need input on
this.
I like the second better. It's more structured, suggests a non-textual
vision of the created content, while the first is too PHP-like for my
personal taste.
But then again, if we are going for utter simplicity, probably newbies
think of text more than they think about an abstract infoset
representation of the content. So #1 might be easier to understand up front.
A verbosity problem, however, comes out if we have several attributes to
be conditionally decided, because that creates an explosion of possible
element/attributes combinations and all of them have to be exposed.
Nah, I vote for #2.
Including and calling templates:
--
I believe that Chris outlined that we definitely need to have an #include or
#import function to import templates defined in other source files, but I
also wanted to know if there's the need to have a parallel to templates
matching and application as in XSLT...
Personally, I don't need it... I believe that the source template should
exactly look like the output we want to produce, so applying templates on
matching template rules should be out of the question, but maybe something
like this might be useful:
html
body
#foreach {request/header}
#call subtemplate
#end
/body
/html
#template subtemplate
p
{./value}
/p
#end
Allowing call to access internally defined subtemplates, and to access
templates defined in other files...
Dunno...
This is what they call macro in Velocity and I bet that it might be
something people will ask once include is implemented as you can 'reuse'
parts of the templates between them.
But I would leave the #call concept out for now, also because parameter
passing is not exactly a no brainer to design.
Output caching:
---
I believe it is wrong to give to the template a copy of the response
object in any case (the response should be available only to serializers,
not to generators).
Agreed. Also note that if you need to modify stuff in the response, you
have the flow to do it. Views should not mess with the transport but
only with the content and having access to the view allows them to mess
with transport and I dislike it.
Also, I think that the request object should not always be given to the
template (and included in the set of objects available to JXPath) because of
problems with caching...
Hmmm, I don't know here, you might end up copying a bunch of request
stuff into the model passed to the view, but you are right pointing out
that Caching is an important aspect to consider. But I wonder if
performing an hashcode of the bean passed to the view is good enough to
estimate its ergodicity.
I believe that (correct me if I'm wrong), if every object in the root JXPath
context is cacheable and valid, and if the template has not changed, its
output should not be re-generated, and therefore the entire generation can
be cached (as we do with the FileGenerator).
this is true if and only if the output of the template is a function of
the input only (for example, doesn't depend on things like time or
system load or other environmental inputs). But again, how are you going
to identify if the input to the template hasn't changed?
Imagine that somehow, in a factory somewhere, I create an Article object,
and that is cached in my JVM by my ArticleFactory
If Article implements CacheableProcessingComponent, and at request time
this has not changed, and the template itself has not changed, I don't think
that we need to re-run the generation stage again.
This is true only if you have a way to understand if the input to the
template hasn't changed between the last execution. Understanding this
might, in general, be more expensive than redoing the processing.
Until we implement a caching system that can adapt to efficiency
measurement (as I planned before the current SAX-based cache was
implemented), the whole value of template caching is hard to estimate.
Giving access to Request to the template
Re: Syncing rhino
on 6/25/03 4:55 PM Gianugo Rabellino wrote: Stefano Mazzocchi wrote: I think that the option of active and direct collaboration between Cocoon and Rhino would be better for both. It might increase their community, create a solid political link (that today is missing), give us a meritocratic control on the platform (cocoon is probably going to become one of the most important rhino customers). So, it might be good to start talking to them *before* we even attempt to do anything from a code perspective, maybe they have ideas on how to solve things easily or maybe even converge to a common point. Hmmm... don't forget that this is Open Source (oh well, I bet you know that ;-)) and as NKB loves to say, discussions get forgotten, just code remains. :-) I would say then that it would be nice to go to the Rhino community with suggestions *and* some code. I have been looking at it more thouroughly and as of now I think that the real problem is not really Rhino missing continuations, but Rhino being coded not to be extensible: most classes we need to extend are final, and members we need access to are private. So far Cristopher and I went quite the easy way, changing accesses and declarations just when needed, but it won't take a huge effort to refactor the few classes we need in order (adding getter/setters and the like) to make them really extensible. Once this is done, the continuation-specific code might happily live in the Cocoon CVS as a Rhino extension if the Mozilla community is not willing to accept it (and actually I don't really see a real reason for them to include it ATM since Cocoon would be the only customer for that) and we might control it with Gump guarding against back-incompatible changes. This will take no more than a few hours of (boring) coding, and I'm willing undertake the effort if it sounds reasonable to us all, and produce a first working extensible JavaScript interpreter that might be committed in Rhino. Meanwhile, we can start approaching the Rhino guys and see what they think aboout it. How does it sound? I love the incremental approach. +1 -- Stefano.
Re: What hacks are going on in Cocoon?
Bruno Dumon wrote:
If you have some time, could you compare the current behaviour with
that of xalan 2.5 and 2.4.1, to see if this got worse recently?
Hello Bruno,
back to these bugs - we stumbled over them in our company, where we use
Cocoon 2.0.4 and updated Xalan to 2.4.1.
The pipe:
map:match pattern=*.xbl
map:generate src={1}.xbl/
map:serialize type=xml/
/map:match
The file:
bindings xmlns=xbl-namespace-uri xmlns:xbl=xbl-namespace-uri
xmlns:xul=xul-namespace-uri
binding
content
xul:textbox xbl:inherits=class/
/content
/binding
/bindings
The result (with Xalan 2.4.1):
xbl:bindings xmlns=xbl-namespace-uri xmlns:xbl=xbl-namespace-uri
xmlns:xul=xul-namespace-uri
xbl:binding
xbl:content
xul:textbox xbl:inherits=class/
/xbl:content
/binding
/bindings
While with old Xalan 2.2.D11 from JDK on every element the xbl
namespace-prefix was added correctly (also on endElement). This can be
seen still at http://conweb.virbus.de/conweb/binding/textbox.xml (using
Mozilla; only if http://conweb.virbus.de/conweb/ shows still version
2.1.12, the page will be updated probably tomorrow).
The solution here was simple: replacing generator + serializer by a
reader. But I guess this is not always possible. Xalan 2.4.1 and up
seems to have problems when the default namespace and a namespace-prefix
are set to one namespace-uri.
Joerg
[OT] CVS access over SSH
Sorry for the off-topic post but I have a problem accessing Cocoon with SSH using Putty (win2k). Is there anybody out there who runs this configuration? I get some real strange error messages. TIA! Reinhard P.S. Of course I would write some documentation, promised!
Re: [OT] CVS access over SSH
Reinhard Pötz wrote: Sorry for the off-topic post but I have a problem accessing Cocoon with SSH using Putty (win2k). Is there anybody out there who runs this configuration? I get some real strange error messages. I do... what messages do you get? cheers -- Torsten
RE: Syncing rhino
... I would say then that it would be nice to go to the Rhino community with suggestions *and* some code. I have been looking at it more thouroughly and as of now I think that the real problem is not really Rhino missing continuations, but Rhino being coded not to be extensible: most classes we need to extend are final, and members we need access to are private. So far Cristopher and I went quite the easy way, changing accesses and declarations just when needed, but it won't take a huge effort to refactor the few classes we need in order (adding getter/setters and the like) to make them really extensible. Once this is done, the continuation-specific code might happily live in the Cocoon CVS as a Rhino extension if the Mozilla community is not willing to accept it (and actually I don't really see a real reason for them to include it ATM since Cocoon would be the only customer for that) and we might control it with Gump guarding against back-incompatible changes. This will take no more than a few hours of (boring) coding, and I'm willing undertake the effort if it sounds reasonable to us all, and produce a first working extensible JavaScript interpreter that might be committed in Rhino. Meanwhile, we can start approaching the Rhino guys and see what they think aboout it. How does it sound? I love the incremental approach. +1 -- Stefano. Great all around. If you lay out a general road map of what needs to be done, I'd like to try to help - but won't see daylight enough to do so for about a week. If you're not done by then, count me in. Chris, is this a plan with teeth? Geoff
RE: Syncing rhino
+1. Refactoring the Rhino core to be extensible is the proper solution IMO. However, the use of implementation inheritance in Rhino is going to be a major problem: virtually every class that I originally extended has changed significantly in incompatible ways. I'm really not sure what can be done about that. Regards, Chris -Original Message- From: Geoff Howard [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2003 5:35 PM To: [EMAIL PROTECTED] Subject: RE: Syncing rhino ... I would say then that it would be nice to go to the Rhino community with suggestions *and* some code. I have been looking at it more thouroughly and as of now I think that the real problem is not really Rhino missing continuations, but Rhino being coded not to be extensible: most classes we need to extend are final, and members we need access to are private. So far Cristopher and I went quite the easy way, changing accesses and declarations just when needed, but it won't take a huge effort to refactor the few classes we need in order (adding getter/setters and the like) to make them really extensible. Once this is done, the continuation-specific code might happily live in the Cocoon CVS as a Rhino extension if the Mozilla community is not willing to accept it (and actually I don't really see a real reason for them to include it ATM since Cocoon would be the only customer for that) and we might control it with Gump guarding against back-incompatible changes. This will take no more than a few hours of (boring) coding, and I'm willing undertake the effort if it sounds reasonable to us all, and produce a first working extensible JavaScript interpreter that might be committed in Rhino. Meanwhile, we can start approaching the Rhino guys and see what they think aboout it. How does it sound? I love the incremental approach. +1 -- Stefano. Great all around. If you lay out a general road map of what needs to be done, I'd like to try to help - but won't see daylight enough to do so for about a week. If you're not done by then, count me in. Chris, is this a plan with teeth? Geoff
Re: How ASF membership works and what it means
on 6/24/03 6:55 AM Dirk-Willem van Gulik wrote: Then perhaps my observation means absolutely nothing - and I should really try to get my mind around a fundamentally different development model (and some aspect you call WORA). Oh, sorry, WORA := Write Once Run Anywhere. It's java's first commandament. Basically, it's bullshit: java runs everywhere because all virtual machines descend from the same codebase (in fact, those exotic virtual machines like Kaffe or natively-gcc-compiled are not used because the number of small incompatibilities/deficiencies is simply too big). WORA translates automatically into Java's biggest sin: native code. Java programmers were tough the religion of java purity as the only way to purify their souls from the sin of native code. This is the reason why we basically we have mod_* where * is any programming language, but not mod_java, there is no java API that mimics the HTTPD API because we preferred to avoid the sin of doing JNI (java native interface) and preferred the socket disconnected way with mod_jserv. note that for apache 1.3.x, JNI would have been hard because of the multi-process environment, but for apache 2.0, a JNI-based mod_java is perfectly valid architecturarely, but nobody works on it because of this sin syndrome. Also, java programmers tend *not* to have any knowledge of things like how to link a library in a native environment. basically they are totally isolated, which leads to concepts such as server microkernel architectures (avalon Phoenix) which look cool from a purely architectural perspective, but are totally weak from a security and stability perspective, because they use one JVM for the entire thing, a very weak setup. Pier is probably the only person I know who has great capacity on both sides of the fence and he tried to add unix deamon-like capabilities to java but crushed into several JCP walls where native stuff is still seen as a sin. Note how Java failed on the client side because of how slow swing is. Eclipse introduces SWT, something that Sun really disliked because of considered again a sin to have something OS-specific. Again, the culture difference between java and python, for example, is that python has OS-specific features, java does not and will never. java is based on a common denominator. Python is based on giving access to what you have. note how apple provides OS-specific hooks to java and native alternate implementations of java libraries (such as swing). we'll see how much this impact the java purity concept. this is just to show how peculiar the java development culture is. personally, I feel ashamed I was not able to see that this WORA concept is just bullshit and that I wasn't able to see how mentally limiting this pure java thing is. But it's far from common to have language open mindness in the java world and this is due to this purity religion. - the java world seems to need amazing number of indians (or committers) relative to lines of codes or bugs fixed. And seems to see more isolated pockets of people than the xml and other parts of the ASF. I don't get what you mean here, can you elaborate more? Actually - an extension of your Agora should propably be better at showing and modeling it; I was basically looking at commit-scope of people in a single code bases across projects. And had the impression that we see smaller scope activity, by more people relative to total project activity; and more often by people who only work on that part - but do not 'participate' in the larger architecture and structure. I see. But gathering this data would be a pretty hard CVS datamining problem. Anyway, agora can visualize any structure you come out with so if you want to experiment with it, it would be very cool and I might even be able to help you. But the latter part is not really proper statistics. Let me try to back that up when I have some time. Cool, let me know when you come up with some data to show. -- Stefano.
Re: [VOTE] Give all Cocoon committers CVS access?
on 6/24/03 7:19 AM Carsten Ziegeler wrote: Nicola Ken Barozzi wrote: Jeff Turner wrote, On 24/06/2003 13.38: As most of you probably saw, there's a thread on cocoon-dev suggesting that Forrest ought to be a Cocoon subproject, with the consensus being it makes sense. AFAICT the only practical difference would be that Cocoon committers would automatically become Forrest committers. Sounds fine to me. Can we vote on these issues then? Vote 1: Cocoon committers automatically become Forrest committers +1 +1 +1 Vote 2: Forrest should become a subproject of Cocoon (http://cocoon.apache.org/forrest) +1 +1 +1 /SNIP PS: This makes me think that Linotype should have its own project rather than being just a block... I think some other current blocks are good candidates as subprojects but I guess we are not ready for that now - I think, this fits a little bit in the context of real blocks. I agree with Carsten here, until we have a real deployment infrastructure, it would just create more harm than good to hyperfragment our blocks into their own projects. -- Stefano.
cvs commit: cocoon-2.1/src/blocks/linotype/samples/stylesheets news2rss-0.91.xslt news2rss-2.0.xslt
stefano 2003/06/25 20:09:49 Modified:src/blocks/linotype/samples/stylesheets news2rss-0.91.xslt news2rss-2.0.xslt Log: fixing problem with RSS validation, strangely enough, the RSS validator doesn't appear to validate the resulting RSS anymore because it doesn't like the body xhtml tag, if any RSS validation guru wants to take a look at this, it will be greatly appreciated. Revision ChangesPath 1.2 +1 -1 cocoon-2.1/src/blocks/linotype/samples/stylesheets/news2rss-0.91.xslt Index: news2rss-0.91.xslt === RCS file: /home/cvs/cocoon-2.1/src/blocks/linotype/samples/stylesheets/news2rss-0.91.xslt,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- news2rss-0.91.xslt17 Jun 2003 01:32:43 - 1.1 +++ news2rss-0.91.xslt26 Jun 2003 03:09:49 - 1.2 @@ -25,7 +25,7 @@ item titlexsl:value-of select=n:title//title linkxsl:value-of select=$home//xsl:value-of select=../@id///link - descriptionxsl:apply-templates//description + descriptionxsl:apply-templates select=h:body//description /item /xsl:template 1.2 +1 -1 cocoon-2.1/src/blocks/linotype/samples/stylesheets/news2rss-2.0.xslt Index: news2rss-2.0.xslt === RCS file: /home/cvs/cocoon-2.1/src/blocks/linotype/samples/stylesheets/news2rss-2.0.xslt,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- news2rss-2.0.xslt 17 Jun 2003 01:32:43 - 1.1 +++ news2rss-2.0.xslt 26 Jun 2003 03:09:49 - 1.2 @@ -28,7 +28,7 @@ item titlexsl:value-of select=n:title//title linkxsl:value-of select=$home//xsl:value-of select=../@id///link - descriptionxsl:apply-templates//description + descriptionxsl:apply-templates select=h:body//description pubDatexsl:value-of select=@creation-fulldate//pubDate /item /xsl:template
cvs commit: cocoon-2.1 forrest.properties
crossley2003/06/25 20:16:39
Modified:.forrest.properties
Log:
Temporary fix for recent problems caused by now copying the DTDs and some
supporting xml docs into the build tree.
Revision ChangesPath
1.14 +1 -1 cocoon-2.1/forrest.properties
Index: forrest.properties
===
RCS file: /home/cvs/cocoon-2.1/forrest.properties,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- forrest.properties20 Jun 2003 01:42:40 - 1.13
+++ forrest.properties26 Jun 2003 03:16:38 - 1.14
@@ -78,7 +78,7 @@
#forrest.validate.xdocs.failonerror=${forrest.validate.failonerror}
#
#forrest.validate.xdocs.includes=**/*.x*
-forrest.validate.xdocs.excludes=site.xml,status.xml,drafts/*.xml,dictionary.xml,catalog-test.xml,ctwig/sample/**/*.xml,tabs.xml
+forrest.validate.xdocs.excludes=site.xml,status.xml,drafts/*.xml,dictionary.xml,catalog-test.xml,**/catalog-demo/*.xml,ctwig/sample/**/*.xml,tabs.xml
#
#forrest.validate.skinconf.includes=${skinconf-file}
#forrest.validate.skinconf.excludes=
Re: FOM implementation
on 6/21/03 10:55 AM Christopher Oliver wrote: OK. I didn't implement the following, so if you or anyone else would like to, please go ahead: Cocoon.addEventListener() Cocoon.removeEventListener(); Cocoon.getComponent() Can someone explain the purpose and behavior of these operations? I finally had the time to look into the FOM today and I saw your comments. Please allow me to explain my intentions with the above methods: 1) addEventListener/removeEventListener the Servlet API introduces in version 2.3 an event model which is basically connected to remouval of session values. The servlet API version 2.4 (yet to be finalized) introduced a number of new events, even if, to be honest, many of them are utterly useless and were probably introduced for symmetry (something which I dislike, but anyway) the two methods above describe a hook to connect event listeners (implemented as flow functions) to the events that the flow could generate. Now, the flow event model is yet to be defined, so those methods are useless for now. Given the state of the FOM, I would also be ready to comment them out (for now) and go on with more important things until we have time to define a basic event model for the flow (basically, what events are generated and when). 2) getComponent() returns an avalon component which is not a sitemap component. Basically, it has to ask to the cocoon component manager to return the component identified with the given role and check if it doesn't implement SitemapModelComponent, in which case an exception should be thrown. What do you think? -- Stefano.
Re: FOM implementation
on 6/21/03 10:55 AM Christopher Oliver wrote: OK. I didn't implement the following, so if you or anyone else would like to, please go ahead: Cocoon.addEventListener() Cocoon.removeEventListener(); Cocoon.getComponent() Can someone explain the purpose and behavior of these operations? I finally had the time to look into the FOM today and I saw your comments. Please allow me to explain my intentions with the above methods: 1) addEventListener/removeEventListener the Servlet API introduces in version 2.3 an event model which is basically connected to remouval of session values. The servlet API version 2.4 (yet to be finalized) introduced a number of new events, even if, to be honest, many of them are utterly useless and were probably introduced for symmetry (something which I dislike, but anyway) the two methods above describe a hook to connect event listeners (implemented as flow functions) to the events that the flow could generate. Now, the flow event model is yet to be defined, so those methods are useless for now. Given the state of the FOM, I would also be ready to comment them out (for now) and go on with more important things until we have time to define a basic event model for the flow (basically, what events are generated and when). 2) getComponent() returns an avalon component which is not a sitemap component. Basically, it has to ask to the cocoon component manager to return the component identified with the given role and check if it doesn't implement SitemapModelComponent, in which case an exception should be thrown. What do you think? -- Stefano.
cvs commit: cocoon-2.1/src/webapp/WEB-INF/entities/catalog-demo override.txt testpub.txt testsys.txt override.xml testpub.xml testsys.xml
crossley2003/06/25 21:12:59 Modified:src/webapp/WEB-INF/entities catalog src/webapp/samples/catalog catalog-demo.xml Added: src/webapp/samples/catalog testovr.txt src/webapp/WEB-INF/entities/catalog-demo override.txt testpub.txt testsys.txt Removed: src/webapp/samples/catalog testovr.xml src/webapp/WEB-INF/entities/catalog-demo override.xml testpub.xml testsys.xml Log: Workaround a stupid problem. The catalog demo was including snippets of xml via entities. The xml validation was failing because these snippets did not declare their DTD. We can get around that using an internal DTD subset. However when we do that, then the parser complains when it includes those snippets saying DOCTYPE declaration not allowed in content. Catch-22. Yet another reason to move away from using DTDs for xml validation. So now using plain-text snippets for this demo. Revision ChangesPath 1.4 +3 -3 cocoon-2.1/src/webapp/WEB-INF/entities/catalog Index: catalog === RCS file: /home/cvs/cocoon-2.1/src/webapp/WEB-INF/entities/catalog,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- catalog 25 Jun 2003 19:47:38 - 1.3 +++ catalog 26 Jun 2003 04:12:59 - 1.4 @@ -56,12 +56,12 @@ -- these entries are used for the catalog-demo sample application -- OVERRIDE NO PUBLIC -//Arbortext//TEXT Test Override//EN - catalog-demo/override.xml + catalog-demo/override.txt OVERRIDE YES PUBLIC -//Arbortext//TEXT Test Public Identifier//EN - catalog-demo/testpub.xml + catalog-demo/testpub.txt SYSTEM urn:x-arbortext:test-system-identifier - catalog-demo/testsys.xml + catalog-demo/testsys.txt PUBLIC -//Indexgeo//DTD Catalog Demo v1.0//EN catalog-demo/catalog-demo-v10.dtd -- end of entries for the catalog-demo sample application -- 1.4 +6 -6 cocoon-2.1/src/webapp/samples/catalog/catalog-demo.xml Index: catalog-demo.xml === RCS file: /home/cvs/cocoon-2.1/src/webapp/samples/catalog/catalog-demo.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- catalog-demo.xml 7 May 2003 04:57:12 - 1.3 +++ catalog-demo.xml 26 Jun 2003 04:12:59 - 1.4 @@ -7,7 +7,7 @@ bogus-system-identifier.xml !ENTITY testsys SYSTEM urn:x-arbortext:test-system-identifier !ENTITY testovr PUBLIC -//Arbortext//TEXT Test Override//EN - testovr.xml + testovr.txt !ENTITY % ISOnum PUBLIC ISO 8879:1986//ENTITIES Numeric and Special Graphic//EN//XML ISOnum.pen @@ -41,9 +41,9 @@ paraThe internal DTD subset of the top-level document instance goes on to declare the three external sub-document entities using various means. It also declares and includes the ISOnum set of character entities, - so that we can use entities like amp;frac12; (to represent frac12;). + so that we can use entities like amp;frac12; (to represent frac12;). Finally the internal DTD subset declares an internal general entity - for quot;notequot;. + for quot;amp;notequot;. /para /section @@ -51,14 +51,14 @@ paratestpub ... this entity is declared with a PUBLIC identifier and a bogus system identifier (which will be overridden by the catalog) /para - testpub; + paranote; testpub;/para /section section paratestsys ... this entity is declared with a SYSTEM identifier (which will be resolved by the catalog) /para - testsys; + paranote; testsys;/para /section section @@ -66,7 +66,7 @@ identifier (the catalog is set to not override this one, so the declared system identifier is used) /para - testovr; + paranote; testovr;/para /section /catalog-demo 1.1 cocoon-2.1/src/webapp/samples/catalog/testovr.txt Index: testovr.txt === This paragraph is automatically included from the testovr.txt external file. The location of this entity was not resolved by the catalog, because there is no matching catalog entry for its public identifier or its system identifier. So the declared system identifier is used, i.e. the file is retrieved relative to the top-level document. 1.1 cocoon-2.1/src/webapp/WEB-INF/entities/catalog-demo/override.txt Index: override.txt === This is content from the override.txt external file. This content will not actually be included, because the catalog was set with OVERRIDE NO for this public identifier.
cvs commit: cocoon-2.1 forrest.properties
crossley2003/06/25 21:17:24
Modified:.forrest.properties
Log:
Remove the recent workaround for an xml validation problem.
Revision ChangesPath
1.15 +1 -1 cocoon-2.1/forrest.properties
Index: forrest.properties
===
RCS file: /home/cvs/cocoon-2.1/forrest.properties,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- forrest.properties26 Jun 2003 03:16:38 - 1.14
+++ forrest.properties26 Jun 2003 04:17:24 - 1.15
@@ -78,7 +78,7 @@
#forrest.validate.xdocs.failonerror=${forrest.validate.failonerror}
#
#forrest.validate.xdocs.includes=**/*.x*
-forrest.validate.xdocs.excludes=site.xml,status.xml,drafts/*.xml,dictionary.xml,catalog-test.xml,**/catalog-demo/*.xml,ctwig/sample/**/*.xml,tabs.xml
+forrest.validate.xdocs.excludes=site.xml,status.xml,drafts/*.xml,dictionary.xml,catalog-test.xml,ctwig/sample/**/*.xml,tabs.xml
#
#forrest.validate.skinconf.includes=${skinconf-file}
#forrest.validate.skinconf.excludes=
RE: DTDs for document-v11
Carsten Ziegeler wrote: David Crossley wrote: Why do we need DTDs to be included here? If they need to be in Cocoon CVS, then shouldn't they be in WEB-INF/entities. The validate-xdocs task validates all our documents and uses the DTDs from the documentation directory. As the old document-10 dtd was already there, I thought it would be the natural place to put the newer dtd. I question why you want to use the new DTDs that are under development at Forrest. In Cocoon we still use the document-v10 DTDs for all of the xdocs. Do you really need the document-v1[12] DTDs or can you suffer the current one? There is a plan to do a bulk transformation to the new stuff, re-commit the new xdocs to cvs, and change the sitemap for webapp docs. However, that is complex and seems to have stalled. wiki:ForrestProposal If Cocoon starts to use a mixture of document types, then it might further complicate that process. --David
cvs commit: cocoon-2.1/src/documentation/images portal-parts.gif
cziegeler2003/06/25 22:43:42 Added: src/documentation/images portal-parts.gif Log: Adding missing image Revision ChangesPath 1.1 cocoon-2.1/src/documentation/images/portal-parts.gif Binary file
