Orbeon vs Cocoon?
Guys, Has anyone of you looked at Orbeon (www.orbeon.com)? I came across the site when looking for eXist info and found a comparison to Cocoon, an old version of Cocoon looking at the comparison result. Right now it looks like the website is down. At least I can't get to it. Bye, Helma
Re: Orbeon vs Cocoon?
Hi Helma, ...Has anyone of you looked at Orbeon (www.orbeon.com)?.. There have been discussions here from time to time, search for OXF in the mailing lists archives. I've talked to one of their head developers a while ago (hmmtwo years I think, time flies ;-) and my impression was that they were trying to cover more or less the same needs than Cocoon, but from a we're a commercial company perspective, which IIUC they believed would be more likely to be accepted by Fortune 500 folks. As we know, this is not the case, Fortune 500 companies prefer open source ;-) Only half-kidding here. I don't know where Orbeon as a company stands now (and I wish them all the best, honest), but it seems like companies which have gone the open source route have been very happy in 2004. It is my case (as a micro-company of one ;-), and I'm certainly not alone given the kind of success stories that we heard at the GT2004. Dunno what the OXF license is today, at the time it was closed. The Wayback Machine helps if their website is down: http://web.archive.org/web/*/http://www.orbeon.com -Bertrand smime.p7s Description: S/MIME cryptographic signature
RE: Orbeon vs Cocoon? - Live version available?
Hi Bertrand, I've looked at their site a few days ago and saw something mentioned about their code being open source. Haven't looked at it further (yet). I can't help but mention that the documentation on their website looks much better and much more coherent than Cocoon. So this is a challenge: to get our documentation up to speed. What I do like as well, and this might be easier (as in quicker) to accomplish is the fact that they have live samples on their website. I often want to have a quick look at the samples, but since I've set up my project along the YourCocoonProjectAnt16 instructions, my distro is as lean as possible and lacking all samples. That would mean I need a second build for the entire distribution. It would be nice if there was a place where the latest release would be running, so everyone could check it out. I know this requires cleaning up the crap that some people think they should enter, but that might be done through some simple scripts. It would also give future users the change to have a look at Cocoon before doing the actual download. And newbies can verify if they have done things correctly because they can compare their own version with THE live version. I know server hosting will be a problem, but maybe it's running somewhere already which could be made available to the world? WDYT? Bye, Helma -Original Message- From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] Sent: Friday, 17 December, 2004 09:42 To: [EMAIL PROTECTED] Subject: Re: Orbeon vs Cocoon? Hi Helma, ...Has anyone of you looked at Orbeon (www.orbeon.com)?.. There have been discussions here from time to time, search for OXF in the mailing lists archives. I've talked to one of their head developers a while ago (hmmtwo years I think, time flies ;-) and my impression was that they were trying to cover more or less the same needs than Cocoon, but from a we're a commercial company perspective, which IIUC they believed would be more likely to be accepted by Fortune 500 folks. As we know, this is not the case, Fortune 500 companies prefer open source ;-) Only half-kidding here. I don't know where Orbeon as a company stands now (and I wish them all the best, honest), but it seems like companies which have gone the open source route have been very happy in 2004. It is my case (as a micro-company of one ;-), and I'm certainly not alone given the kind of success stories that we heard at the GT2004. Dunno what the OXF license is today, at the time it was closed. The Wayback Machine helps if their website is down: http://web.archive.org/web/*/http://www.orbeon.com -Bertrand
Re: how to list all sitemap components
Carsten Ziegeler wrote: David Crossley wrote: That is the trouble - i don't know what is correct. :) The file called components-javadoc-sitemaptask-diff.txt is the difference between the list produced by scanning javadocs (finding extra clutter, maybe missing some) and the list produced by the SitemapTask. diff components-source.txt components-sitemaptask.txt Yepp. This is not to say that the scanning javadocs is finding all components. It is just to provide a method for comparison. Ok. Here are some examples of components that are not found by the SitemapTask ... org/apache/cocoon/matching/RegexpTargetHostMatcher org/apache/cocoon/transformation/JXTemplateTransformer org/apache/cocoon/selection/SessionStateSelector org/apache/cocoon/transformation/CachingCIncludeTransformer org/apache/cocoon/forms/formmodel/RepeaterAction Ah, so it's the other way round and the list I provided above are those that are not found in the javadocs, right? I'm still trying to make sense of the diff file: what line is missing in which file. The *Pipeline components that you listed above are found by the SitemapTask but not by the scan of javadocs. That is because the correlate-table.sh script forgot to look for pipelines. But do we consider them sitemap components that should be documented in the Userdocs? Yes, we should :) These are sitemap components, you can selected between different pipeline implementations in your sitemap (caching, non-caching etc.), so imho it makes sense to document them as well. That is what i thought but wasn't sure. Thanks. I will generate some fresh files and put them at my web space perhaps i can remove a bit more of the clutter. --David
Re: Orbeon vs Cocoon? - Live version available?
Le 17 déc. 04, à 10:13, [EMAIL PROTECTED] a écrit : I won't talk about the docs - we know ;-) ...What I do like as well, and this might be easier (as in quicker) to accomplish is the fact that they have live samples on their website... They were discussions a while ago that we might get a virtual machine on ASF infrastructure, but I haven't heard more. If we had this it would be fairly easy to setup a live instance of Cocoon for the samples (including automatic daily cleanup, we can simply wipe out the thing every day and rebuild it from a cron job). You're right that having live samples would be very helpful, if only because we could refer users to live URLs to see things working (and the corresponding source code), It could be a good motivation to make the samples more self-describing, which IMO is the best way of explaining the details. I've been playing with the openlaszlo samples yesterday night, being able to copy code into a web page and seeing the results immediately is an incredibly good way of learning (wouldn't be so easy with Cocoon apps but you get the idea I think). ...I know server hosting will be a problem, but maybe it's running somewhere already which could be made available to the world?.. Problem is, the load (CPU and bandwidth) on such a server is hard to estimate, so people might be wary of giving space on a machine that's used for something else. But if someone has a spare Linux machine somewhere (preferably Debian), or if this ASF virtual server things comes to life, I'd be happy to help setup and maintain this, assuming it would be considered a best effort and not a critical thing. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Cocoon-POI question
What do you all think about this simple (_TEMPORARY_) solution (in
attachment as EPStyle.java.diff)?
Regards,
Krystian
--
Krystian Nowak
[EMAIL PROTECTED]
===
Poznan Supercomputing and Networking Center
Poland, 60-814 Poznan, Zwierzyniecka 20
tel. (+48 61) 8582164 fax. (+48 61) 8582151
http://www.man.poznan.pl
===
BlueEyes - Human-Operator Monitoring System
http://www.blueeyes.prv.pl
http://www.cs.put.poznan.pl/csidc/2001
===
Index: EPStyle.java
===
RCS file:
/home/cvspublic/cocoon-2.1/src/blocks/poi/java/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements/EPStyle.java,v
retrieving revision 1.7
diff -u -r1.7 EPStyle.java
--- EPStyle.java5 Mar 2004 13:02:04 - 1.7
+++ EPStyle.java17 Dec 2004 10:12:11 -
@@ -41,6 +41,7 @@
*
* @author Marc Johnson ([EMAIL PROTECTED])
* @author Andrew C. Oliver ([EMAIL PROTECTED])
+ * @author Krystian Nowak (krystian _a_t_ man _d_o_t_ poznan _d_o_t_ pl)
* @version CVS $Id: EPStyle.java,v 1.7 2004/03/05 13:02:04 bdelacretaz Exp $
*/
public class EPStyle extends BaseElementProcessor {
@@ -116,6 +117,11 @@
convertVAlignment(getVerticalAlignment().getCode());
style.setVerticalAlignment(cnvvalign);
style.setFillPattern((short)getShade());
+style.setRotation(convertStyleOrientation(
+isStyleOrientationHoriz(),
+isStyleOrientationVertHorizText(),
+isStyleOrientationVertVertText(),
+isStyleOrientationVertVertText2()));
Workbook workbook = getWorkbook();
HSSFDataFormat dataformat = workbook.createDataFormat();
@@ -547,6 +553,20 @@
+ retval);
}
return retval;
+}
+
+/**
+ * deal with mismatch between gnumeric style orientation and Excel cell
style rotation
+ */
+private short convertStyleOrientation(
+boolean horiz, boolean vert_horiz_text, boolean vert_vert_text,
+boolean vert_vert_text2) {
+
+if(horiz (!vert_horiz_text) (!vert_vert_text)
(!vert_vert_text2)) {
+return 0;
+} else {
+return 90;
+}
}
} // end public class EPStyle
Cocoon-2.1.X Tests Failure 12/17/04
Automated Cocoon Unit tests failed! Full log file if this unit test run is available here: http://nagoya.apache.org/~vadim/cocoon-test-log-20041217.log Last messages from the log file: == [foreach] reader-mime-type.xml:39: Starting http://localhost:1///samples/test/reader-mime-type/test20.html [foreach] reader-mime-type.xml:41: Running test [Header: Content-type = text/html ... done (0ms) [foreach] reader-mime-type.xml:39: Finished http://localhost:1///samples/test/reader-mime-type/test20.html (87ms) [foreach] reader-mime-type.xml:44: Starting http://localhost:1///samples/test/reader-mime-type/test20.html [foreach] reader-mime-type.xml:46: Running test [Header: Content-type = text/html ... done (0ms) [foreach] reader-mime-type.xml:44: Finished http://localhost:1///samples/test/reader-mime-type/test20.html (32ms) [foreach] reader-mime-type.xml:50: Starting http://localhost:1///samples/test/reader-mime-type/test30.html [foreach] reader-mime-type.xml:52: Running test [Header: Content-type = text/html ... done (0ms) [foreach] reader-mime-type.xml:50: Finished http://localhost:1///samples/test/reader-mime-type/test30.html (424ms) [foreach] reader-mime-type.xml:55: Starting http://localhost:1///samples/test/reader-mime-type/test30.html [foreach] reader-mime-type.xml:57: Running test [Header: Content-type = text/html ... done (1ms) [foreach] reader-mime-type.xml:55: Finished http://localhost:1///samples/test/reader-mime-type/test30.html (86ms) [foreach] reader-mime-type.xml:61: Starting http://localhost:1///samples/test/reader-mime-type/test40.html [foreach] reader-mime-type.xml:63: Running test [Header: Content-type = text/html ... done (1ms) [foreach] reader-mime-type.xml:61: Finished http://localhost:1///samples/test/reader-mime-type/test40.html (25ms) [foreach] reader-mime-type.xml:66: Starting http://localhost:1///samples/test/reader-mime-type/test40.html [foreach] reader-mime-type.xml:68: Running test [Header: Content-type = text/html ... done (0ms) [foreach] reader-mime-type.xml:66: Finished http://localhost:1///samples/test/reader-mime-type/test40.html (27ms) [foreach] reader-mime-type.xml:72: Starting http://localhost:1///samples/test/reader-mime-type/test50.html [foreach] reader-mime-type.xml:74: Running test [Header: Content-type = text/html[1;31m Failure: file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/anteater/reader-mime-type.xml:74: message doesn't match because header 'content-type' is not present[m [foreach] ... done (7ms) [foreach] reader-mime-type.xml:72: Finished http://localhost:1///samples/test/reader-mime-type/test50.html (46ms) BUILD FAILED file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/anteater/reader-mime-type.xml:72: Task at file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/anteater/reader-mime-type.xml:72: failed Total time: 26 seconds Last messages from the server console: == [EMAIL PROTECTED]: Startup sequence initiated from main() method [EMAIL PROTECTED]: Loaded properties from [/disk/raid0/home/vadim/svn/cocoon-2.1.X/server.properties] [EMAIL PROTECTED]: Initiating startup sequence... [EMAIL PROTECTED]: Server socket opened successfully in 4 ms. [EMAIL PROTECTED]: Database [index=0, id=0, db=file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db/cocoondb, alias=] opened sucessfully in 2255 ms. [EMAIL PROTECTED]: Startup sequence completed in 2304 ms. [EMAIL PROTECTED]: 2004-12-17 01:31:31.228 HSQLDB server 1.7.3 is online [EMAIL PROTECTED]: To close normally, connect and execute SHUTDOWN SQL [EMAIL PROTECTED]: From command line, use [Ctrl]+[C] to abort abruptly - The database 'db' root directory has been set to /disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db. Keep in mind that if a war upgrade will take place the database will be lost. - Database points to /disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db - [main] '/db/system/SysSymbols' Set object system_SysConfig - [main] '/db/system/SysConfig' Set document database.xml - [main] '/db/system/SysSymbols' Set object meta_Metas - [main] '/db/system/SysSymbols' Set object meta_Metas_system_SysConfig - Database 'db' successfully opened - Xindice server successfully started parameter = @PARAMETER@ replaceme = replaceme-abc parameter = @PARAMETER@ replaceme = replaceme-123 - VM shutting down with the disk store for cocoon-ehcache-1 still active. The disk store is persistent. Calling dispose... - Database 'db' successfully closed - Scheduler Cocoon_$_Fri_Dec_17_01:31:18_PST_2004 paused. - Scheduler Cocoon_$_Fri_Dec_17_01:31:18_PST_2004 shutting down. - Scheduler Cocoon_$_Fri_Dec_17_01:31:18_PST_2004 paused
Re: Orbeon vs Cocoon? - Live version available?
[EMAIL PROTECTED] wrote:
Hi Bertrand,
I've looked at their site a few days ago and saw something mentioned about
their code being open source. Haven't looked at it further (yet).
I can't help but mention that the documentation on their website looks much
better and much more coherent than Cocoon. So this is a challenge: to get
our documentation up to speed.
Agree.
What I do like as well, and this might be
easier (as in quicker) to accomplish is the fact that they have live samples
on their website.
FYI, in their live site, they have a section that allows visitors to
type in some XSLT. As I'm a curious person, I wanted to see if/how they
protected themselves from malicious code in the XSLT. So I added a
simple call to System.exit() and... crashed their whole website!!!
As I did not expected such a result, I promptly sent them an email with
my apologizes, and they told me they would close that door. Maybe they
finally forgot to?
I often want to have a quick look at the samples, but since I've set up my
project along the YourCocoonProjectAnt16 instructions, my distro is as
lean as possible and lacking all samples. That would mean I need a second
build for the entire distribution.
It would be nice if there was a place where the latest release would be
running, so everyone could check it out. I know this requires cleaning up
the crap that some people think they should enter, but that might be done
through some simple scripts.
It would also give future users the change to have a look at Cocoon before
doing the actual download. And newbies can verify if they have done things
correctly because they can compare their own version with THE live
version.
I know server hosting will be a problem, but maybe it's running somewhere
already which could be made available to the world?
Googling for welcome to apache cocoon shows quite a few ones :-)
Seriously, that's true that we should be have a live showcase of the
latest release. This has been discussed a while ago in relation with the
VMWare installation here at Apache, but as Bertrand, I don't have any
further info on this.
For those who can read french, there has been a discussion a few weeks
ago on a list dedicated to the development of the XMLfr.org website [1].
Some experiments have been made to migrate it to Cocoon (it's currently
based on a servlet + the XT xslt processor) and OXF has been studied
also. An interesting discussion happended then between Erik Bruchez, one
of OXF's devs and myself.
Sylvain
[1] http://xmlfr.org/communautes/dev/listes/dev/2004/09/date.html
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Orbeon vs Cocoon? - Live version available?
Steven Noels wrote:
On 17 Dec 2004, at 10:13, [EMAIL PROTECTED] wrote:
It would be nice if there was a place where the latest release would be
running, so everyone could check it out. I know this requires
cleaning up
the crap that some people think they should enter, but that might be
done
through some simple scripts.
It would also give future users the change to have a look at Cocoon
before
doing the actual download. And newbies can verify if they have done
things
correctly because they can compare their own version with THE live
version.
I know server hosting will be a problem, but maybe it's running
somewhere
already which could be made available to the world?
FWIW, this has been running on cocoon.cocoondev.org for more than two
years, but I pulled it down due to lack of hits. Similarly, I will be
dropping the webmail.cocoondev.org demo soonish.
Well, lack of hits doesn't meen lack of interest, but maybe more lack of
advertising (AFAIK, these demos weren't mentioned on the Apache website).
The problem is that we've always been more or less reluctant to link
from the ASF cocoon website to resources hosted elsewhere. Even the
wiki. That's something we should fix, and a live demo with due
advertising on the website front page would certainly have more visitors.
Now for sure it would be good if it could be hosted by the ASF
infrastructure.
I had a Cocoon BOF two days ago at JavaPolis. I spoke to quite a few
folks during the conference as well, which know how we (as a company)
have been pushing people to use Cocoon over the past three years.
With all due respect, I think there's only a few things we should care
to work on to give Cocoon more chances for success. I know there were
many success stories lately, but we should be realistic as well: the
world is looking into a shift from Struts to JSF, and that's about all
they care. People still perceive Cocoon as a big, complicated, scary
beast.
Funnily, I recently had a private chat after my recent blog entry about
Struts [1] with Stephane Bailliez (Ant Maven committer) which told me
more or less the same.
Some recurring complaints were:
* documentation (oh well)
* cohesive direction (as in: _only_ explain folks about things like
the power trio, and make sure these things work flawlessly, and stop
being hesitant about deprecation and removal of alternatives)
* prune, prune, prune: make blocks separately downloadable, and drop
blocks which aren't supported nor used
* make sure people don't need a bit of everything to build a decent
Cocoon app (as in: some Actions, some Input modules, some Javascript,
some Java, a bit of CForms, a choice over various O/R efforts, some
Springkles here and there, and so on and so forth)
The last one doesn't mean people shouldn't use all this, it's just
that all this is now perceived as totally separated, isolated,
unrelated and incohesively documented stuff.
I can only agree with this.
The JBoss folks were right when they told me over drinks that Cocoon
is too much of a research project.
Yes, but that's also because of its we-don't-have-to-respect-a-JSR
nature which allows more creativity.
Just to give an example: JXTG isn't even used massively (too many
folks still stuck with XSPs), and already we start chatting about
JXTG-NG. How should users believe we actually care about them? (=
literal remark I got yesterday!)
Mmmh... JXTG-NG has a dual purpose:
- refactor the complicated code we have today into something more
maintainable. Similar to what happened in the CForms transformer
- pave the way for *the* dynamic template generator, just as CForms
deprectated XMLForm.
end-of-rant
Thanks for it :-)
Sylvain
[1] http://www.anyware-tech.com/blogs/sylvain/archives/000153.html
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: Orbeon vs Cocoon? - Live version available?
FWIW, this has been running on cocoon.cocoondev.org for more than two years, but I pulled it down due to lack of hits. Similarly, I will be dropping the webmail.cocoondev.org demo soonish. Too bad I didn't know this before. But maybe that's exactly the reason for the low hitrate: too few people knew about it and therefore too few people referred newbies to it. Some recurring complaints were: * documentation (oh well) * cohesive direction (as in: _only_ explain folks about things like the power trio, and make sure these things work flawlessly, and stop being hesitant about deprecation and removal of alternatives) * prune, prune, prune: make blocks separately downloadable, and drop blocks which aren't supported nor used * make sure people don't need a bit of everything to build a decent Cocoon app (as in: some Actions, some Input modules, some Javascript, some Java, a bit of CForms, a choice over various O/R efforts, some Springkles here and there, and so on and so forth) The last one doesn't mean people shouldn't use all this, it's just that all this is now perceived as totally separated, isolated, unrelated and incohesively documented stuff. True, from a simple user's perspective: it is difficult to figure out what the best practice currently is. I joined the Cocoon community exactly one year ago and since then have seen the rise of flow, the deprecated as best practice of XSP and multiple other major changes. Cocoon is exciting stuff and the community is wonderful. I truly believe that the community of committers and active contributers is a self-organising development team of a size that can hardly be found in any business. Something many businesses could learn from. Too bad the quality of Cocoon is obscured by the perceived complexity. I know I'm currently not contributing more than just some posts on the discussion lists, but I do hope that some of my comments spark great ideas in others that do have the time, knowledge and resources to actually do something about it. The JBoss folks were right when they told me over drinks that Cocoon is too much of a research project. Just to give an example: JXTG isn't even used massively (too many folks still stuck with XSPs), and already we start chatting about JXTG-NG. This might be a valid argument to keep the rate of new things down. How should users believe we actually care about them? (= literal remark I got yesterday!) But I don't see how this is connected. After all deprecation of old technology is done after extensive discussion on this list and then there is still support on the users list. I must confess I haven't read up on all the roadmap and cocoon's future threads, so I don't know if I now propose something that's already there. I just wonder if it is possible that those of you with in-depth knowledge of Cocoon and the way open source communities work, can investigate other major open source projects like Apache server, Mozilla/FireFox, Tomcat, JBoss for that matter and see what makes them different, better if you like. I'm not talking about documentation here. There are already steps taken in the right direction. More like: the rate of new releases, deprecation of older techniques, the number of ways to solve a problem, user support. I've seen you guys discussing this for Cocoon and coming up with rules of thumb that most of you stick too. So where are you in this when you compare this to the other major open source projects? Bye, Helma
DO NOT REPLY [Bug 32751] - Serious problem with cinclude and caching
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32751. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32751 --- Additional Comments From [EMAIL PROTECTED] 2004-12-17 14:40 --- Created an attachment (id=13771) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13771action=view) My sitemap -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[GUMP@brutus]: Project cocoon-block-template (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon-block-template has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-template : Java XML Framework Full details are available at: http://brutus.apache.org/gump/public/cocoon/cocoon-block-template/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [template-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/cocoon/cocoon-block-template/gump_work/build_cocoon_cocoon-block-template.html Work Name: build_cocoon_cocoon-block-template (Type: Build) Work ended in a state of : Failed Elapsed: 9 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=17122004 -Dblock-name=template gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
DO NOT REPLY [Bug 32751] - Serious problem with cinclude and caching
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32751. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32751 --- Additional Comments From [EMAIL PROTECTED] 2004-12-17 14:41 --- Created an attachment (id=13772) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13772action=view) My stylesheet -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32751] - Serious problem with cinclude and caching
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32751. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32751 --- Additional Comments From [EMAIL PROTECTED] 2004-12-17 14:42 --- Created an attachment (id=13773) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13773action=view) Log fragment from Cocoon 2.1.5 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[RT] Component confs per sitemap
The current solution for adding own components to Cocoon is to (optionally) add the role to the cocoon.roles file and to add the component (configuration) to the global cocoon.xconf file. What about providing the possibility to add components/roles on a per sitemap level? For example by providing a reference from within a sitemap in the map:components sections: map:components roles-file=... config-file=... .. /map:components So all of these components are available in this sitemap and in all subsitemaps. Adding this (to 2.2) should be very easy and makes adding own stuff imho easier. (As a second step - but this is independent it would be possible to move all definitions of sitemap components into these files as well, leaving just the pipelines in a sitemap). WDYT? Carsten Carsten Ziegeler Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.net/weblogs/rael/
Re: [RT] Component confs per sitemap
On Fri, Dec 17, 2004 at 03:06:20PM +0100, Carsten Ziegeler wrote: The current solution for adding own components to Cocoon is to (optionally) add the role to the cocoon.roles file and to add the component (configuration)to the global cocoon.xconf file. What about providing the possibility to add components/roles on a per sitemap level? For example by providing a reference from within a sitemap in the map:components sections: map:components roles-file=... config-file=... .. /map:components So all of these components are available in this sitemap and in all subsitemaps. Adding this (to 2.2) should be very easy and makes adding own stuff imho easier. (As a second step - but this is independent it would be possible to move all definitions of sitemap components into these files as well, leaving just the pipelines in a sitemap). WDYT? I like both ideas, because they allow more modular configuration. It seems this may also help with virtual hosting via subsitemaps? Could we allow live updates from changes made to the roles-file and config-file like we do for changes to sitemaps? --Tim Larson
Refactoring Cforms samples
Guys, Looking at the Cforms samples I notice 3 different versions of Form.js and samples based on each of them. In the light of making things easier for the ordinary users, would it be possible to settle for one of those three and refactor the other samples to use only that one? A second step would be to rearrange/rename the files to show which files belong to which sample. A third step: are all (Cforms) samples rewritten to use only Flow-JXTemplates-Cforms? Finally, does the section on Cforms include references to other samples that use Cforms? I could have a try at this, but before that I need to know which version of Form.js will be settled on. Bye, Helma
Re: Refactoring Cforms samples
[EMAIL PROTECTED] wrote: Guys, Looking at the Cforms samples I notice 3 different versions of Form.js and samples based on each of them. In the light of making things easier for the ordinary users, would it be possible to settle for one of those three and refactor the other samples to use only that one? that's what we decided in gent - see http://wiki.apache.org/cocoon/22StabilizeCocoonForms A second step would be to rearrange/rename the files to show which files belong to which sample. +1 A third step: are all (Cforms) samples rewritten to use only Flow-JXTemplates-Cforms? we should provide examples with all three possible ways: - generator - trasformer - jxmakro Finally, does the section on Cforms include references to other samples that use Cforms? I could have a try at this, but before that I need to know which version of Form.js will be settled on. v1 + http://wiki.apache.org/cocoon/22StabilizeCocoonForms Bye, Helma -- Reinhard
FYI: weird javascript function not found problems with 2.1.5
I've had a weird case where javascript functions were found without problem, and lost after a logout/login of the user, as if the flowscript-calling sitemap had suddently lost track of them. I'm documenting this here in case it rings bells for someone. I've seen this in a 2.1.5.1 app, didn't test it with 2.1.6 as the app in question needs some changes for 2.1.6. Scenario: 1.-User logs in, CForms-based editor form works 2. User logs out in another browser window, logs in again (login page uses sendPageAndWait but no CForms) 3. User tries to reload CForms-based editor form (via URL, *not* continuation), and gets a javascript: function x_y_z() not found, where x_y_z is the function called by the sitemap for this editor page, which worked in 1. Flowscript functions for the CForms-based editor page are called from the top-level application sitemap, other functions (login, logout) are called from subsitemaps. I noticed that the problem occurs right after the login page calls a continuation, via a matcher in the top-level application sitemap. Moving the continuation matcher from the top-level sitemap down to the same sitemap which generates the login page seems to fix the problem. Let me know if someone needs more detail, I haven identified the problem very precisely but it looks like a weird context thing. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Orbeon vs Cocoon? - Live version available?
On 17 Dec 2004, at 13:32, [EMAIL PROTECTED] wrote: I just wonder if it is possible that those of you with in-depth knowledge of Cocoon and the way open source communities work, can investigate other major open source projects like Apache server, Mozilla/FireFox, Tomcat, JBoss for that matter and see what makes them different, better if you like. I'm not talking about documentation here. There are already steps taken in the right direction. More like: the rate of new releases, deprecation of older techniques, the number of ways to solve a problem, user support. I've seen you guys discussing this for Cocoon and coming up with rules of thumb that most of you stick too. So where are you in this when you compare this to the other major open source projects? Easy (IMHO): Cocoon is blessed and cursed by the fact that it's one of the very few factual bazaar projects I know, the Apache HTTPD server being another one. HTTPD is lucky that they only have to implement the HTTP spec (quite an understatement), where as Cocoon must (a) set its course, and (b) isn't driven by the energy of a single visionary (anymore, and for quite some time now). If Cocoon would be owned by a smaller set of contributors, it might be easier to establish a clear vision and set of goals, a directed drive for the project, but also the danger that other contributors are alienated. As of currently, I think what worries me most is alienation of the user community. I must say I don't know many projects where the ratio of developers vs users is comparable to Cocoon's - which means (IMHO) that you almost need to be a Cocoon dev before you can actually use the product. That's asking too much patience from a user who isn't interested in framework, but wants to build business applications instead. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Refactoring Cforms samples
Le 17 déc. 04, à 15:18, [EMAIL PROTECTED] a écrit : ...In the light of making things easier for the ordinary users, would it be possible to settle for one of those three and refactor the other samples to use only that one?... +1, and maybe mark the other Form.js files as deprecated in some way (comments in the source code, note on the samples page, etc.). ...A second step would be to rearrange/rename the files to show which files belong to which sample... You mean creating separate directories for each sample? Yes, sounds good. ...A third step: are all (Cforms) samples rewritten to use only Flow-JXTemplates-Cforms?.. Makes sense. Finally, does the section on Cforms include references to other samples that use Cforms? Not sure if I understand the question, but the tour block includes a CForms sample as well, the bean editor application. You might want to add a link or notice about it on the CForms samples page. I could have a try at this, but before that I need to know which version of Form.js will be settled on. Great! -Bertrand smime.p7s Description: S/MIME cryptographic signature
RE: [RT] Component confs per sitemap
Tim Larson wrote: I like both ideas, because they allow more modular configuration. It seems this may also help with virtual hosting via subsitemaps? I think so, yes. Could we allow live updates from changes made to the roles-file and config-file like we do for changes to sitemaps? Sure. Carsten
Re: FYI: weird javascript function not found problems with 2.1.5
Bertrand Delacretaz wrote: I've had a weird case where javascript functions were found without problem, and lost after a logout/login of the user, as if the flowscript-calling sitemap had suddently lost track of them. I'm documenting this here in case it rings bells for someone. I've seen this in a 2.1.5.1 app, didn't test it with 2.1.6 as the app in question needs some changes for 2.1.6. Scenario: 1.-User logs in, CForms-based editor form works 2. User logs out in another browser window, logs in again (login page uses sendPageAndWait but no CForms) 3. User tries to reload CForms-based editor form (via URL, *not* continuation), and gets a javascript: function x_y_z() not found, where x_y_z is the function called by the sitemap for this editor page, which worked in 1. Flowscript functions for the CForms-based editor page are called from the top-level application sitemap, other functions (login, logout) are called from subsitemaps. I noticed that the problem occurs right after the login page calls a continuation, via a matcher in the top-level application sitemap. Moving the continuation matcher from the top-level sitemap down to the same sitemap which generates the login page seems to fix the problem. Let me know if someone needs more detail, I haven identified the problem very precisely but it looks like a weird context thing. -Bertrand try using rhino_1.6 from trunk - should be binary compatible -- Reinhard
Re: [RT] Component confs per sitemap
Carsten Ziegeler wrote: The current solution for adding own components to Cocoon is to (optionally) add the role to the cocoon.roles file and to add the component (configuration) to the global cocoon.xconf file. What about providing the possibility to add components/roles on a per sitemap level? For example by providing a reference from within a sitemap in the map:components sections: map:components roles-file=... config-file=... .. /map:components So all of these components are available in this sitemap and in all subsitemaps. Adding this (to 2.2) should be very easy and makes adding own stuff imho easier. (As a second step - but this is independent it would be possible to move all definitions of sitemap components into these files as well, leaving just the pipelines in a sitemap). WDYT? There was a discussion on this very topic (with pretty much the same proposal) here while you were on vacation. However, as I recall it was under one of the topics that I believe you deleted. :-) You just can't go on vacation anymore! I love the idea - especially moving the component definitions into the xconf file. Small sitemap files are good. Ralph
RE: Refactoring Cforms samples
that's what we decided in gent - see http://wiki.apache.org/cocoon/22StabilizeCocoonForms Oops, didn't look at that before. OTOH it might be me, but I cannot figure out where it says that Form.js v1 is decided on. I know I've seen a discussion once on which version of Form.js does what, but I cannot find it. Does anyone have some URLs? we should provide examples with all three possible ways: - generator - trasformer - jxmakro Generator and transformer +1, but what's the difference with jxmacro? In my opinion it's a kind of subroutine or library kind of functionality that could be used with either a generator or a transformer. Or did I miss something? Thinking about this, I think the samples should also be extended to clearly show all kinds of features, like widget states, dynamic updates to widgets or forms (along the lines of the dynamic repeater, the tasktree sample and the dreamteam sample). And maybe the form gui builder could be turned into a more wizard-like application which finishes with the three files that are needed to build a Cform page. Finally, does the section on Cforms include references to other samples that use Cforms? I could have a try at this, but before that I need to know which version of Form.js will be settled on. v1 + http://wiki.apache.org/cocoon/22StabilizeCocoonForms Is this wiki page updated to reflect the latest state of implementation? Bye, Helma
Re: trunk doesn't run - GroovyInterpreter not found.
Ralph Goers wrote: I updated trunk and then did a clean and build. I then started cocoon and tried to access the sample site. It failed with a ClassNotFound exception during initialization. It looks like it is still being configured into cocoon.xconf. yepp, sorry about that ...fixed cheers -- Torsten
Re: Refactoring Cforms samples
On 17.12.2004 15:44, [EMAIL PROTECTED] wrote: that's what we decided in gent - see http://wiki.apache.org/cocoon/22StabilizeCocoonForms Oops, didn't look at that before. OTOH it might be me, but I cannot figure out where it says that Form.js v1 is decided on. I know I've seen a discussion once on which version of Form.js does what, but I cannot find it. Does anyone have some URLs? IIRC this has been in Gent on the white board. we should provide examples with all three possible ways: - generator - trasformer - jxmakro Generator and transformer +1, but what's the difference with jxmacro? In my opinion it's a kind of subroutine or library kind of functionality that could be used with either a generator or a transformer. Or did I miss something? You can use the FormsGenerator, the FileGenerator + the FormsTransformer or the JXTemplateGenerator with activated JXMacros. So you have three different things. Joerg
Re: [RT] Component confs per sitemap
Carsten Ziegeler wrote: . What about providing the possibility to add components/roles on a per sitemap level? Where do I sign? 8-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Component confs per sitemap
Le 17 déc. 04, à 15:06, Carsten Ziegeler a écrit : ...map:components roles-file=... config-file=... .. /map:components So all of these components are available in this sitemap and in all subsitemaps. Adding this (to 2.2) should be very easy and makes adding own stuff imho easier... Sounds great, +1! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Orbeon vs Cocoon? - Live version available?
Steven Noels wrote: snipAs of currently, I think what worries me most is alienation of the user community. I must say I don't know many projects where the ratio of developers vs users is comparable to Cocoon's - which means (IMHO) that you almost need to be a Cocoon dev before you can actually use the product. That's asking too much patience from a user who isn't interested in framework, but wants to build business applications instead. /Steven Well stated. /ed
DO NOT REPLY [Bug 32751] - Serious problem with cinclude and caching
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32751. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32751 --- Additional Comments From [EMAIL PROTECTED] 2004-12-17 14:38 --- Created an attachment (id=13769) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13769action=view) This is document A -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32751] - Serious problem with cinclude and caching
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32751. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32751 --- Additional Comments From [EMAIL PROTECTED] 2004-12-17 14:39 --- Created an attachment (id=13770) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13770action=view) This is document B -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32751] - Serious problem with cinclude and caching
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32751. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32751 --- Additional Comments From [EMAIL PROTECTED] 2004-12-17 14:43 --- Created an attachment (id=13774) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13774action=view) Log fragment from Cocoon 2.1.6 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Orbeon vs Cocoon? - Live version available?
Steven Noels wrote: On 17 Dec 2004, at 10:13, [EMAIL PROTECTED] wrote: It would be nice if there was a place where the latest release would be running, so everyone could check it out. I know this requires cleaning up the crap that some people think they should enter, but that might be done through some simple scripts. It would also give future users the change to have a look at Cocoon before doing the actual download. And newbies can verify if they have done things correctly because they can compare their own version with THE live version. I know server hosting will be a problem, but maybe it's running somewhere already which could be made available to the world? FWIW, this has been running on cocoon.cocoondev.org for more than two years, but I pulled it down due to lack of hits. Similarly, I will be dropping the webmail.cocoondev.org demo soonish. I had a Cocoon BOF two days ago at JavaPolis. I spoke to quite a few folks during the conference as well, which know how we (as a company) have been pushing people to use Cocoon over the past three years. With all due respect, I think there's only a few things we should care to work on to give Cocoon more chances for success. I know there were many success stories lately, but we should be realistic as well: the world is looking into a shift from Struts to JSF, and that's about all they care. People still perceive Cocoon as a big, complicated, scary beast. Some recurring complaints were: * documentation (oh well) * cohesive direction (as in: _only_ explain folks about things like the power trio, and make sure these things work flawlessly, and stop being hesitant about deprecation and removal of alternatives) * prune, prune, prune: make blocks separately downloadable, and drop blocks which aren't supported nor used * make sure people don't need a bit of everything to build a decent Cocoon app (as in: some Actions, some Input modules, some Javascript, some Java, a bit of CForms, a choice over various O/R efforts, some Springkles here and there, and so on and so forth) The last one doesn't mean people shouldn't use all this, it's just that all this is now perceived as totally separated, isolated, unrelated and incohesively documented stuff. I consider myself a researcher, at times a scientists, at times I considered myself an artist wanna-be (but then I go to museums and realize how much there is to get ther), but I never ever thought I was a project manager. Nor I want to become one. The day cocoon stops being what it is and starts to go after J2EE and .NET is the day I kiss you goodbye. Can we have better docs? sure. Can we prune and deprecate? you bet. Can we make separate module available externally? yeah! Should we? most definately! The JBoss folks were right when they told me over drinks that Cocoon is too much of a research project. You say this as all the above lacks were a *result* of the fact that we are not afraid of innovate. I'm sorry but this is just pure and ultimate bullshit. Just to give an example: JXTG isn't even used massively (too many ' folks still stuck with XSPs), and already we start chatting about JXTG-NG. How should users believe we actually care about them? (= literal remark I got yesterday!) JXTG isn't used massively because we were not sure *which one* of the various template systems we have should become *the one* since there is no one that has all the benefits and none of the drawbacks. What we are doing, Steven, is not screwing people over a silly itch to change where there is no need to it... we don't change interfaces around because their names are not polished (like avalon did, several times)... what we are doing is not JXTG-NG but it's an agreement on the road to a unified, coherent, documented and community-proposed CTemplates solution, that would solve all the above issues. I don't know what you answered to that guy (nor I care, honestly) but blaming lack of coherence on the fact that cocoon is a research project is pure nonsense. You can say that cocoon behaves differently from other projects... and you would be true (there will be social studies published that show this!) and that the rate of turn-over and innovation in cocoon is unseen in the majority of the projects out there (and might result in a sense of moving target, this is correct). But if any of you think that the nature of the above is *harming* rather than helping, I think you are not only blind but you're biting the hands that feeds you. -- Stefano, wondering what is Steven's special talent that allows him to piss me off in just three paragraphs ;-)
Cocoon, a Huge, Scary Beast? (was: Re: Orbeon vs Cocoon? - Live version available?)
Steven Noels wrote: snip/ I had a Cocoon BOF two days ago at JavaPolis. I spoke to quite a few folks during the conference as well, which know how we (as a company) have been pushing people to use Cocoon over the past three years. With all due respect, I think there's only a few things we should care to work on to give Cocoon more chances for success. I know there were many success stories lately, but we should be realistic as well: the world is looking into a shift from Struts to JSF, and that's about all they care. Or at least the _Java_ world ;) I think that one of the reasons that Cocoon is complex is that part of the developer community has a Java centric view and other parts of the community has a XML centric view. And the perception of what is a nice and elegant solution of a certain usecase, often differ between the two groups. People still perceive Cocoon as a big, complicated, scary beast. And IMHO they are right. I think we spend much more effort in making complicated things possible than in making simple things simple. That might be a natural result of gathering higly competent developers, but neither the less, the threshold for start using Cocoon is rather high. I found the Orbeon tutorial http://www.orbeon.com/ois/doc/pages/Tutorial.pdf, rather interesting. Not that I necesarilly agreed with their solutions. But it seemed that simple things actually where simple to achieve. I think that a basic Cocoon tutorial that describe our _prefered_ way of doing basic stuff is what we most of all lack in our documentation. Maybe we could start from the supersonic tour. There are several advantages on having an _official_ basic tutorial: * We have to decide what the basic use cases for Cocoon are. * We have to decide what _the_ prefered way of doing a certain thing is. * We would (hopefully) feel motivated to make the things in the tutorial as simple to achieve as possible. Some recurring complaints were: * documentation (oh well) * cohesive direction (as in: _only_ explain folks about things like the power trio, and make sure these things work flawlessly, and stop being hesitant about deprecation and removal of alternatives) * prune, prune, prune: make blocks separately downloadable, and drop blocks which aren't supported nor used Yes, I think its time to stop waiting for the real blocks. They are no doubt important and I very much apriciate Reihard's effort in making them happen. But IMO blocks are not only about technology its much more about how we organize our work. And we can start to work on the organizational issues right away. IMO we should create a block directory directly under cocoon in svn, with the sub directories: * supported/stable, * supported/unstable and * unsupported, (for the detailed structure I'm certain that Reinhard had a much better idea, my main message is the supported, unsupported dimension). Next we put all of our blocks in the unsupported directory. Then if someone feel that a block actually should be supported by us as a community he/she has to start a vote about it. And during such a vote I think that we should be carfull about if we are +0 or +1 about a block, i.e. if we are mearly positive about it or if we actually are going to support it. Also we should make an evaluation of the core components in generation, transformer etc, some of might really be core but many of them are there because they where written before the block system or because they are percieved to small for being part of a block or because no one have cared enough. Moving all the blocks outside the trunk might complicate things in the short term, but I think that it is necessary that we decide what we are going to support as a community. Then some of the blocks might become sub projects in their own right. It will also make us more motivated in working on the tools for block handling. * make sure people don't need a bit of everything to build a decent Cocoon app (as in: some Actions, some Input modules, some Javascript, some Java, a bit of CForms, a choice over various O/R efforts, some Springkles here and there, and so on and so forth) Exactly, we could create a minimal Cocoon distro with just core and the supported stuff (or even a base subset of the suported stuff). The last one doesn't mean people shouldn't use all this, it's just that all this is now perceived as totally separated, isolated, unrelated and incohesively documented stuff. The JBoss folks were right when they told me over drinks that Cocoon is too much of a research project. It is all about community I would be supprised if I'm the only one who joined the community, not only because I needed an XML based web framework, but also as I enjoyed Stefano's and others RTs. Being partly a research project is not only one of Cocoon's main problems it is also one of its main strenghs. In short: if it wasn't partly a research project, both the community and the project would be
RE: [RT] Component confs per sitemap
Ralph Goers wrote: There was a discussion on this very topic (with pretty much the same proposal) here while you were on vacation. Ups. However, as I recall it was under one of the topics that I believe you deleted. :-) Yepp...[sound of Carsten whistling]... You just can't go on vacation anymore! :) Ok, I just reread the thread you're refering to and it seems to me that noone was against it, right? So does anyone mind if I just implement it? Carsten I love the idea - especially moving the component definitions into the xconf file. Small sitemap files are good. Ralph
[RT] CForms Triage/Staging in Whiteboard
Should we svn copy cocoon forms into the whiteboard to create a triage/staging area for (large, controversial) cforms ideas. This would allow us to try out ideas with code, rather than just with talk, before user support would become an issue. Any ideas which prove themselves and are accepted would be moved into the svn trunk for polishing before being added to a release. Examples of code I would plan on adding for discussion: Importable macros for bindings, models, and templates. First-class support for multiple bindings per form. Template code for walking x widget trees in parallel. WDYT? --Tim Larson PS: This idea (or a seed for it) was suggested by Sylvain previously, and over time I have started to warm up to it. It is OK to admit when I was wrong, right? :)
Re: Orbeon vs Cocoon? - Live version available?
Le 17 déc. 04, à 15:34, Steven Noels a écrit : ...As of currently, I think what worries me most is alienation of the user community. I must say I don't know many projects where the ratio of developers vs users is comparable to Cocoon's - which means (IMHO) that you almost need to be a Cocoon dev before you can actually use the product. That's asking too much patience from a user who isn't interested in framework, but wants to build business applications instead.. I understand and share your worries but - do you really think one can build a serious application with Cocoon without having at least one skilled java/xslt programmer and integrator (like someone who knows a little about a lot of things) on the team? I've come to the conclusion this year that having these skills in the team (even if it's just one senior developer) is a prerequisite once you go beyond simple read-only publishing applications. Which means: no need to dumb down Cocoon IMO, but rather communicate precisely about what it is and who it is for. People will be thankful if they fail early instead of wasting their time, or if they realize early on that they need certain skills in their team to reach the high productivity levels that Cocoon enables. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Orbeon vs Cocoon? - Live version available?
Steven Noels wrote: On 17 Dec 2004, at 13:32, [EMAIL PROTECTED] wrote: I just wonder if it is possible that those of you with in-depth knowledge of Cocoon and the way open source communities work, can investigate other major open source projects like Apache server, Mozilla/FireFox, Tomcat, JBoss for that matter and see what makes them different, better if you like. I'm not talking about documentation here. There are already steps taken in the right direction. More like: the rate of new releases, deprecation of older techniques, the number of ways to solve a problem, user support. I've seen you guys discussing this for Cocoon and coming up with rules of thumb that most of you stick too. So where are you in this when you compare this to the other major open source projects? Easy (IMHO): Cocoon is blessed and cursed by the fact that it's one of the very few factual bazaar projects I know, the Apache HTTPD server being another one. HTTPD is lucky that they only have to implement the HTTP spec (quite an understatement), where as Cocoon must (a) set its course, and (b) isn't driven by the energy of a single visionary (anymore, and for quite some time now). If Cocoon would be owned by a smaller set of contributors, it might be easier to establish a clear vision and set of goals, a directed drive for the project, but also the danger that other contributors are alienated. As of currently, I think what worries me most is alienation of the user community. I must say I don't know many projects where the ratio of developers vs users is comparable to Cocoon's - which means (IMHO) that you almost need to be a Cocoon dev before you can actually use the product. That's asking too much patience from a user who isn't interested in framework, but wants to build business applications instead. The above, as weird as it seems to many, has been intentional (on my part) so far, because a higher bar increases the fact that the people that can actually climb that bar are far more likely to give back than just free ride. The low users/dev ratio also indicates that the amount of energy that comes back is a lot more than what we give away, making the project healthy and the momentum going, even without big outside marketing. I still think it's a mistake to prepare a more ambitious marketing strategy without real blocks. It is also a *huge* mistake to measure the success of an open source project with numbers such as users or deployed installations. It is also stupid to think that a project is better off with more users... if all those users do is to drain energy from the project. It is also silly to believe in the sillogism that the more people out there use cocoon the more profiting the market around cocoon is going to be. It is also stupid to think that we are able to absorb, as a community, a radical change in marketing direction without falling apart. Let's just fix what's broken and move on from there. -- Stefano.
RE: [RT] Component confs per sitemap
Carsten Ziegeler said: Ok, I just reread the thread you're refering to and it seems to me that noone was against it, right? So does anyone mind if I just implement it? Carsten Are you done yet? (That's a big +1). Also, once you have this working it would be nice to see if it could be back-ported to 2.1 in a compatible manner. Ralph
DO NOT REPLY [Bug 32157] - [PATCH] redirect to relative urls does not work correctly in Websphere 5.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32157. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32157 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2004-12-17 20:09 --- It looks like I might be experiencing a similar problem under Tomcat. We use a proxy in front and the redirects are causing problems. I will probably implement something along the lines of your suggestion. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
Re: [RT] Component confs per sitemap
Carsten Ziegeler wrote:
The current solution for adding own components to Cocoon is to (optionally)
add the role to the cocoon.roles file and to add the component
(configuration)
to the global cocoon.xconf file.
What about providing the possibility to add components/roles on a per
sitemap
level? For example by providing a reference from within a sitemap in the
map:components sections:
map:components roles-file=... config-file=...
..
/map:components
So all of these components are available in this sitemap and in all
subsitemaps.
Adding this (to 2.2) should be very easy and makes adding own stuff imho
easier.
(As a second step - but this is independent it would be possible to move all
definitions of sitemap components into these files as well, leaving just the
pipelines in a sitemap).
WDYT?
+1. You already can put any component declaration in map:components,
so it's actually just a matter of reading this declaration in an
external file.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [RT] Component confs per sitemap
Ralph Goers wrote: Carsten Ziegeler said: Ok, I just reread the thread you're refering to and it seems to me that noone was against it, right? So does anyone mind if I just implement it? Carsten Are you done yet? (That's a big +1). No, I'm currently rewriting/cleaning up parts of ECM++ and when that is done, I will start with the configuration stuff. I hope to get everything finished before xmas. Also, once you have this working it would be nice to see if it could be back-ported to 2.1 in a compatible manner. Yeah, this should be possible, but my opinion is that it should just go into 2.2 as it is kind of a major addition. That's just my opinion, so if the majority is for 2.1 I'm fine with it. But let'S just get it running in 2.2 and then see what we do about it. Carsten
RE: [RT] Component confs per sitemap
Sylvain Wallez wrote: +1. You already can put any component declaration in map:components, :( You know my opinion about ;) so it's actually just a matter of reading this declaration in an external file. Yes, with the additional that this is then *official* and *supported* :) Carsten
Increasing Cocoon's mind share (was Orbeon vs Cocoon? - Live version available?)
On Dec 17, 2004, at 8:34 AM, Steven Noels wrote: As of currently, I think what worries me most is alienation of the user community. I must say I don't know many projects where the ratio of developers vs users is comparable to Cocoon's - which means (IMHO) that you almost need to be a Cocoon dev before you can actually use the product. That's asking too much patience from a user who isn't interested in framework, but wants to build business applications instead. What do you see as a possible solution to this problem? I think before we can even begin to solve this problem we have to understand who cocoon users currently are, what they want and wether they are really the target audience of the work being done. Below is some personal opinion and speculation concerning Cocoon, its user community and shifting paradigms. I think a survey of actual users would be interesting and I am considering putting one together. On the other hand I think making the distinction between users and developers when it comes to putting together web applications is a little silly, since anyone who is putting together a unique business application is a developer. A user would be someone who configures an existing web application to meet their particular needs. If you read below this please realize that I have only observed this community for the past 9 months and what history I know is second hand. In its simplest form Cocoon is indeed a server side application capable of producing simple sites where data and presentation can be completely separated. Such sites can be designed and implemented by your average webmaster. With a little bit of SQL and/or Java knowledge they can create dynamic sites. In the hands of a more advanced user, Cocoon is a framework/platform that allows a much more powerful business application to be built using a MVC pattern. The more complex your application is, the more advanced a user of the framework you must be. No doubt the webmaster who was able to cobble together his site with Cocoon a year ago using the Authentication Framework and ESQL would be hard pressed to implement it today using Java, Hibernate, CForms and Flowscript. However, nothing stops him from implementing it the exact same way today as he did a year ago. I, on the other hand, as an application designer/developer have a lot more flexibility then I had a year ago. I can achieve a true separation of concerns in a much simpler and obvious way. Having said that, the hard part of a web facing business application is the business model and logic. Presentation has been simplified a great deal over the years. Mediating between the presentation and the model and controlling application workflow have been much more difficult then they should have been. Flow is about the simplest way I have run across to mediate between the model and the view. On the other hand I'm not real crazy about CForms (or any forms handling framework at the moment). I find it to be overly complex for my needs. If anything, I think on the whole, the advances made in cocoon have made things simpler from my perspective as a developer. So maybe I'm not a user, maybe I'm a developer who's only written sitemap components to see how its done and once in a misguided attempt to integrate a store directly into cocoon. (why did I ever try such a thing? buy me a beer. my embarrassment has a price ;-).) There has been a small paradigm shift in the recommended way sites should be built with cocoon. The shift has come as a result of the desire to put more complex applications on our sites and to find better ways to manage that complexity. Unfortunately, complexity is hardly ever removed but is usually shifted somewhere else. The shift in Cocoon seems to have been towards the users. By that I mean that it is the users responsibility to code or program pieces of application functionality as opposed to relying on the Cocoon developer comunity. This has left some users feeling abandoned. To some extent thats true, the developers will not be spending time writing Actions, they are assuming that users will be able to achieve the same results in a much more direct manner through using flow. Unfortunately, flow requires programming, not simply making an entry in the sitemap. Imagine what a poor webmaster must do to authenticate a user using flow as opposed to the just using map:act type=auth-login. (this is just an example of switching from Actions to flow, I know the Action could still be used) Likewise, having to get data from the database directly using flow, rather then using ESQL and XSP requires a lot more of the user. This shift makes it much more likely that a developer will be needed to create a web app. The user community is shifting more towards the developer community. Cocoon is becoming more of a framework/platform then an application. The mind share that needs to be gained is that of web developers, those that
Templating: asking the right questions
Glen's prior message was eerily similar to the one below, which has been rolling around in my head for a while. JX strikes me as a powerful, though low-level feature. Users don't go around saying what can I temaplate today?. They have higher-level concerns. If they need to, they'll resort to templating, but it's a tool, not a solution. So, I'm happy to see refactoring work on JX, but I wonder if there's more we could do. So, what kinds of high-level tasks are users using templating for? And how can we more naturally help them get this done? .micah
Re: Orbeon vs Cocoon?
FYI, the Orbeon stuff is LGPL since about September. http://www.orbeon.com/company/pr-oss-announcement .micah Bertrand Delacretaz wrote: Dunno what the OXF license is today, at the time it was closed. The Wayback Machine helps if their website is down: http://web.archive.org/web/*/http://www.orbeon.com
DO NOT REPLY [Bug 32762] New: - [PATCH] flow redirector should allow explicit 'cocoon:' scheme
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32762. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32762 Summary: [PATCH] flow redirector should allow explicit 'cocoon:' scheme Product: Cocoon 2 Version: Current SVN 2.1 Platform: Macintosh OS/Version: Mac OS X 10.0 Status: NEW Severity: normal Priority: P2 Component: Flowscript AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Prohibiting an explicit scheme unduly disallows the valid use of colons in the scheme-specific portion of the URI. With this patch, an explicit 'cocoon:' scheme is allowed, which permits URIs such as cocoon:/something:foo/bar. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 32762] - [PATCH] flow redirector should allow explicit 'cocoon:' scheme
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32762. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32762 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |minor -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Orbeon vs Cocoon? - Live version available?
On 17 Dec 2004, at 17:07, Stefano Mazzocchi wrote: snip/ Uhm, like, yeah, like... sigh. Oh whatever. I've grown out of this. -- Stefano, wondering what is Steven's special talent that allows him to piss me off in just three paragraphs ;-) Reading your reply? No idea, actually. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
