Re: [GT2005] Presentations and Audio Now Available
Le 10 oct. 05, à 23:04, Agile Jack a écrit : ...Thanks to Arje and others from Hippo for a well-run event, and to the presenters for great content... And big thanks to you for the recordings and quick publishing, this adds a lot of value to the event! -Bertrand
Re: Jira or Bugzilla...
Le 11 oct. 05, à 00:59, Pier Fumagalli a écrit : ...So, who is against switching to Jira?... I'm all for it, especially if you do the work ;-) Thanks for driving this. -Bertrand
[VOTE] new committer: Max Pfingsthorn
Dear community, Several of us share the thought that Max is the perfect example of a GSoC success: apart from great technical work, he's quickly found his place in our community, with regular contributions in code and on the lists. His presentation at last week's GT has shown a high level of understanding of CForms and of Cocoon at large. What he's done with the forms libraries is definitely not just a student work, it is solid stuff. (and besides that, it will be cool to have more people with difficult names to type ;-) So I have the pleasure of proposing Max as our new committer! Please cast your votes, here's mine: +1 -Bertrand
DO NOT REPLY [Bug 37008] - style sheet directed termination
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=37008. 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=37008 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-10-11 08:37 --- This stylesheet directed termination message typically indicates that the XSLT processor could not do its job correctly. Either because the XSL is invalid, or because there's a problem in the data it is given to process. Please check the logs where you should find more explanations. Also you should really ask this kind of questions on the user list rather than creating bugs. -- 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: [VOTE] new committer: Max Pfingsthorn
On 11 Oct 2005, at 08:28, Bertrand Delacretaz wrote: So I have the pleasure of proposing Max as our new committer! +1 /Steven -- Steven Noelshttp://outerthought.org/ Outerthought Open Source Java XML stevenn at outerthought.orgstevenn at apache.org
Re: [VOTE] new committer: Max Pfingsthorn
Bertrand Delacretaz wrote: So I have the pleasure of proposing Max as our new committer! +1
Re: [VOTE] new committer: Max Pfingsthorn
Bertrand Delacretaz bdelacretaz at apache.org writes: So I have the pleasure of proposing Max as our new committer! +1 Jörg
Re: [VOTE] new committer: Max Pfingsthorn
Bertrand Delacretaz wrote: Please cast your votes, here's mine: +1 Jorg
Re: [VOTE] new committer: Max Pfingsthorn
Bertrand Delacretaz wrote: Dear community, Several of us share the thought that Max is the perfect example of a GSoC success: apart from great technical work, he's quickly found his place in our community, with regular contributions in code and on the lists. His presentation at last week's GT has shown a high level of understanding of CForms and of Cocoon at large. What he's done with the forms libraries is definitely not just a student work, it is solid stuff. (and besides that, it will be cool to have more people with difficult names to type ;-) So I have the pleasure of proposing Max as our new committer! Please cast your votes, here's mine: +1 +1 -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [VOTE] new committer: Max Pfingsthorn
On 10/11/05, Bertrand Delacretaz [EMAIL PROTECTED] wrote: So I have the pleasure of proposing Max as our new committer! +1, welcome Max! Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [VOTE] new committer: Max Pfingsthorn
So I have the pleasure of proposing Max as our new committer! +1 Bye, Helma
Re: [VOTE] new committer: Max Pfingsthorn
Il giorno 11/ott/05, alle ore 08:28, Bertrand Delacretaz ha scritto: So I have the pleasure of proposing Max as our new committer! Please cast your votes, here's mine: +1 +1 Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [VOTE] new committer: Max Pfingsthorn
Bertrand Delacretaz wrote: So I have the pleasure of proposing Max as our new committer! A warm +1! Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
[Docs] Articles on Cocoon
Hi, this is both a notification and some requests. During the GT I've asked several people in the community to write an article on an aspect of Cocoon. The intention is to get a series of a few articles and have them published in an (online) magazine or other relevant site to promote/expose Cocoon. The intended readers are: - those unfamiliar with Cocoon/those that think Cocoon is only suitable for small, almost static websites. - those that are familiar with Cocoon and run into a similar problem. So the article should not be too technical, but give enough information to help the readers in the second group to find more information. Given the target group the articles should not be too long, certainly not more than 5 pages, probably less. So far I've been promised: - Cocoon and large websites by Pier and Ross McDonald, focus on performance issues - Cocoon and security by Ralph, focus on security issues in internet banking - Cocoon and AJAX by Sylvain, focus on how easy it is in Cocoon - Cocoon and performance by Jack Ivers and Vadim, focus on a comparison of XSLT processors - Cocoon and CMS by Steven, focus on the role/advantages of Cocoon in Daisy Requests: - are there more people willing to contribute articles that could fit this series? - what would be the most interesting site/magazine to get this series published? I intend to get them up on our documentation site as well, just have to figure out what the most effective publishing schedule is. Bye, Helma
Re: [QVote] Configurable default for sitemap reloading
Torsten Curdt wrote: I still think turning it off is FS ...but anyway :) Now the funny thing is, that someone at the GT said (can't remember who it was) that we are really good in not allowing things :) And sometimes we are even better in making things more complicated as they need to be. Absolutely true :) Whatever guys... quick vote - quick answer: -0 :) Thanks Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [VOTE] new committer: Max Pfingsthorn
So I have the pleasure of proposing Max as our new committer! +1 cheers -- Torsten PGP.sig Description: This is a digitally signed message part
RE: [VOTE] new committer: Max Pfingsthorn
So I have the pleasure of proposing Max as our new committer! My first vote.. Happy to send it to you, Max :-) +1
RE: [VOTE] new committer: Max Pfingsthorn
So I have the pleasure of proposing Max as our new committer! +1 Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
Re: [QVote] Configurable default for sitemap reloading
Carsten Ziegeler wrote: Torsten Curdt wrote: I know :) But we already delay the checking and therefor heavily reduce the native filesystem checks ...and I was just playing devil's advocate here. So how many people (despite Carsten) are actually using it? I still think turning it off is FS ...but anyway :) Now the funny thing is, that someone at the GT said (can't remember who it was) that we are really good in not allowing things :) I don't think it's FS, it's a simple switch. A check costs time, even delayed it still costs time, so why not turning them off to avoid this? And users will feel happy, they will say: Look, in 2.2 you can turn off all the reloading for production with one simple switch. Isn't this great? :) I see another advantage to this: finally write this source-cache thing, which will avoid components to have their own private caches that aren't friendly with the server's memory as old items are not flushed when memory gets low. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
RE: [Docs] Articles on Cocoon
- Cocoon and CMS by Steven, focus on the role/advantages of Cocoon in Daisy Darn, Steven, you got me there. I'd be happy to write a piece about knowledge sharing in intranets or on the web. Generating relationships, using team folders, finding articles, using thesauri and taxonomies, etc. Practical stuff that really adds value, no fuzzy knowledge management buzz. Also not about Wiki's (I'll leave that one to Steven ;) ). WDYT?
Re: XULifying CForms (yet another attempt?)
On 10/10/05, Stefano Mazzocchi [EMAIL PROTECTED] wrote: I've been working heavily with XUL recently and I have to say, it could be a refreshing experience if you were used to build DHTML applications. At the same time, be aware that XUL is normally used inside the mozilla security sandbox (say, loaded with chrome:// instead of being loaded with http:// or file://), things change rather dramatically when you use remote XUL (as it is called when you load XUL from http:// as opposed to local XUL. From what I reckon, the security sandbox shouldn't be that much of an issue when dealing just with forms with no access to local resources. Things of course would change when it comest to mangling with the user's station, such as writing files or opening socket connections to different hosts, but it shouldn't be different from applets, to say the least. As far as XBL goes, I would suggest to start without and see how far you can keep going without it (which, for me, is pretty far since I'm not developing reusable UI widgets) Then again, a good lot of CForms is about reusable UI widgets, which makes me think that we'll need XBL pretty soon. Is there a reason to be scared though? I don't quite find XBL, in its simplest incarnations, a daunting technology: if you use it as a poor's man XSLT/macro processor it's more or less a piece of cake. I agree, though, on staying away from overcomplication as much as we can. As for as XHTML, XUL does *NOT* replace XHTML, in fact, you can consider it as an extension to it. There are things that are, IMO, but better than in XHTML (the vbox/hbox/flex model, for example, *WAY* better than the stinking table/tr/td or even better than the CSS3 column layouts) but some XUL widgets are nothing but reusable XHTML constructs with embedded style and behavior (and that's why XBL is related to CSS, you can think if XBL as an extension to CSS to make behavior portable and isolated.. too bad they got the syntax wrong, the use of the XML for XBL is a total golden hammer instance if you ask me) rant Now, call me an old fart, but I don't quite like the continuous and oh-so-fashionable XML bashing I see nowadays. Clearly, writing angle brackets all over the place isn't the most comfortable way of working, but as long as I will be able to (per)use transformations so that I will be able to generate an application using just an XSL stylesheet from a model, I'll be an happy puppy. I just wish we had a (successful) alternate syntax to avoid the carpal tunnel syndrome, yet XSLT/XPath/validations and friends are just too powerful technologies that make me easily fogive input verbosity. /rant As far as roundtripping, Ajax all over the place is the only reasonable answer, IMO... be aware that this makes browser history and bookmarking an interesting problem. Yup, my point exactly. One of the first problems to dissect is how CForms can go from a navigation based framework to a real GUI, where navigation happens locally and it's calculated (mostly) on the client. This is my first and foremost concern and at times I have the feeling that Xul in CForms will have to remain a pure translation of html interfaces (as in s/\.html/\.xul/g). Not a big deal after all. At the same time, browsers are *NOT* build with that in mind and remote XUL cannot prevent the users from clicking the back button Well, this is where continuation should help us. At least possibly. :-) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [QVote] Configurable default for sitemap reloading
Sylvain Wallez wrote: I see another advantage to this: finally write this source-cache thing, which will avoid components to have their own private caches that aren't friendly with the server's memory as old items are not flushed when memory gets low. I will write the config stuff in the next days and then we can continue from their with the source-cache thing etc. and see where it takes us. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [Docs] Articles on Cocoon
Arje Cahn wrote: - Cocoon and CMS by Steven, focus on the role/advantages of Cocoon in Daisy Darn, Steven, you got me there. I'd be happy to write a piece about knowledge sharing in intranets or on the web. Generating relationships, using team folders, finding articles, using thesauri and taxonomies, etc. Practical stuff that really adds value, no fuzzy knowledge management buzz. Also not about Wiki's (I'll leave that one to Steven ;) ). WDYT? I welcome any article that gives Cocoon more exposure. First, I'm not sure what Steven had in mind, but the two of you could figure out who focuses on what and get two articles out of this. Or...thinking out loud... without getting into last years' CMS show down, you could both write about how you solved similar issues in both CMS. Haven't seen Hippo's source ;-) I assume that both of you ran into similar problems and it would be interesting to see how you've solved that, e.g. searching and notification. Just make sure it's not an I can do this better approach. WDYT? Bye, Helma
Re: [Docs] Articles on Cocoon
On 10/11/05, hepabolu [EMAIL PROTECTED] wrote: So the article should not be too technical, but give enough information to help the readers in the second group to find more information. Given the target group the articles should not be too long, certainly not more than 5 pages, probably less. So far I've been promised: - Cocoon and large websites by Pier and Ross McDonald, focus on performance issues - Cocoon and security by Ralph, focus on security issues in internet banking - Cocoon and AJAX by Sylvain, focus on how easy it is in Cocoon - Cocoon and performance by Jack Ivers and Vadim, focus on a comparison of XSLT processors - Cocoon and CMS by Steven, focus on the role/advantages of Cocoon in Daisy Requests: - are there more people willing to contribute articles that could fit this series? Would you be interested in some Cocoon and Enterprise Application Integration stuff, with some JBI flavor on top? I could come up with something. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Jira or Bugzilla...
Reinhard Poetz wrote: This could also be a chance to clean up our issues list as discussed in the other ongoing thread and we could separate roadmap from bugs. Haven't been able to extensively look around in Jira, so: +0. But if it helps separating roadmaps from actual bugs I'm all for it: +1. Bye, Helma
Re: [Docs] Articles on Cocoon
Le 11 oct. 05, à 09:42, hepabolu a écrit : ...Requests: - are there more people willing to contribute articles that could fit this series?.. I could write one on Cocoon Bricks, a modern Cocoon example application. (I'm thinking of removing the -cms from the name when bricks moves to the new contrib directory, to lower the confusion about CMSes ;-) -Bertrand
typo in commit R312838
Hi, Apparently there is a typo on 2.2 for this commit, could anyone apply this patch? Cheers, cheche Index: src/java/org/apache/cocoon/components/thread/ThreadPool.java === --- src/java/org/apache/cocoon/components/thread/ThreadPool.java (revisión: 312838) +++ src/java/org/apache/cocoon/components/thread/ThreadPool.java(copia de trabajo) @@ -125,7 +125,7 @@ * @return Whether a shutDown method has succeeded in terminating all * threads */ -boolean isTerminatedAfterShutdown()); +boolean isTerminatedAfterShutdown(); /** * Execute a command using this pool
DO NOT REPLY [Bug 25295] - [Roadmap] XUL support
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=25295. 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=25295 --- Additional Comments From [EMAIL PROTECTED] 2005-10-11 11:06 --- Created an attachment (id=16652) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16652action=view) Patch to CForms' samples to integrate a form1 XUL sample. -- 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.
DO NOT REPLY [Bug 25295] - [Roadmap] XUL support
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=25295. 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=25295 --- Additional Comments From [EMAIL PROTECTED] 2005-10-11 11:07 --- Created an attachment (id=16653) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16653action=view) XSLT to transform dumped fi markup (FormsGenerator) to RDF. -- 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: typo in commit R312838
Juan Jose Pablos wrote: Hi, Apparently there is a typo on 2.2 for this commit, could anyone apply this patch? Thanks for the info - I was just in the process to commit, but damn Eclipse always takes 10 minutes to make up its mind... :( Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [VOTE] new committer: Max Pfingsthorn
Hi, On 11 Oct 2005, at 07:28, Bertrand Delacretaz wrote: So I have the pleasure of proposing Max as our new committer! A big +1. Welcome Max! Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
DO NOT REPLY [Bug 25295] - [Roadmap] XUL support
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=25295. 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=25295 --- Additional Comments From [EMAIL PROTECTED] 2005-10-11 11:10 --- Created an attachment (id=16654) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16654action=view) Form1 XUL template. It's in biggest parts still static. Two simple fields are filled dynamically and I started with the multivaluefield. -- 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: [Docs] Articles on Cocoon
Gianugo Rabellino wrote: Would you be interested in some Cocoon and Enterprise Application Integration stuff, with some JBI flavor on top? I could come up with something. I'm not familiar with any EAI stuff, but it sure seems to be a hot topic, so if you can write about it great, but I'm flying blind on this one. In short: yes please. Thanks. Bye, Helma
Re: svn commit: r312725 - in /cocoon/blocks/crails: ./ trunk/ trunk/WEB-INF/ trunk/java/ trunk/java/org/ trunk/java/org/apache/ trunk/java/org/apache/cocoon/ trunk/java/org/apache/cocoon/controller/ t
Le 10 oct. 05, à 23:10, Berin Loritsch a écrit : Upayavira wrote: ...https://svn.apache.org/repos/asf/cocoon/whiteboard/ Create yourself a directory there. Will do. FYI there's a trick to easily include blocks from the whiteboard in the 2.2 build, you can see how it's done in http://svn.apache.org/repos/asf/cocoon/gsoc/rgraham/refdoc/ , see the local.blocks.refdoc.xconf and README.TXT files. -Bertrand
Re: [VOTE] new committer: Max Pfingsthorn
Bertrand Delacretaz wrote: Dear community, Several of us share the thought that Max is the perfect example of a GSoC success: apart from great technical work, he's quickly found his place in our community, with regular contributions in code and on the lists. His presentation at last week's GT has shown a high level of understanding of CForms and of Cocoon at large. What he's done with the forms libraries is definitely not just a student work, it is solid stuff. (and besides that, it will be cool to have more people with difficult names to type ;-) So I have the pleasure of proposing Max as our new committer! Please cast your votes, here's mine: +1 +1 Upayavira
Re: [Docs] Articles on Cocoon
Bertrand Delacretaz wrote: I could write one on Cocoon Bricks, a modern Cocoon example application. (I'm thinking of removing the -cms from the name when bricks moves to the new contrib directory, to lower the confusion about CMSes ;-) Hmm, this could be an excellent entry-level article, i.e. focus on newcomers that don't know where to begin. We badly need this kind of article. OTOH My gut feeling tells me this doesn't fit exactly in the general idea of Cocoon can be used to build high roller apps/Cocoon implements the latest hot topics. It's more the Cocoon made easy track and for a track I need more than one article. I certainly want this article, but I need more thinking of how to use it most effectively. Bye, Helma
Re: [VOTE] new committer: Max Pfingsthorn
On 11 Oct 2005, at 09:03, Arje Cahn wrote: So I have the pleasure of proposing Max as our new committer! My first vote.. Happy to send it to you, Max :-) +1 You don't count!!! You hired the guy! :-P :-P :-P Anyhow, I'm glad to see that Max got to be voted on and here's my (non binding) +1 Pier smime.p7s Description: S/MIME cryptographic signature
Re: XULifying CForms (yet another attempt?)
Gianugo Rabellino gianugo at gmail.com writes: 1. server roundtrip model: Xul doesn't really fit in a request-response model where all data travel at once upon hitting a submit button. This might lead to two different alternatives: (a) ajax all over the place, where more or less every widget submits events to a Cocoon server or (b) server roundtrips being avoided whenever possible thanks to the richest functionalities of a Xul frontend (think repeaters). Is it an either-or-decision? Well, the way I see it is that either the Xul incarnation of CForms provides a different roundtrip model for client-server communication or it would just be a 1:1 mapping to the current HTML forms. Not much added value compared to an HTML rendering, given it would still be browser based *and* strongly tied to just one browser. Why should anyone choose to use the Xul version nowadays then? I think it's clear using XUL the HTML-way makes no sense. My either-or was related to the two mentioned alternatives. And these two depend heavily on the widget IMO. Convergence with the new Ajax model of CForms somewhat blurs the line, yet I feel that a mere translation of CForms widgets to Xul without a rethink of the roundtrip model might be somewhat limiting (as in uh, ok, so what?). Actually, I might go as far as saying that the whole Xul/CForms marriage might not have that much sense now that we have Ajax and all the Web 2.0 yadda-yadda. That is, unless we figure out some real advantage in server interaction. Claas and I came to the conclusion that Ajax as-is does not work with XUL. If you mean as-is as the current Cocoon incarnation, I don't quite see why, apart from some tweaks that might be necessary. The whole idea of Ajax actually was in Xul since day one, given that manipulation of the widget tree is delegated to javascript and network communication has to happen through XmlHttpRequest. And I have the perception that XBL might play a role even here I meant the browser update instructions which is actually only a client-side replacement of elements. The idea of rich clients includes the move of the view to the client, which does not happen with the current Ajax stuff. Only data should be sent to the client. This is what the RDF and XUL template stuff is about. My first idea was to provide one CForms template which knows how to display all the widgets described in the RDF, which means the RDF has to include information about the view (e.g. radio buttons vs. drop-down list). Besides this disadvantage Claas mentioned it is impossible to match all and everything in my super CForms template. So we switched to the approach I attached to the bug. Clean separation of data and view (form instance markup is generated with the FormsGenerator, so it contains no details about the view). The template is only on the client, but form-specific. That's what form1_template.xul is for example. Unfortunately this approach seems to be horrible to template writers. If you have to learn the concepts of RDF and this horrible templates of XUL before getting something to work ... Our conclusion: it's neither the correct approach. Now Claas tries something else on the client-side which is more or less a replacement for XUL templates: DOM 3 XPath or XSLT. The XPath approach would only work for Gecko engine at the moment, but maybe also in future IEs. It's similar to XUL template in that extent that it tries to match on elements and creates some markup if an XPath matches. XSLT should work even now in nearly all browsers. This is more or less the move of the stylesheets currently on the server to the client. Hmm... point is I'm afraid you won't go much farther than a few text input, checkboxes, radios and selection lists without XBL... You can get really far without XBL. By the way, the other part of a client-server-roundtrip, sending a request, is quite easy. Just walking through the DOM, collecting all form elements and constructing a request is easy. Jörg
[VOTE] Move to Jira (Was: Re: Jira or Bugzilla...)
Ok, there we go, here's the vote... [ ] +1 Yes please, let's move all our bugs to Jira and set it up to work in the following way: Statuses (workflow running accordingly): - OPEN - REOPENED - CLOSED - WAITING FOR FEEDBACK Issue Types: - BUG - NEW FEATURE - IMPROVEMENT - TEST - WISH - TASK - ROADMAP Components: - One per block - Core - Other Cocoon Part: - Sitemap components - Generic components - Components and Roles Configurations - Cocoon forms - Flow (Flowscript, Javaflow, ...) - Samples - Sitemaps - Build Environment - Core Java - Documentation Version/Status/Resolutions/Priorities: - Jira defaults [ ] -/+0 I could care less what issue tracking system we use [ ] -1 No, I want to keep using Bugzilla because smime.p7s Description: S/MIME cryptographic signature
RE: [VOTE] new committer: Max Pfingsthorn
You don't count!!! You hired the guy! :-P :-P :-P Yes! And damn glad I did. :) Heck, I'd vote twice if I could! Anyhow, I'm glad to see that Max got to be voted on and here's my (non binding) +1 You Mister Moral! ;p Arje
Re: [HEADS-UP] IRC support?
Bertrand Delacretaz wrote: You'd get a *lot* of noise if you simply log, so I'm not sure if it is worth the effort. What do you mean by noise? Look at [1] for an example log output. Jorg [1] http://svg.jibbering.com/svg/2005-10-09.html
Re: [HEADS-UP] IRC support?
Jorg Heymans jh at domek.be writes: What do you mean by noise? Look at [1] for an example log output. That's exactly the point: How much of such a conversation is actual useful? Jörg
[Poll] What sources of information do you use?
Hello Cocoon users, I'm in the process of gathering articles on the use of Cocoon in various environments with the intention of getting them published in a (online) magazine or on a website to promote exposure and understanding of Cocoon. Please answer the questions below so we can try to maximize the impact of the articles. Questions: 1. What is your favorite source of information, in other words: where would you be most likely to read these articles if they were published? 2. Where would your boss/person deciding on framework be most likely to read these articles? Thanks. Bye, Helma
Re: [VOTE] Move to Jira (Was: Re: Jira or Bugzilla...)
Pier Fumagalli wrote: Ok, there we go, here's the vote... [X] +1 Yes please, let's move all our bugs to Jira and set it up to work in the following way: Statuses (workflow running accordingly): - OPEN - REOPENED - CLOSED - WAITING FOR FEEDBACK Issue Types: - BUG - NEW FEATURE - IMPROVEMENT - TEST - WISH - TASK - ROADMAP Components: - One per block - Core - Other Cocoon Part: - Sitemap components - Generic components - Components and Roles Configurations - Cocoon forms - Flow (Flowscript, Javaflow, ...) - Samples - Sitemaps - Build Environment - Core Java - Documentation Version/Status/Resolutions/Priorities: - Jira defaults [ ] -/+0 I could care less what issue tracking system we use [ ] -1 No, I want to keep using Bugzilla because -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Roadmap for Cocoon Blocks
I hadn't thought of this before, but I suppose this means that end user applications using Cocoon will need to be built with Maven 2? Ralph Reinhard Poetz wrote: In Amsterdam at the GT Daniel gave a presentation (http://cocoongt.hippo12.castaserver.com/cocoongt/daniel-fagerstrom-blocks-2.pdf) about Cocoon blocks and one of his slides contained a roadmap for Cocoon blocks. This roadmap was discussed in the breaks and AFAICT is was widely accepted. Of course this doesn't mean that this is community consensus as not all have had the chance to comment on this yet. So here is the roadmap and let's discuss it officially on the mailing list: - Cocoon 2.2 will not use OSGi but will support blocks as far as possible: - blocks protocol (= sitemap blocks) - a block gets its own component manager that contains all local components and gets the block component managers of all wired blocks as parent. - we use M2 as build and deployment tool (needs some special M2 plug-ins for the deployment part) - blocks are distributed as binaries - blocks are *not* spread over different directories during deployment - a block can contain classes in [block]/BLOCK-INF/classes that are added to the context classloader -- this means that everything, that real blocks promise, works except the shielding of Java classes. - Cocoon 3.0 will use OSGi -- shielding classloader and hot plugablillity Although Daniel has emphasized this many times I want to repeat it: We don't need to branch trunk for this roadmap. OSGi development can be done in parallel and we can avoid the unsatisfying situation of maintaining two branches. Of course future development can show that this or that is not possible or should be done differently (who knows now, if OSGi will really make it) but IMO it's nice to have a goal and something that we can communicate to other projects that depend on Cocoon so that they have enough time to adapt their design decisions. WDOT?
Re: [VOTE] Move to Jira (Was: Re: Jira or Bugzilla...)
Pier Fumagalli wrote: Ok, there we go, here's the vote... [X] +1 Yes please, let's move all our bugs to Jira and set it up to work in the following way: Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [VOTE] new committer: Max Pfingsthorn
Bertrand Delacretaz wrote: Dear community, Several of us share the thought that Max is the perfect example of a GSoC success: apart from great technical work, he's quickly found his place in our community, with regular contributions in code and on the lists. His presentation at last week's GT has shown a high level of understanding of CForms and of Cocoon at large. What he's done with the forms libraries is definitely not just a student work, it is solid stuff. (and besides that, it will be cool to have more people with difficult names to type ;-) So I have the pleasure of proposing Max as our new committer! Please cast your votes, here's mine: +1 -Bertrand +1 Ralph
Re: [QVote] Configurable default for sitemap reloading
Ralph Goers wrote: Well, I don't know how great it would be to not be able to modify xslt's or portlet layouts on the fly. In fact, not being able to modify or add a portlet layout would be a big problem. But our sitemaps should never change without having a new release of our product. Yepp, the proposal takes care of this. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Clarifying classloading in 2.2 [was Re: Classloader changes]
Vadim Gritsenko wrote: Carsten Ziegeler wrote: In addition, we could define extra class paths in web.xml (containing directories/jars I think) which were added to the class path as well IIRC, those were *not* added to the classpath, but on the contrary - it was a way to indicate to the java compiler (used in xsp, for example) about any classpath which was set in the container. Ah, yes, you're right! Thanks! For example, if you have some extra lib in the tomcat/common/lib, it is visible to Cocoon but java compiler does not know about it, hence the need to specify extra class path elements. This can be avoided if javac knew how to work with class loader - as jdt does. So, as we are using jdt, we can remove these settings, right? In addition I think we should always use the paranoid class loader to avoid class loading problems. I don't like using paranoid class loader always. I prefer current situation where you can choose what you need. Hmm, yes, but with real blocks you have paranoid class loading anyway. Each block will use the exact jars it depends on. Now, I think the paranoid class loader does do more good than harm, so I think we should just use it. What situations do you have in mind where the paranoid class loader would not work for you? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [HEADS-UP] IRC support?
Joerg Heinicke wrote: That's exactly the point: How much of such a conversation is actual useful? Which is exactly not the point :-) The smallest snippet or remark can bring enlightening [1] Note that i'm not trying to push this in any way. It just seemed easy to do, thus making the effort worthwhile. I agree there is not much to be gained, but there is nothing to lose either. Lets leave it for now, I promise i won't bring it up again until i've got the bot working ;) Jorg [1] http://thread.gmane.org/gmane.text.xml.cocoon.devel/50579
Re: [Docs] Articles on Cocoon
hepabolu wrote: Bertrand Delacretaz wrote: I could write one on Cocoon Bricks, a modern Cocoon example application. (I'm thinking of removing the -cms from the name when bricks moves to the new contrib directory, to lower the confusion about CMSes ;-) Hmm, this could be an excellent entry-level article, i.e. focus on newcomers that don't know where to begin. We badly need this kind of article. OTOH My gut feeling tells me this doesn't fit exactly in the general idea of Cocoon can be used to build high roller apps/Cocoon implements the latest hot topics. It's more the Cocoon made easy track and for a track I need more than one article. I certainly want this article, but I need more thinking of how to use it most effectively. Bye, Helma All the articles should be published on our website as well as wherever else they can be (i.e. Javaworld, etc.). The bricks article would be very useful on our website even if it isn't published externally. Ralph
Re: [VOTE] Move to Jira (Was: Re: Jira or Bugzilla...)
Pier Fumagalli wrote: Ok, there we go, here's the vote... [ ] +1 Yes please, let's move all our bugs to Jira and set it up to work in the following way: Statuses (workflow running accordingly): - OPEN - REOPENED - CLOSED - WAITING FOR FEEDBACK Issue Types: - BUG - NEW FEATURE - IMPROVEMENT - TEST - WISH - TASK - ROADMAP Components: - One per block - Core - Other Cocoon Part: - Sitemap components - Generic components - Components and Roles Configurations - Cocoon forms - Flow (Flowscript, Javaflow, ...) - Samples - Sitemaps - Build Environment - Core Java - Documentation Version/Status/Resolutions/Priorities: - Jira defaults [ ] -/+0 I could care less what issue tracking system we use [ ] -1 No, I want to keep using Bugzilla because +0 I haven't used Jira. As long as what we use is blessed by infra (and I know Jira is) then I'll go with the flow. Ralph
Re: [VOTE] Move to Jira (Was: Re: Jira or Bugzilla...)
Il giorno 11/ott/05, alle ore 12:43, Pier Fumagalli ha scritto: [X] +1 Yes please, let's move all our bugs to Jira and set it up to work in the following way: Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: Roadmap for Cocoon Blocks
Ralph Goers wrote: I hadn't thought of this before, but I suppose this means that end user applications using Cocoon will need to be built with Maven 2? I'ld say they can but don't have to. We will distribute the 2.2 core and block releases via the m2 repository, so m2 based projects can easily upgrade this way. The full binary build will still contain everything in one package, this can be used to build your app in any other way you like. Now we might provide a recommended way of building and structuring cocoon applications using m2 archetypes and our own plugins, but it will only be a recommendation and not a requirement. 3.0 is a different beast alltogether. Likely we will need an m2 plugin that can compile one block against other blocks using osgi dependency rules (ie using the manifest information). The same goes for dependency resolution, as it needs to be made osgi aware (right Daniel?). So unless he knows a lot about osgi, a block developer will have to use our m2 deployment framework to target 3.0. Or am I seeing this m2-osgi build and deploy time integration too complicated for what it really is ? Jorg
Re: [RT] Clarifying classloading in 2.2 [was Re: Classloader changes]
Carsten Ziegeler wrote:
Hmm, yes, but with real blocks you have paranoid class loading anyway.
Each block will use the exact jars it depends on.
hmm, I wouldn't formulate it this way. The build system (M2) will make sure that
there is only one include of e.g. log4j deployed as all blocks that depend on
it, have a log4j dependency.
What we must do in every case is using our own classloader that uses the context
classloader that is provided by a spec compliant servlet container as parent
classloader. The point now is that as we already change the classloader,
changing it a bit further doesn't make us more our less standard compliant.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [VOTE] new committer: Max Pfingsthorn
Bertrand Delacretaz wrote:
Dear community,
Several of us share the thought that Max is the perfect example of a
GSoC success: apart from great technical work, he's quickly found his
place in our community, with regular contributions in code and on the
lists.
His presentation at last week's GT has shown a high level of
understanding of CForms and of Cocoon at large. What he's done with the
forms libraries is definitely not just a student work, it is solid stuff.
(and besides that, it will be cool to have more people with difficult
names to type ;-)
So I have the pleasure of proposing Max as our new committer!
Please cast your votes, here's mine:
+1
As his GSoC mentor it's a great pleasure for me seeing you becoming a Cocoon
committer. So big +1!
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Roadmap for Cocoon Blocks
Jorg Heymans wrote:
Ralph Goers wrote:
I hadn't thought of this before, but I suppose this means that end user
applications using Cocoon will need to be built with Maven 2?
I'ld say they can but don't have to.
Right, if the user makes sure himself that the dependencies are resolved
correctly because a 2.2 block will not include the JARs it depends on but they
are copied into WEB-INF/lib at deploy time. M2 will make sure that only one
version of one JAR type is deployed.
Currently these dependendencies are declared in the Maven project descriptor.
Personally I don't have a problem with it as the alternative is having our own
mechanism. Shipping M2 with Cocoon 2.2 will be much simpler.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: XULifying CForms (yet another attempt?)
On 10/11/05, Joerg Heinicke [EMAIL PROTECTED] wrote: Gianugo Rabellino gianugo at gmail.com writes: 1. server roundtrip model: Xul doesn't really fit in a request-response model where all data travel at once upon hitting a submit button. This might lead to two different alternatives: (a) ajax all over the place, where more or less every widget submits events to a Cocoon server or (b) server roundtrips being avoided whenever possible thanks to the richest functionalities of a Xul frontend (think repeaters). Is it an either-or-decision? Well, the way I see it is that either the Xul incarnation of CForms provides a different roundtrip model for client-server communication or it would just be a 1:1 mapping to the current HTML forms. Not much added value compared to an HTML rendering, given it would still be browser based *and* strongly tied to just one browser. Why should anyone choose to use the Xul version nowadays then? I think it's clear using XUL the HTML-way makes no sense. My either-or was related to the two mentioned alternatives. And these two depend heavily on the widget IMO. I see your point. Problem is whether the CForms approach can be abstracted so that a CForm can be transparently rendered both as HTML or as XUL, something I don't see likely to happen at the moment. Consider repeaters in a non-Ajax scenario (i.e. no ajax=true): the HTML CForm will need a roundtrip to the server, which would be overkill for the more powerful XUL rendering. Convergence with the new Ajax model of CForms somewhat blurs the line, yet I feel that a mere translation of CForms widgets to Xul without a rethink of the roundtrip model might be somewhat limiting (as in uh, ok, so what?). Actually, I might go as far as saying that the whole Xul/CForms marriage might not have that much sense now that we have Ajax and all the Web 2.0 yadda-yadda. That is, unless we figure out some real advantage in server interaction. Claas and I came to the conclusion that Ajax as-is does not work with XUL. If you mean as-is as the current Cocoon incarnation, I don't quite see why, apart from some tweaks that might be necessary. The whole idea of Ajax actually was in Xul since day one, given that manipulation of the widget tree is delegated to javascript and network communication has to happen through XmlHttpRequest. And I have the perception that XBL might play a role even here I meant the browser update instructions which is actually only a client-side replacement of elements. The idea of rich clients includes the move of the view to the client, which does not happen with the current Ajax stuff. Only data should be sent to the client. This is what the RDF and XUL template stuff is about. Well, definitely the ideal scenario would be the (rich) client handling navigation and posting pure data back and forth (either bound or unbound to the underlying model - better, the underlying model's XML view, even for objects). Then again, however, this would stretch the CForm paradigm quite a bit. Not sure it's feasible without a major impact in CForms as a whole. My first idea was to provide one CForms template which knows how to display all the widgets described in the RDF, which means the RDF has to include information about the view (e.g. radio buttons vs. drop-down list). Besides this disadvantage Claas mentioned it is impossible to match all and everything in my super CForms template. So we switched to the approach I attached to the bug. Clean separation of data and view (form instance markup is generated with the FormsGenerator, so it contains no details about the view). The template is only on the client, but form-specific. That's what form1_template.xul is for example. Unfortunately this approach seems to be horrible to template writers. If you have to learn the concepts of RDF and this horrible templates of XUL before getting something to work ... Well, I have been tempted by XUL templates, then took some time to read a few rants here and there and became convinced that it's not that mature and reliable as a technology (see http://www.jerf.org/resources/xblinjs/whyNotMozilla/notXulTemplates.html). I know I keep pestering with XBL, but I have the gut feeling that XBL won't be as difficult as Xul templates and could provide a much better experience for form template writers. But I really need to get my feet wet and provide some code. Our conclusion: it's neither the correct approach. Now Claas tries something else on the client-side which is more or less a replacement for XUL templates: DOM 3 XPath or XSLT. The XPath approach would only work for Gecko engine at the moment, but maybe also in future IEs. Uhm, so what? Aren't we targetting XUL in Gecko? It's similar to XUL template in that extent that it tries to match on elements and creates some markup if an XPath matches. Yup, document.evaluate()
Re: Roadmap for Cocoon Blocks
Reinhard Poetz wrote: In Amsterdam at the GT Daniel gave a presentation (http://cocoongt.hippo12.castaserver.com/cocoongt/daniel-fagerstrom-blocks-2.pdf) about Cocoon blocks and one of his slides contained a roadmap for Cocoon blocks. This roadmap was discussed in the breaks and AFAICT is was widely accepted. Of course this doesn't mean that this is community consensus as not all have had the chance to comment on this yet. So here is the roadmap and let's discuss it officially on the mailing list: - Cocoon 2.2 will not use OSGi but will support blocks as far as possible: - blocks protocol (= sitemap blocks) - a block gets its own component manager that contains all local components and gets the block component managers of all wired blocks as parent. - we use M2 as build and deployment tool (needs some special M2 plug-ins for the deployment part) - blocks are distributed as binaries - blocks are *not* spread over different directories during deployment - a block can contain classes in [block]/BLOCK-INF/classes that are added to the context classloader -- this means that everything, that real blocks promise, works except the shielding of Java classes. - Cocoon 3.0 will use OSGi -- shielding classloader and hot plugablillity Although Daniel has emphasized this many times I want to repeat it: We don't need to branch trunk for this roadmap. OSGi development can be done in parallel and we can avoid the unsatisfying situation of maintaining two branches. Of course future development can show that this or that is not possible or should be done differently (who knows now, if OSGi will really make it) but IMO it's nice to have a goal and something that we can communicate to other projects that depend on Cocoon so that they have enough time to adapt their design decisions. I'm +1 One thing, though, remember to also have a LinkRewritingTransformer that is block aware so that we can do style src=block:skin:/styles/main.css/ and this gets translated in the right URL (hopefully relative, so that we don't have issues with webapp proxying, or, if absolute, we need a way to configure where is the cocoon mountpoint as seen from the proxy side) I'm currently doing http://simile.mit.edu/repository/linotype/trunk/stylesheets/absolutize.xslt with my latest linotype and I can't wait to get rid of all these hacks :-) -- Stefano.
Re: svn commit: r312820 - /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
Is it just too early in the morning for me? I don't see any difference
other than spacing?
Ralph
[EMAIL PROTECTED] wrote:
Author: hepabolu
Date: Tue Oct 11 00:02:02 2005
New Revision: 312820
URL: http://svn.apache.org/viewcvs?rev=312820view=rev
Log:
Bug 35413, patch applied, thanks to Patrick Ahles, now properly applied ;-)
Modified:
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
Modified:
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
URL:
http://svn.apache.org/viewcvs/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java?rev=312820r1=312819r2=312820view=diff
==
---
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
(original)
+++
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
Tue Oct 11 00:02:02 2005
@@ -308,11 +308,11 @@
this.contentHandler.endElement(URI, DAY_NODE_NAME,
PREFIX + ':' + DAY_NODE_NAME);
end.add(Calendar.DAY_OF_MONTH, 1);
+if (firstDay == end.get(Calendar.DAY_OF_WEEK)) {
+ this.contentHandler.endElement(URI, WEEK_NODE_NAME,
+ PREFIX + ':' + WEEK_NODE_NAME);
+ }
}
- if (firstDay == end.get(Calendar.DAY_OF_WEEK)) {
-this.contentHandler.endElement(URI, WEEK_NODE_NAME,
-PREFIX + ':' + WEEK_NODE_NAME);
- }
}
this.contentHandler.endElement(URI, CALENDAR_NODE_NAME,
PREFIX + ':' + CALENDAR_NODE_NAME);
Re: [GT2005] Presentations and Audio Now Available
Bertrand Delacretaz wrote: Le 10 oct. 05, à 23:04, Agile Jack a écrit : ...Thanks to Arje and others from Hippo for a well-run event, and to the presenters for great content... And big thanks to you for the recordings and quick publishing, this adds a lot of value to the event! Now we need somebody to have the SMIL of the slides synchronized with the audio ;-) JK, awesome job everyone, too bad I was on the other side of the planet (in los angeles)... maybe next year we should have MIT organize it :-) -- Stefano.
Re: [VOTE] new committer: Max Pfingsthorn
Bertrand Delacretaz wrote: Dear community, Several of us share the thought that Max is the perfect example of a GSoC success: apart from great technical work, he's quickly found his place in our community, with regular contributions in code and on the lists. His presentation at last week's GT has shown a high level of understanding of CForms and of Cocoon at large. What he's done with the forms libraries is definitely not just a student work, it is solid stuff. (and besides that, it will be cool to have more people with difficult names to type ;-) So I have the pleasure of proposing Max as our new committer! Please cast your votes, here's mine: +1 +1 -- Stefano.
Re: Roadmap for Cocoon Blocks
Reinhard Poetz wrote: Jorg Heymans wrote: Ralph Goers wrote: I hadn't thought of this before, but I suppose this means that end user applications using Cocoon will need to be built with Maven 2? I'ld say they can but don't have to. Right, if the user makes sure himself that the dependencies are resolved correctly because a 2.2 block will not include the JARs it depends on but they are copied into WEB-INF/lib at deploy time. M2 will make sure that only one version of one JAR type is deployed. Currently these dependendencies are declared in the Maven project descriptor. Personally I don't have a problem with it as the alternative is having our own mechanism. Shipping M2 with Cocoon 2.2 will be much simpler. I don't have a problem with that. I really am not crazy about implementing our own alternative. But it is just one more thing that needs to be made clear in the doc. Ralph
Re: [Docs] Articles on Cocoon
On 11 Oct 2005, at 10:22, Arje Cahn wrote: - Cocoon and CMS by Steven, focus on the role/advantages of Cocoon in Daisy Darn, Steven, you got me there. Don't worry: the idea was just to narrate why we're happy to have based part of Daisy on Cocoon. I didn't mean to sell Daisy using the Cocoon-bandwagon, AAMOF most of the time it's the other way around. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought Open Source Java XML stevenn at outerthought.orgstevenn at apache.org
Re: Roadmap for Cocoon Blocks
Reinhard Poetz wrote: Currently these dependendencies are declared in the Maven project descriptor. Personally I don't have a problem with it as the alternative is having our own mechanism. Shipping M2 with Cocoon 2.2 will be much simpler. Agreed, but don't you mean requiring rather than shipping ? Jorg
Re: [Docs] Articles on Cocoon
hepabolu wrote: Hi, this is both a notification and some requests. During the GT I've asked several people in the community to write an article on an aspect of Cocoon. The intention is to get a series of a few articles and have them published in an (online) magazine or other relevant site to promote/expose Cocoon. The intended readers are: - those unfamiliar with Cocoon/those that think Cocoon is only suitable for small, almost static websites. - those that are familiar with Cocoon and run into a similar problem. So the article should not be too technical, but give enough information to help the readers in the second group to find more information. Given the target group the articles should not be too long, certainly not more than 5 pages, probably less. So far I've been promised: - Cocoon and large websites by Pier and Ross McDonald, focus on performance issues - Cocoon and security by Ralph, focus on security issues in internet banking - Cocoon and AJAX by Sylvain, focus on how easy it is in Cocoon - Cocoon and performance by Jack Ivers and Vadim, focus on a comparison of XSLT processors - Cocoon and CMS by Steven, focus on the role/advantages of Cocoon in Daisy Awesome! How about something about Cocoon as a service integration platform? Massimo, Matthew and Gianugo, between the three of you, I'm sure you have something to say. I would like to see the success stories too, like the sites that won awards that are powered by cocoon or the behind-the-scene integrators. Requests: - are there more people willing to contribute articles that could fit this series? I think you should convince our more CTO-ish type of committers that even if they are so overwhelmed and busy these days, it's probably good for their business and cocoon's in general, if we show off a little more what we achieved. More real life case studies and serious stuff can bring a lot of solidity to the question why should I use this stuff? that CTO/CIOs ask. - what would be the most interesting site/magazine to get this series published? I intend to get them up on our documentation site as well, just have to figure out what the most effective publishing schedule is. I think O'Reillynet/xml.com is a good place. O'Reilly has wanted a book on cocoon forever, which I started and dumped, then Steven restarted and dumped (or held), so it didn't happen. Not sure there is enough traction for an entire column on cocoon, but we might well ask, a lot of people in O'Reilly have good respect for Cocoon. -- Stefano.
Re: Roadmap for Cocoon Blocks
Stefano Mazzocchi wrote:
One thing, though, remember to also have a LinkRewritingTransformer that
is block aware so that we can do
style src=block:skin:/styles/main.css/
and this gets translated in the right URL (hopefully relative, so that
we don't have issues with webapp proxying, or, if absolute, we need a
way to configure where is the cocoon mountpoint as seen from the proxy
side)
I'm currently doing
http://simile.mit.edu/repository/linotype/trunk/stylesheets/absolutize.xslt
with my latest linotype and I can't wait to get rid of all these hacks :-)
I haven't checked it but I think the LinkRewritingTransformer in the
link-rewriting block is already block aware and does what you want. Of course it
needs to be moved to core.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [GT2005] Presentations and Audio Now Available
Stefano Mazzocchi wrote: JK, awesome job everyone, too bad I was on the other side of the planet (in los angeles)... maybe next year we should have MIT organize it :-) Too bad the timing was bad. It would have been nice to meet you - either in Amsterdam or in L.A.! Ralph
Re: [RT] Clarifying classloading in 2.2 [was Re: Classloader changes]
Reinhard Poetz wrote: Carsten Ziegeler wrote: Hmm, yes, but with real blocks you have paranoid class loading anyway. Each block will use the exact jars it depends on. hmm, I wouldn't formulate it this way. The build system (M2) will make sure that there is only one include of e.g. log4j deployed as all blocks that depend on it, have a log4j dependency. Hmm, I'm not sure if this will be the case :) For example, if two blocks depend on let's say commons-collections, block A depends on version 2.0 and block B on 3.0, then of course each block should get it's own version. Log4j is - as you said - the other case. We can set such libraries to provided which means the environment will provide the classes which could be our Cocoon core. Or we have to extend m2. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [VOTE] Move to Jira (Was: Re: Jira or Bugzilla...)
Pier Fumagalli wrote:
Ok, there we go, here's the vote...
[X] +1 Yes please, let's move all our bugs to Jira and set it up
to work in the following way:
Cocoon Part:
- Sitemap components
- Generic components
- Components and Roles Configurations
- Cocoon forms
- Flow (Flowscript, Javaflow, ...)
- Samples
- Sitemaps
- Build Environment
- Core Java
- Documentation
I'm not sure about the parts. Do we really need all of them? IIUC the concept
of part correctly, having
- code
- documentation
- build environment
should be enough. Note that samples will (have) become blocks on their own.
The other part types don't make much sense to me.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [RT] Clarifying classloading in 2.2 [was Re: Classloader changes]
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Hmm, yes, but with real blocks you have paranoid class loading anyway.
Each block will use the exact jars it depends on.
hmm, I wouldn't formulate it this way. The build system (M2) will make sure that
there is only one include of e.g. log4j deployed as all blocks that depend on
it, have a log4j dependency.
Hmm, I'm not sure if this will be the case :) For example, if two blocks
depend on let's say commons-collections, block A depends on version 2.0
and block B on 3.0, then of course each block should get it's own
version. Log4j is - as you said - the other case. We can set such
libraries to provided which means the environment will provide the
classes which could be our Cocoon core. Or we have to extend m2.
AFAIU this is the usecase that makes OSGi shine. Shall we really implement this?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [Docs] Articles on Cocoon
- what would be the most interesting site/magazine to get this series published? I intend to get them up on our documentation site as well, just have to figure out what the most effective publishing schedule is. I think O'Reillynet/xml.com is a good place. O'Reilly has wanted a book on cocoon forever, which I started and dumped, then Steven restarted and dumped (or held), so it didn't happen. Not sure there is enough traction for an entire column on cocoon, but we might well ask, a lot of people in O'Reilly have good respect for Cocoon. Actually I had this idea a while ago. The Cocoon bible. Written by the people who wrote it. Having a couple more authors to split the huge task. We could even make it an Open Source book. Available as a pdf or in print for the ones who want to hold something in there hands. I would love that... cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: [QVote] Configurable default for sitemap reloading
Torsten Curdt wrote: But we already delay the checking and therefor heavily reduce the native filesystem checks ...and I was just playing devil's advocate here. Are we? * XSLTProcessorImpl uses source validity / aggregate validity, I don't see any delays in there. * Cocoon.java has hardcoded delay // FIXME: add a configuration option for the refresh delay. // for now, hard-coded to 1 second. * JXTemplate does not have any delay at all * XSP, etc. Nothing sitemap related and therefor totally different issues. Got carried away a bit :-) It is related though to filesystem checks. It would probably be even more effective to fix those. Yes it will - sitemap is just few files, while all xsls and jx used for single request can be many. Vadim
Re: [Docs] Articles on Cocoon
On 11 Oct 2005, at 15:06, Torsten Curdt wrote: Actually I had this idea a while ago. The Cocoon bible. Written by the people who wrote it. Having a couple more authors to split the huge task. Uhm. Isn't this what the documentation should be all about? Instead of doing the FOO-jerk, just make sure our documentation is republish-able in a paper format at all times? ORA even has a series for that: http://www.oreilly.com/oreilly/author/ch01.html#series and look for community press. Of course, that's easier said than done. But I stopped dreaming of finding time to write something when I stopped caring for my name on a cover. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought Open Source Java XML stevenn at outerthought.orgstevenn at apache.org
Re: [RT] Clarifying classloading in 2.2 [was Re: Classloader changes]
Reinhard Poetz wrote: AFAIU this is the usecase that makes OSGi shine. Shall we really implement this? Can you please elaborate a little bit on this? Of course, if there is already something helping us we should use it. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: XULifying CForms (yet another attempt?)
Gianugo Rabellino wrote: On 10/10/05, Stefano Mazzocchi [EMAIL PROTECTED] wrote: I've been working heavily with XUL recently and I have to say, it could be a refreshing experience if you were used to build DHTML applications. At the same time, be aware that XUL is normally used inside the mozilla security sandbox (say, loaded with chrome:// instead of being loaded with http:// or file://), things change rather dramatically when you use remote XUL (as it is called when you load XUL from http:// as opposed to local XUL. From what I reckon, the security sandbox shouldn't be that much of an issue when dealing just with forms with no access to local resources. Things of course would change when it comest to mangling with the user's station, such as writing files or opening socket connections to different hosts, but it shouldn't be different from applets, to say the least. That is the theory. In practice, I heard it's a lot more painful, due to bugs and overconcerned security restrictions. As far as XBL goes, I would suggest to start without and see how far you can keep going without it (which, for me, is pretty far since I'm not developing reusable UI widgets) Then again, a good lot of CForms is about reusable UI widgets, which makes me think that we'll need XBL pretty soon. Is there a reason to be scared though? I don't quite find XBL, in its simplest incarnations, a daunting technology: if you use it as a poor's man XSLT/macro processor it's more or less a piece of cake. I agree, though, on staying away from overcomplication as much as we can. Oh, no, nothing to be really scared off. Just a way to reduce the barrier of entry... but if you think you need it, go for it. As for as XHTML, XUL does *NOT* replace XHTML, in fact, you can consider it as an extension to it. There are things that are, IMO, but better than in XHTML (the vbox/hbox/flex model, for example, *WAY* better than the stinking table/tr/td or even better than the CSS3 column layouts) but some XUL widgets are nothing but reusable XHTML constructs with embedded style and behavior (and that's why XBL is related to CSS, you can think if XBL as an extension to CSS to make behavior portable and isolated.. too bad they got the syntax wrong, the use of the XML for XBL is a total golden hammer instance if you ask me) rant Now, call me an old fart, but I don't quite like the continuous and oh-so-fashionable XML bashing I see nowadays. Clearly, writing angle brackets all over the place isn't the most comfortable way of working, but as long as I will be able to (per)use transformations so that I will be able to generate an application using just an XSL stylesheet from a model, I'll be an happy puppy. I just wish we had a (successful) alternate syntax to avoid the carpal tunnel syndrome, yet XSLT/XPath/validations and friends are just too powerful technologies that make me easily fogive input verbosity. /rant all right, all right. look, it can be worse, I work with people that want everything to be RDF ;-) As far as roundtripping, Ajax all over the place is the only reasonable answer, IMO... be aware that this makes browser history and bookmarking an interesting problem. Yup, my point exactly. One of the first problems to dissect is how CForms can go from a navigation based framework to a real GUI, where navigation happens locally and it's calculated (mostly) on the client. This is my first and foremost concern and at times I have the feeling that Xul in CForms will have to remain a pure translation of html interfaces (as in s/\.html/\.xul/g). Not a big deal after all. Would be nice to work with other types of interaction too, though, like wizards and decks, but that's another story. At the same time, browsers are *NOT* build with that in mind and remote XUL cannot prevent the users from clicking the back button Well, this is where continuation should help us. At least possibly. :-) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/) -- Stefano.
Re: [VOTE] Move to Jira (Was: Re: Jira or Bugzilla...)
On 11 Oct 2005, at 14:03, Reinhard Poetz wrote: Pier Fumagalli wrote: Ok, there we go, here's the vote... [X] +1 Yes please, let's move all our bugs to Jira and set it up to work in the following way: Cocoon Part: - Sitemap components - Generic components - Components and Roles Configurations - Cocoon forms - Flow (Flowscript, Javaflow, ...) - Samples - Sitemaps - Build Environment - Core Java - Documentation I'm not sure about the parts. Do we really need all of them? IIUC the concept of part correctly, having - code - documentation - build environment should be enough. Note that samples will (have) become blocks on their own. The other part types don't make much sense to me. It's to identify errors occurring in a specific part of a block... If we take samples out of the picture, a block might with some forms (let's assume the Captcha block provides a sitemap using CForms, for example). So, I could target a bug, issue, task, whatever to a specific block (Captcha block, this is in the components) and subtarget it to Sitemap and Forms in the part... Pier smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r312820 - /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
Hi Ralph,
this indeed looks somewhat confusing, but the IF is now _inside_ the
while loop...
On 10/11/05, Ralph Goers [EMAIL PROTECTED] wrote:
Is it just too early in the morning for me? I don't see any difference
other than spacing?
Ralph
[EMAIL PROTECTED] wrote:
Author: hepabolu
Date: Tue Oct 11 00:02:02 2005
New Revision: 312820
URL: http://svn.apache.org/viewcvs?rev=312820view=rev
Log:
Bug 35413, patch applied, thanks to Patrick Ahles, now properly applied ;-)
Modified:
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
Modified:
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
URL:
http://svn.apache.org/viewcvs/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java?rev=312820r1=312819r2=312820view=diff
==
---
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
(original)
+++
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
Tue Oct 11 00:02:02 2005
@@ -308,11 +308,11 @@
this.contentHandler.endElement(URI, DAY_NODE_NAME,
PREFIX + ':' + DAY_NODE_NAME);
end.add(Calendar.DAY_OF_MONTH, 1);
+ if (firstDay ==
end.get(Calendar.DAY_OF_WEEK)) {
+ this.contentHandler.endElement(URI,
WEEK_NODE_NAME,
+ PREFIX + ':' + WEEK_NODE_NAME);
+ }
}
- if (firstDay == end.get(Calendar.DAY_OF_WEEK)) {
- this.contentHandler.endElement(URI,
WEEK_NODE_NAME,
-PREFIX + ':' + WEEK_NODE_NAME);
- }
}
this.contentHandler.endElement(URI, CALENDAR_NODE_NAME,
PREFIX + ':' + CALENDAR_NODE_NAME);
--
Patrick
Neutiquam erro. Magister mundi sum!
Re: [Docs] Articles on Cocoon
Torsten Curdt wrote: - what would be the most interesting site/magazine to get this series published? I intend to get them up on our documentation site as well, just have to figure out what the most effective publishing schedule is. I think O'Reillynet/xml.com is a good place. O'Reilly has wanted a book on cocoon forever, which I started and dumped, then Steven restarted and dumped (or held), so it didn't happen. Not sure there is enough traction for an entire column on cocoon, but we might well ask, a lot of people in O'Reilly have good respect for Cocoon. Actually I had this idea a while ago. The Cocoon bible. Written by the people who wrote it. Having a couple more authors to split the huge task. We could even make it an Open Source book. Available as a pdf or in print for the ones who want to hold something in there hands. I would love that... How about a wikibook? -- Stefano.
RE: [Docs] Articles on Cocoon
I think you should convince our more CTO-ish type of committers that even if they are so overwhelmed and busy these days, it's probably good for their business and cocoon's in general, if we show off a little more what we achieved. More real life case studies and serious stuff can bring a lot of solidity to the question why should I use this stuff? that CTO/CIOs ask. I hear the call. I'll chat to Gianugo/Massimo etc. about what we may be able to write up. Not sure there is enough traction for an entire column on cocoon, but we might well ask, a lot of people in O'Reilly have good respect for Cocoon. I will be at EuroOSCON next week and will see what may be possible to raise the awareness for Cocoon over at O'Reilly. Actually it is a pity no-one submitted a Cocoon talk for that. I will be using Cocoon in my Open Source business session - so at least there will be a little plug at CxO level. Matthew
Re: FYI: 2.2 samples pages reorganized
Bertrand Delacretaz wrote: I've just committed the changes that we started yesterday at the Hackathon, the first page of samples now shows links to a minimum number of samples, the rest being on a different page. I'd appreciate it if people could give it a try, I haven't had time to check all the samples yet. All formerly existing samples should still be there for now, but the page building mechanism is slightly different, so please check if your favorite sample is still there. -Bertrand Just had a quick look and some things came to mind: - as Carsten pointed out, the link to all samples is very unobtrusive. - I really feel the need for a back link on each overview page or maybe the Cocoon logo could be made into a link, going back to the first page of the samples. - if core is treated as a block, all core samples should be in one page, like the samples for each block. I.e. additional core samples should be either referenced on the core samples page or integrated. - I really feel we shouldn't go deeper than 2 or 3 levels: * first page - sample page * first page, all samples - long list, block oriented - sample page If there are more sublevels we should remove them (I think there are a few). - it seems that the list of blocks samples should be alphabetical, but then groovy flow is out of order. Haven't look at the others yet, although putting Cocoon Forms under F is not logical for an outsider. Bye, Helma
Re: [VOTE] new committer: Max Pfingsthorn
On Tue, Oct 11, 2005 at 08:28:56AM +0200, Bertrand Delacretaz wrote: So I have the pleasure of proposing Max as our new committer! Please cast your votes, here's mine: Happy +1 --Tim Larson
Re: [GT2005] Presentations and Audio Now Available
The podcast has been updated to this URL to keep everything on the cocoongt site: http://cocoongt.hippo12.castaserver.com/cocoongt/audio/gt2005.xml: On 10/10/05, Agile Jack [EMAIL PROTECTED] wrote: For those that weren't able to attend the Cocoon GetTogether 2005, presentations and audio are now available here: http://www.cocoongt.org/Slides-and-recordings.html Also, a podcast RSS feed is available here: http://agilepartners.com/gt2005.xml and instructions on how to subscribe in iTunes 5 here: http://www.agilepartners.com/blog/ Thanks to Arje and others from Hippo for a well-run event, and to the presenters for great content. -- Jack Ivers -- Agile Partners http://www.agilepartners.com mailto:[EMAIL PROTECTED] -- Jack Ivers -- Agile Partners http://www.agilepartners.com mailto:[EMAIL PROTECTED]
Re: svn commit: r312820 - /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
Does this patch also need to be applied to trunk (2.2) ?
Ralph
Patrick Ahles wrote:
Hi Ralph,
this indeed looks somewhat confusing, but the IF is now _inside_ the
while loop...
On 10/11/05, Ralph Goers [EMAIL PROTECTED] wrote:
Is it just too early in the morning for me? I don't see any difference
other than spacing?
Ralph
[EMAIL PROTECTED] wrote:
Author: hepabolu
Date: Tue Oct 11 00:02:02 2005
New Revision: 312820
URL: http://svn.apache.org/viewcvs?rev=312820view=rev
Log:
Bug 35413, patch applied, thanks to Patrick Ahles, now properly applied ;-)
Modified:
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
Modified:
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
URL:
http://svn.apache.org/viewcvs/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java?rev=312820r1=312819r2=312820view=diff
==
---
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
(original)
+++
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
Tue Oct 11 00:02:02 2005
@@ -308,11 +308,11 @@
this.contentHandler.endElement(URI, DAY_NODE_NAME,
PREFIX + ':' + DAY_NODE_NAME);
end.add(Calendar.DAY_OF_MONTH, 1);
+ if (firstDay == end.get(Calendar.DAY_OF_WEEK)) {
+ this.contentHandler.endElement(URI,
WEEK_NODE_NAME,
+ PREFIX + ':' + WEEK_NODE_NAME);
+ }
}
- if (firstDay == end.get(Calendar.DAY_OF_WEEK)) {
- this.contentHandler.endElement(URI,
WEEK_NODE_NAME,
-PREFIX + ':' + WEEK_NODE_NAME);
- }
}
this.contentHandler.endElement(URI, CALENDAR_NODE_NAME,
PREFIX + ':' + CALENDAR_NODE_NAME);
--
Patrick
Neutiquam erro. Magister mundi sum!
Re: [Docs] Articles on Cocoon
Torsten Curdt wrote: - what would be the most interesting site/magazine to get this series published? I intend to get them up on our documentation site as well, just have to figure out what the most effective publishing schedule is. I think O'Reillynet/xml.com is a good place. O'Reilly has wanted a book on cocoon forever, which I started and dumped, then Steven restarted and dumped (or held), so it didn't happen. Not sure there is enough traction for an entire column on cocoon, but we might well ask, a lot of people in O'Reilly have good respect for Cocoon. Actually I had this idea a while ago. The Cocoon bible. Written by the people who wrote it. Having a couple more authors to split the huge task. We could even make it an Open Source book. Available as a pdf or in print for the ones who want to hold something in there hands. I would love that... As said, I also think that writing a book is a huge task. I'm sure Carsten and Matthew can give great insight in this. ;-) Hell, my own thesis is proceeding with only a few lines a day, so I know. Let's not jump into illusions. As much as I cannot tell the lot of you to rewrite Cocoon and divide the work among the most active committers, it's impossible to do the same for the documentation. What we CAN try, is what Steven already suggested: get the documentation into a coherent and complete state and use that as a book. This will be a slow and gradual process. For now I want short articles that can appear in magazines, and of course they end up on our website.
Re: svn commit: r312820 - /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
Yes, but since so much was being reorganized, I hesitated. I'll create
a patch for trunk too.
On 10/11/05, Ralph Goers [EMAIL PROTECTED] wrote:
Does this patch also need to be applied to trunk (2.2) ?
Ralph
Patrick Ahles wrote:
Hi Ralph,
this indeed looks somewhat confusing, but the IF is now _inside_ the
while loop...
On 10/11/05, Ralph Goers [EMAIL PROTECTED] wrote:
Is it just too early in the morning for me? I don't see any difference
other than spacing?
Ralph
[EMAIL PROTECTED] wrote:
Author: hepabolu
Date: Tue Oct 11 00:02:02 2005
New Revision: 312820
URL: http://svn.apache.org/viewcvs?rev=312820view=rev
Log:
Bug 35413, patch applied, thanks to Patrick Ahles, now properly applied ;-)
Modified:
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
Modified:
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
URL:
http://svn.apache.org/viewcvs/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java?rev=312820r1=312819r2=312820view=diff
==
---
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
(original)
+++
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
Tue Oct 11 00:02:02 2005
@@ -308,11 +308,11 @@
this.contentHandler.endElement(URI, DAY_NODE_NAME,
PREFIX + ':' + DAY_NODE_NAME);
end.add(Calendar.DAY_OF_MONTH, 1);
+ if (firstDay ==
end.get(Calendar.DAY_OF_WEEK)) {
+ this.contentHandler.endElement(URI,
WEEK_NODE_NAME,
+ PREFIX + ':' + WEEK_NODE_NAME);
+ }
}
- if (firstDay == end.get(Calendar.DAY_OF_WEEK)) {
- this.contentHandler.endElement(URI,
WEEK_NODE_NAME,
-PREFIX + ':' + WEEK_NODE_NAME);
- }
}
this.contentHandler.endElement(URI, CALENDAR_NODE_NAME,
PREFIX + ':' + CALENDAR_NODE_NAME);
--
Patrick
Neutiquam erro. Magister mundi sum!
--
Patrick
Neutiquam erro. Magister mundi sum!
Re: XULifying CForms (yet another attempt?)
On 10/11/05, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: snip/ rant Now, call me an old fart, but I don't quite like the continuous and oh-so-fashionable XML bashing I see nowadays. Clearly, writing angle brackets all over the place isn't the most comfortable way of working, but as long as I will be able to (per)use transformations so that I will be able to generate an application using just an XSL stylesheet from a model, I'll be an happy puppy. I just wish we had a (successful) alternate syntax to avoid the carpal tunnel syndrome, yet XSLT/XPath/validations and friends are just too powerful technologies that make me easily fogive input verbosity. /rant all right, all right. look, it can be worse, I work with people that want everything to be RDF ;-) Oh dear, you have my sympathies. Back when RDF/XML was still a candidate spec. we had a business partner that insisted on using it. Must have at least doubled the size and complexity of the project snip/ -- Peter Hunsberger
Re: Roadmap for Cocoon Blocks
Jorg Heymans wrote: ... 3.0 is a different beast alltogether. Likely we will need an m2 plugin that can compile one block against other blocks using osgi dependency rules (ie using the manifest information). The same goes for dependency resolution, as it needs to be made osgi aware (right Daniel?). So unless he knows a lot about osgi, a block developer will have to use our m2 deployment framework to target 3.0. Or am I seeing this m2-osgi build and deploy time integration too complicated for what it really is ? As long as the build of a bundle only depends on explicit jars and not on other bundles, the build is rather simple. This will be the case in our initial work with OSGi as we work more on bundelizing the existing Cocoon than integrating with external bundles. And for our own blocks we need to take care of the dependendency on libraries anyway. As soon as we want to have the build dependent on other bundles it becomes a little bit more complicated as the build system must be OSGi aware to know what packages in a bundle that will be available for another bundle. Now, even if this happen to be somewhat complex, it probably doesn't need to be a problem for us. Eclipse have allready solved this in theire build system and created external APIs for handling dependency information. I have discussed this question a little bit at the Felix list, and some of the main developers of the Eclipse kernel suggested to use the Eclipse mechanism and seemed to be willing to help making it work. So for the nearest future it will be enough with a rather simple system, like the M2 OSGi plugin at Felix. And when we require a more sophisticated solution, we have a quite clear idea about how to solve that. /Daniel
Re: [Docs] Articles on Cocoon
Actually I had this idea a while ago. The Cocoon bible. Written by the people who wrote it. Having a couple more authors to split the huge task. Uhm. Isn't this what the documentation should be all about? That's what it should be ...and I think we are making good progress. Sylvain showed me the Cocoon docu in a single pdf. That's great. Maybe we just need to revise it a bit from the print perspective and get people to really commit on writing a chapter on certain topics. I just assume having a few people getting there names onto a cover will help with the commitment ;) Instead of doing the FOO-jerk, just make sure our documentation is republish-able in a paper format at all times? ORA even has a series for that: http://www.oreilly.com/oreilly/ author/ch01.html#series and look for community press. Awesome ...that would be the perfect fit! Of course, that's easier said than done. But I stopped dreaming of finding time to write something when I stopped caring for my name on a cover. Hehe cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: [VOTE] Move to Jira (Was: Re: Jira or Bugzilla...)
On 10/11/05, Pier Fumagalli [EMAIL PROTECTED] wrote: Ok, there we go, here's the vote... [ ] +1 Yes please, let's move all our bugs to Jira and set it up to work in the following way: +1 Ciao, -- Gianugo
Re: [Docs] Articles on Cocoon
On 11 Oct 2005, at 15:33, Matthew Langham wrote: I will be at EuroOSCON next week and will see what may be possible to raise the awareness for Cocoon over at O'Reilly. Actually it is a pity no-one submitted a Cocoon talk for that. I did submit a Daisy one with mentioning of Cocoon. Looks like it did miss out on FOO-karma, it seems. Oh well. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought Open Source Java XML stevenn at outerthought.orgstevenn at apache.org
Re: [Docs] Articles on Cocoon
Actually I had this idea a while ago. The Cocoon bible. Written by the people who wrote it. Having a couple more authors to split the huge task. We could even make it an Open Source book. Available as a pdf or in print for the ones who want to hold something in there hands. I would love that... How about a wikibook? I think we can already get that from the daisy installation. (Helma?) cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Concern Creep on the Processor interface
The Processor interface used to be very simple, and reasonably
documented. Over time it has adopted new methods as part of its
contract, and those have not been well documented. The only reason that
I am bringing this up is that I am trying to implement my own Processor,
and there is a lot that the interface requires that is of little or no
concern to me. First lets see what it used to be 2 years and 7 months ago:
interface Processor
{
boolean process(Environment env) throws Exception;
// the remaining methods were introduced in 2.1
ProcessingPipeline processInternal(Environment env) throws Exception;
Configuration getComponentConfigurations();
}
Already we see we added some scope creep from the 2.0 to the 2.1 series
(the last I worked on Cocoon was the 2.0 series). For example, why is
it necessary for a Processor contract to expose the component
configurations? The processInternal method is a coin toss.
Presumably it is to enable cocoon:// or sitemap:// psuedo-protocols to
be more consistent--allowing a parent processor to call
processInternal() on child processors. Nevertheless, one would wonder
why the original process() method wasn't changed to return a
ProcessingPipeline instead of a boolean in this case.
At this point I also want to point out that the original process()
method has decent JavaDocs so that you can understand its purpose and
why it exists, the remaining methods are not that way.
A month later the getComponentConfigurations() method was refactored to
return a Map--presumably of component Configuration objects, but there
is still no documentation on what the expected keys are.
Three months later processInternal was changed to buildPipline (same
arguments and return value)--a better picture but still nothing in the
JavaDocs to help understand the method purpose.
Two months later we add the Processor getRootProcessor() method to
support internal redirects. Now this is one thing that makes Processors
much more difficult to implement. Why can't such a thing be handled by
a ProcessorHelper or something. The root processor problem is
orthagonal to the responsibilities of just one processor.
16 months, 2 weeks ago we had the biggest change to the whole
interface. We have an interface with an internal class?! The
InternalPipelineDescription has a reason for existing, I'm sure.
However I do have to wonder why it is part of the interface. At this
point we are specifying implementation details in the interface. The
contract of the Processor is no longer an active component (i.e. I tell
you how to do something), but a passive one (i.e. I ask you how to do
stuff for myself). The buildPipeline() method is now altered to use the
InternalPipelineDescription instead of return a ProcessingPipeline. At
the same time we add the getContext() and getSourceResolver() methods.
My head is now realing. This is pure insanity. Why not just get rid of
the interface and simply use a base class? After all we are no longer
documenting a contract, we are documenting how to implement the
Processor. My guess is that limitations in the TreeProcessor approach
caused this to be necessary. But again, couldn't most of these things
have been handled by an external helper or utility class? Does it
really need to affect the interface?
11 months, 3 weeks ago we refactored the getComponentConfigurations()
again so that we now have just an array of configurations. Not a biggy,
but I'm still not convinced it is needed here.
3 months ago we have the last change to the Processor interface, and I
am convinced this should have been a TreeProcessor interface that
extends the core Processor interface. We added methods for setting,
getting, and removing attributes for the sitemap interpreters.
The bottom line is that we have exploded the complexity of what was
originally intended to be a light-weight interface. The only solution
for the processor is a complex solution. The only implementation for a
processor is the tree processor. We've made sure that the interface
requires it to be that way. I've got much simpler needs, and there is a
whole host of issues with implementing all these methods that do
nothing. I'd like to see if we can't separate all the different
concerns in the Processor interface into multiple interfaces. What is
the core concerns?
I'm in the process of identifying the real contracts, and I'll have
another post about that.
Re: [VOTE] new committer: Max Pfingsthorn
Bertrand Delacretaz wrote: (and besides that, it will be cool to have more people with difficult names to type ;-) As long as I can call him Max... +1 :-P Vadim
Re: [Docs] Articles on Cocoon
Arje Cahn wrote: I'd be happy to write a piece about knowledge sharing in intranets or on the web. Generating relationships, using team folders, finding articles, using thesauri and taxonomies, etc. Practical stuff that really adds value, no fuzzy knowledge management buzz. Also not about Wiki's (I'll leave that one to Steven ;) ). WDYT? +10 Vadim
Re: Roadmap for Cocoon Blocks
Stefano Mazzocchi wrote: ... One thing, though, remember to also have a LinkRewritingTransformer that is block aware so that we can do style src=block:skin:/styles/main.css/ and this gets translated in the right URL We allready have, see http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/webapp/WEB-INF/blocks/sample/sitemap.xmap?view=markup for configuration of the LinkRewriteTransformer and the link element in the begining of http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/webapp/WEB-INF/blocks/sample/simple-samples2html.xsl?view=markup for a (rather crappy) example of using it. (hopefully relative, so that we don't have issues with webapp proxying, or, if absolute, we need a way to configure where is the cocoon mountpoint as seen from the proxy side) It is absolute right now, but if it is more convenient to have it relative, we can make it relative. It seem a little bit complicated though. We could start with absolutizing the URL of the page that is link rewrited and then absolitize a link and from that calculate the relative path of the link relative to the page. Would that be enough or is there more to it? I'm currently doing http://simile.mit.edu/repository/linotype/trunk/stylesheets/absolutize.xslt with my latest linotype and I can't wait to get rid of all these hacks :-) I have some own applications with such hacks and neither can I wait to get rid of them ;) /Daniel
Re: [RT] Clarifying classloading in 2.2 [was Re: Classloader changes]
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
AFAIU this is the usecase that makes OSGi shine. Shall we really implement this?
Can you please elaborate a little bit on this? Of course, if there is
already something helping us we should use it.
The problem is, that going for what you propose would mean that each block has
to get its own classloader. In Amsterdam we only talked about *one global*
classloader for Cocoon, but maybe I'm wrong here.
When blocks will become OSGi bundles, OSGi will use the meta inforamtion in
META-INF/manifest.mf to setup a correct classloader with
- the internal classes
- the internal libraries
- all required bundles/packages (= resolving dependencies)
and the for a block/bundle.
My point only is that we should keep things simple (= one global classloader)
for 2.2, use M2 and its dependency resoluation mechanisms to ensure that we get
the correct JARs and we shouldn't reimplement what OSGi already offers.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Concern Creep on the Processor interface
As a short answer: yes, the interface is ugly - but on the other hand we
only have one implementation and could remove the interface and directly
interact with the tree processor :)
The reason is more or less a historical one. We needed a clean
implementation for the tree processor and used the fastest approach. For
example the internal class is used to pass all relevant information back
to the client in order to release everything properly. This mechanism
was very ugly and not always working in 2.1.x. And out of similar
reasons I guess more and more was added without really be interested in
having a clean Processor interface.
So, if we can clean it up, yes - but we must take care that resources
and memory are released in a proper and direct way.
Carsten
Berin Loritsch wrote:
The Processor interface used to be very simple, and reasonably
documented. Over time it has adopted new methods as part of its
contract, and those have not been well documented. The only reason that
I am bringing this up is that I am trying to implement my own Processor,
and there is a lot that the interface requires that is of little or no
concern to me. First lets see what it used to be 2 years and 7 months ago:
interface Processor
{
boolean process(Environment env) throws Exception;
// the remaining methods were introduced in 2.1
ProcessingPipeline processInternal(Environment env) throws Exception;
Configuration getComponentConfigurations();
}
Already we see we added some scope creep from the 2.0 to the 2.1 series
(the last I worked on Cocoon was the 2.0 series). For example, why is
it necessary for a Processor contract to expose the component
configurations? The processInternal method is a coin toss.
Presumably it is to enable cocoon:// or sitemap:// psuedo-protocols to
be more consistent--allowing a parent processor to call
processInternal() on child processors. Nevertheless, one would wonder
why the original process() method wasn't changed to return a
ProcessingPipeline instead of a boolean in this case.
At this point I also want to point out that the original process()
method has decent JavaDocs so that you can understand its purpose and
why it exists, the remaining methods are not that way.
A month later the getComponentConfigurations() method was refactored to
return a Map--presumably of component Configuration objects, but there
is still no documentation on what the expected keys are.
Three months later processInternal was changed to buildPipline (same
arguments and return value)--a better picture but still nothing in the
JavaDocs to help understand the method purpose.
Two months later we add the Processor getRootProcessor() method to
support internal redirects. Now this is one thing that makes Processors
much more difficult to implement. Why can't such a thing be handled by
a ProcessorHelper or something. The root processor problem is
orthagonal to the responsibilities of just one processor.
16 months, 2 weeks ago we had the biggest change to the whole
interface. We have an interface with an internal class?! The
InternalPipelineDescription has a reason for existing, I'm sure.
However I do have to wonder why it is part of the interface. At this
point we are specifying implementation details in the interface. The
contract of the Processor is no longer an active component (i.e. I tell
you how to do something), but a passive one (i.e. I ask you how to do
stuff for myself). The buildPipeline() method is now altered to use the
InternalPipelineDescription instead of return a ProcessingPipeline. At
the same time we add the getContext() and getSourceResolver() methods.
My head is now realing. This is pure insanity. Why not just get rid of
the interface and simply use a base class? After all we are no longer
documenting a contract, we are documenting how to implement the
Processor. My guess is that limitations in the TreeProcessor approach
caused this to be necessary. But again, couldn't most of these things
have been handled by an external helper or utility class? Does it
really need to affect the interface?
11 months, 3 weeks ago we refactored the getComponentConfigurations()
again so that we now have just an array of configurations. Not a biggy,
but I'm still not convinced it is needed here.
3 months ago we have the last change to the Processor interface, and I
am convinced this should have been a TreeProcessor interface that
extends the core Processor interface. We added methods for setting,
getting, and removing attributes for the sitemap interpreters.
The bottom line is that we have exploded the complexity of what was
originally intended to be a light-weight interface. The only solution
for the processor is a complex solution. The only implementation for a
processor is the tree processor. We've made sure that the interface
requires it to be that
Re: [RT] Clarifying classloading in 2.2 [was Re: Classloader changes]
Reinhard Poetz wrote: The problem is, that going for what you propose would mean that each block has to get its own classloader. In Amsterdam we only talked about *one global* classloader for Cocoon, but maybe I'm wrong here. No, you're right - I was refering to real blocks with OSGi and then we have a class loader for each block. And this class loader will be paranoid, so my point is that we can already make the one classloader paranoid. When blocks will become OSGi bundles, OSGi will use the meta inforamtion in META-INF/manifest.mf to setup a correct classloader with - the internal classes - the internal libraries - all required bundles/packages (= resolving dependencies) and the for a block/bundle. My point only is that we should keep things simple (= one global classloader) for 2.2, use M2 and its dependency resoluation mechanisms to ensure that we get the correct JARs and we shouldn't reimplement what OSGi already offers. Absolutely :) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: typo in commit R312838
El mar, 11-10-2005 a las 11:04 +0200, Juan Jose Pablos escribió: Hi, Apparently there is a typo on 2.2 for this commit, could anyone apply this patch? Dude, you can apply such patches yourself. You have write access. ;-) salu2 Cheers, cheche documento de texto sencillo adjunto (typoR312838) Index: src/java/org/apache/cocoon/components/thread/ThreadPool.java === --- src/java/org/apache/cocoon/components/thread/ThreadPool.java (revisión: 312838) +++ src/java/org/apache/cocoon/components/thread/ThreadPool.java (copia de trabajo) @@ -125,7 +125,7 @@ * @return Whether a shutDown method has succeeded in terminating all * threads */ -boolean isTerminatedAfterShutdown()); +boolean isTerminatedAfterShutdown(); /** * Execute a command using this pool -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
