Re: [2.1.10] WildcardHelperTestCase fails
Bertrand Delacretaz wrote: > On 12/5/06, Alfred Nathaniel <[EMAIL PROTECTED]> wrote: > >> ...Also there are two distinct copies of WildcardHelperTestCase in >> src/test/org/apache/cocoon/util/test and >> src/test/org/apache/cocoon/matching/helpers which both should go... > > You mean remove the test cases? I wouldn't do that unless the tested > classes are not used anymore. > > Right now, we could just comment out the failing test, which would > have failed on previous releases anyway IIUC (the > WildcardHelperTestCase didn't exist in 2.1.9). > Ok, I removed the usage of the deprecated matching code and replaced it with using the new matcher. In addition I removed the duplicate test case for the WildcardHelper class and commented out the failing test in the remaining test case. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: svn commit: r482168 - in /cocoon/branches/BRANCH_2_1_X: legal/ lib/optional/
Andrew Savory wrote: > Hi, > > On 4 Dec 2006, at 08:27, [EMAIL PROTECTED] wrote: > >> Author: cziegeler >> Date: Mon Dec 4 05:27:17 2006 >> New Revision: 482168 >> >> URL: http://svn.apache.org/viewvc?view=rev&rev=482168 >> Log: >> Update to released version of jackrabbit > > Just curious - Jackrabbit released 1.1.1 yesterday, did you mean to > add that rather than 1.0.1? > > No :) We had an unreleased version of jackrabbit before; as I I'm not sure yet what the difference between 1.0.x and 1.1.x are, I just choose the version which should be "more compatible" to the version we already had. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.1.10] WildcardHelperTestCase fails
On 12/5/06, Alfred Nathaniel <[EMAIL PROTECTED]> wrote: ...Also there are two distinct copies of WildcardHelperTestCase in src/test/org/apache/cocoon/util/test and src/test/org/apache/cocoon/matching/helpers which both should go... You mean remove the test cases? I wouldn't do that unless the tested classes are not used anymore. Right now, we could just comment out the failing test, which would have failed on previous releases anyway IIUC (the WildcardHelperTestCase didn't exist in 2.1.9). -Bertrand
[jira] Closed: (COCOON-1962) Numeric based suggestion list should initialzate to the corresponding suggested text.
[ http://issues.apache.org/jira/browse/COCOON-1962?page=all ] Antonio Gallardo closed COCOON-1962. Fix Version/s: 2.1.10-dev (current SVN) Resolution: Fixed Thanks for the patch. Feel free to reopen the issue if needed. > Numeric based suggestion list should initialzate to the corresponding > suggested text. > - > > Key: COCOON-1962 > URL: http://issues.apache.org/jira/browse/COCOON-1962 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: Forms >Affects Versions: 2.1.10-dev (current SVN) >Reporter: carlos chávez > Assigned To: Antonio Gallardo > Fix For: 2.1.10-dev (current SVN) > > Attachments: CFormsSuggest.txt, CFormsSuggestSample.txt > > > Hello, > If we have a list with a numeric value and a suggested string text, when the > form load at the first time is showing the numeric value instead the > corresponding text. This patch improve the suggestion list to retrieve the > corresponding suggested text from the server when we have the numeric value > when we load the form. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1962) Numeric based suggestion list should initialzate to the corresponding suggested text.
[ http://issues.apache.org/jira/browse/COCOON-1962?page=all ] Antonio Gallardo updated COCOON-1962: - Summary: Numeric based suggestion list should initialzate to the corresponding suggested text. (was: Suggestion List initialization improvement) Description: Hello, If we have a list with a numeric value and a suggested string text, when the form load at the first time is showing the numeric value instead the corresponding text. This patch improve the suggestion list to retrieve the corresponding suggested text from the server when we have the numeric value when we load the form. was: Hello, If we have a list with a numeric value and a suggested string text, when the form load at the first time is showing the numeric value instead the corresponding text. This patch improve the suggestion list to retrieve the corresponding suggested text from the server when we have the numeric value when we load the form. > Numeric based suggestion list should initialzate to the corresponding > suggested text. > - > > Key: COCOON-1962 > URL: http://issues.apache.org/jira/browse/COCOON-1962 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: Forms >Affects Versions: 2.1.10-dev (current SVN) >Reporter: carlos chávez > Assigned To: Antonio Gallardo > Attachments: CFormsSuggest.txt, CFormsSuggestSample.txt > > > Hello, > If we have a list with a numeric value and a suggested string text, when the > form load at the first time is showing the numeric value instead the > corresponding text. This patch improve the suggestion list to retrieve the > corresponding suggested text from the server when we have the numeric value > when we load the form. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Cocoon Wiki] Update of "Riester" by Riester
Joerg Heinicke escribió: I'd have removed the link to not give the spam more success by adding it to further mailing list archives. Clever move! ;) Thanks for providing info about this stuff. I had no idea what it is at all. Initially, I though the site was a cocoon based site, but the html code did not convinced me at all. Anyhow I preferred to check with you folks formore input. I've just removed the page and added anti-spam keywords. I hope it will be enough. :) Best Regards, Antonio Gallardo.
Re: HTML mails (was Re: Building changes into the top level sitemap)
On Dec 5, 2006, at 2:49 PM, Sylvain Wallez wrote: Mark Lundquist wrote: On Dec 5, 2006, at 8:50 AM, Jeremy Quinn wrote: I have just been working on an established project that is built from 2.2 and I could see the advantages of the new platform. Yeah, it's awesome. However, many perceive 2.2 as almost unusable. Well, it /is/ nearly unusable, but I guess that will change very soon. This is why it's not been released yet :-) Mark, from time to time you send mails in HTML. Can you please make sure you send mails in plain text to the list? It will ease the reader's job, as HTML indentation doesn't make it easy to distinguish quoted messages. Ugh, yeah I see what you mean from the snip above. It's actually not HTML email, though... it's a multipart plaintext + RTF email. I see you are using Thunderbird, so... just for fun I fired up Mozilla, brought up the Gmane usenet mirror in the newreader and looked at my message (the one you replied to), and sure enough, it was doing the indenting thing. It appears that Mozilla/T-bird just doesn't render the RTF element in a very useful way, and does not let you configure anything different. Interestingly, plaintext email w/ quoted excerpts using the standard ">" style displays beautifully; Mozilla translates that into a nice gray bar running along the side. You can configure Mozilla to default to that just by checking "View > Message Body As > Plain Text". Try it and then look at my message again, and you should see that it looks just right. cheers, —ml—
Re: [SURVEY] cocoon eventcache block
Ard Schrijvers wrote: Hello, I am wondering if there is anybody using the cocoon eventcache block (without using hippo jars), or are planning to do so in the future? I'm planning to in the near future.
Re: Releases from trunk
Reinhard Poetz wrote: > > I think it's time to release the next milestone of some of our modules: > > - org.apache.cocoon:cocoon(pom) > - org.apache.cocoon:cocoon-core-modules (pom) > - org.apache.cocoon:cocoon-core (jar) > - org.apache.cocoon:cocoon-blocks-modules (pom) > - org.apache.cocoon:cocoon-template (pom) > - org.apache.cocoon:cocoon-flowscript (pom) > - org.apache.cocoon:cocoon-template-impl (jar) > - org.apache.cocoon:cocoon-flowscript-impl(jar) > - org.apache.cocoon:cocoon-blocks-fw (pom) > - org.apache.cocoon:cocoon-blocks-fw-impl (jar) > - org.apache.cocoon:cocoon-tools-modules (pom) > - org.apache.cocoon:cocoon-archetypes (pom) > - org.apache.cocoon:cocoon-22-archetype-block (archetype jar) > > That's the minimal set of artifacts to do something useful with Cocoon and > to follow the getting started guide. I know that we should release some > more blocks (forms, fop, apples, etc.) and the archetype-webapp artifact, > but they need some more polishing. > > I propose that we change the release procedure this time: > The person who performs the release, releases the artifacts into our > staging repository. Then he calls for a vote, open for 72 hours. If the > vote passes, the artifacts are moved to the official Apache sync directory > on people.apache.org. The last step is asking on repository@apache.org to > sync with the Maven central repo. > > Is the list of artifacts and the outlined release procedure okay for > everybody? If yes, I can do the relase on Thuesday, starting in the > afternoon (MET). I am not clear about what is being suggested for this plan. If it is a "milestone" then it should not end up on the public central repository. If it is a "release" then it should be accompanied by the sources, etc. Also it should be on the w.a.o/dist mirrors as well as whatever Maven does. http://www.apache.org/dev/release.html#releases http://www.apache.org/dev/#releases -David
Re: [RT] Improved matching & selecting
On Tue, 2006-12-05 at 07:58 -0800, Mark Lundquist wrote: > On Dec 4, 2006, at 12:46 PM, Alfred Nathaniel wrote: > > Or use different tags, say in resemblance to XSLT: > > > ... > > > > > > I'm not so keen on that, 'cause I'm actually trying to get away from > using 2 different elements for this. Rationale: > > 1) The precedent of and would have conditioned users > to interpret and as referring to two different kinds of > sitemap components ("Iffer"s and "Choose"rs? :-). I'd like the syntax > to emphasize that it's all matching and there is only one component > now, The Matcher. There is no need for a one-to-one relation between sitemap tags and components. (There won't be any Whener in your model either?). So I don't see the problem in using Matcher implementations for more than one tag which is not called map:match. > 2) The sitemap language is not XSLT and has nothing to do with XSLT. > The only relationship is that the sitemap has to do with Cocoon and > Cocoon uses XSLT... big deal! :-) Trying to imitate XSLT in the > sitemap in the interest of familiarity IMHO is misguided and results > in confusion. Things that are different should look and feel > different. For example: in XSLT and , the @test clause > contains a predicate. This is fundamentally different then in the > sitemap, where the corresponding attribute contains a pattern, and the > predicate comprises some kind of (implicit or configured) match of > this pattern against a configured target value. Now the way this is > expressed in the "classic" sitemap, the version puts > this value into an attribute called "test" — probably, again, in > deference to XSLT, and IMHO confusing — while the version puts > it in an attribute called "pattern". But in either case, the > semantics are rather different than XSLT owing to the difference > between "predicate" and "pattern". Well, why not really use XSLT syntax? where wcmatch() and uri() are Cocoon components. > 3) I think XSLT got it wrong :-). They should have used something > like "" for both, and treated @test like I treat @value in > my proposal. An analogy between and a "switch" or "case" > statement is flawed, the correct analogy is to "if()... else if()" — > again, because of the distinction between predicate and pattern! > Switch/case is really like today's !!! "if()..." > inaugurates a conditional using the same keyword regardless of how > many alternatives there are — one, or many. That's how sitemap > matching (which has only patterns) should do it, and that's how XSLT > (which has only predicates) should have done it. No need for two > different keywords. I think we should use two different keywords because otherwise the content model depends on the presence of various attributes and not on the tagname only -- that is really confusing. Whether the keyword pair is match/select or if/choose or cond/switch or something else I don't care too much. > cheers and thx for the feedback :-), > —ml— Cheers, Alfred.
Re: Building changes into the top level sitemap
Simone Gianni skrev: Jeremy Quinn wrote: Documentation would really help. Absolutely! I have just been working on an established project that is built from 2.2 and I could see the advantages of the new platform. However, many perceive 2.2 as almost unusable. It clearly is being used but the procedures are very different from 2.1 . the results can be completely unpredictable . it will compile one minute and not the next, this is very off-putting. If the less experienced developers like myself cannot feel confidant with the build system for 2.2 what hope do we have of users embracing it? IIUC, the users should not build cocoon 2.2, they will just use maven to fetch an archetype, write their sitemaps and stuff there, configure their dependencies, and then use again maven to build it. Maven will fetch cocoon core, all the needed blocks, and produce a war or launch jetty with it. That is normally correct. Right now a user need to compile as there are so many improvements that simplifies usage since the last milestone. But we will hopefully get a new milestone release in the near future. This will make it as easy as you described above to use Cocoon. Another thing that would simplify it for developers to start work with Cocoon 2.2 would be if we went back to have a cocoon-webapp that actually does something. Now we instead have the dist samples that put everything together in a war file. But they are somewhat unstable and as I described in a previous mail, completely unusable for sample development. The cocoon-webapp doesn't contain any samples anymore, so a develper doesn't have any good examples on what a Cocoon development environment looks like anymore. I would propose that we either add some samples to the cocoon-webapp again or that we create some cocoon-sample-webapp to Cocoon that contains some samples. Sorry this is in no way intended as a personal criticism, merely a statement of facts as I perceive them. Same here, nothing wrong at all with the incredible work that has been made on 2.2. The real problem at the moment, in my opinion, are not the users, but the *developers*. I've been using 2.2 in last 4 months, experimenting with it a lot, but still don't know how many things work, things changes continuously, and we (even committers) don't know what still has to be done and how. To my knowledge nothing _has_ to be done on the code. It is perfectly usable as is (although there are of course room for plenty of improvements). What needs to be done is documenting how to use it. And that more people start to use it so that we can find bugs, stabilize it and smoothen ease of usage. It's not a matter of code by itself, or maven, or osgi. OSGi is not used at all, currently. From my PoV, the areas most urgently in need of documentation are : A cookbook for how to develop 2.2 (as you describe) Recipes for starting your own project. Troubleshooting hint for solving common build problems. Agree. Again, absolutely, and I'd like to add also : A clear and detailed roadmap to 2.2 When I have asked earlier no one had any outstanding items that we absolutely must solve. What is lacking is documentation. So what we need is a roadmap for documentation. In some sense we have that also: one can browse http://cocoon.zones.apache.org/dev-docs/ and see what is lacking. There are lots of skeleton documents, so it is just to start filling in the empty sections ;) Much of that can be done by moving documentation from 2.1 to the new documentation and correct it if needed. It is still hard to know where to start. For me at least some kind of documentation road map or priority list would be helpful. So that I could start with what is most important. /Daniel
HTML mails (was Re: Building changes into the top level sitemap)
Mark Lundquist wrote: > > On Dec 5, 2006, at 8:50 AM, Jeremy Quinn wrote: > > I have just been working on an established project that is built > from 2.2 and I could see the advantages of the new platform. > > > Yeah, it's awesome. > > However, many perceive 2.2 as almost unusable. > > > Well, it /is/ nearly unusable, but I guess that will change very soon. > This is why it's not been released yet :-) Mark, from time to time you send mails in HTML. Can you please make sure you send mails in plain text to the list? It will ease the reader's job, as HTML indentation doesn't make it easy to distinguish quoted messages (and also increases the mail's size). Thanks, Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Building changes into the top level sitemap
Jeremy Quinn wrote: On 5 Dec 2006, at 14:04, Daniel Fagerstrom wrote: Jeremy Quinn skrev: Hi Guys I am trying to get support for the new Upload Progress Bar working in Cocoon 2.2. I need to add a new system pipeline to the top-level sitemap, like (and adjacent to) the one that handles : this is the snippet : prefix="_cocoon/system/"/> The purpose is to mount Block-Level system pipelines. I /think/ the place I make this change is in : /core/cocoon-webapp/src/main/webapp/sitemap.xmap (But TBH I am not sure) Yes, that should be the place. Good :) Next I am trying to get this compiled in, so that it is available for the 'cocoon-dist-samples' and everything else that may be built from this distribution. I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : core/cocoon-webapp/ dists/cocoon-dist-samples/ Neither results in the changes happening to the file at : dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap TBH I find this new build system so deeply opaque, I do not know where to start solving this. What am I supposed to do ? First, the dist samples (cocoon-dist-samples, cocoon-dist- publishing) are really just distribution samples. They just unpack and package together the cocoon-webapp and samples and implementations from the various blocks. For development of samples it would be really inconvenient to work from the dist samples as you would need to rebuild about the whole trunk after each change. OK So what I would recommend to do is to start from the cocoon-webapp instead and to add (locally) all the block samples you need for your work, as dependencies to cocoon-webapp. What happens then is that during startup Cocoon will find all the COB-INF directories from the block samples from the class path. From here two different things can happen: if the block is in a jar at the class path, the COB-INF directory of the block will be unpacked in a blocks/ directory in the temp directory of the servlet container. If the block is in a class directory (if you devolop in Eclipse e.g. and your cocoon-webapp depends on another block project), Cocoon will read directly from the block without any unpacking. All this is done by using a new blockcontext protocol that is aware of the locations of the blocks (see http://marc.theaimsgroup.com/? l=xml-cocoon-dev&m=116326232408386&w=2). So the above should hopefully make it easier to work on making the new stuff functional. After that you can try to compile the dist samples and see if it works in them as well. The above described functionality actually make it easier and faster than ever to develop samples, as you can test them without any copying or jetty restarts at all in Eclipse. But some documentation about this would probably not hurt ;) Documentation would really help. I have just been working on an established project that is built from 2.2 and I could see the advantages of the new platform. However, many perceive 2.2 as almost unusable. It clearly is being used but the procedures are very different from 2.1 . the results can be completely unpredictable . it will compile one minute and not the next, this is very off-putting. If the less experienced developers like myself cannot feel confidant with the build system for 2.2 what hope do we have of users embracing it? Sorry this is in no way intended as a personal criticism, merely a statement of facts as I perceive them. From my PoV, the areas most urgently in need of documentation are : A cookbook for how to develop 2.2 (as you describe) Recipes for starting your own project. I am trying to learn and compile information in that direction (Recipes). e.g. in "How to run block built with cocoon-22-archetype-block" thread Reinhard suggested me a "Getting started in 5 minutes document that explains how to connect to another block and how to use inheritance" would be welcome. I am not there yet but I am very willing to archieve that in the near future. So please bear with my user stupid questions to come :) Looking forward to test the AJAX upload widget ! Patrick Troubleshooting hint for solving common build problems. Reading the Maven2 manual as Giacomo suggested, may well help :) but that still leaves understanding how 2.2 performs it's built using Maven. Thanks for your reply :) regards Jeremy
Re: Building changes into the top level sitemap
Jeremy Quinn wrote: > Documentation would really help. Absolutely! > > I have just been working on an established project that is built from > 2.2 and I could see the advantages of the new platform. > > However, many perceive 2.2 as almost unusable. It clearly is being > used but the procedures are very different from 2.1 . the results > can be completely unpredictable . it will compile one minute and > not the next, this is very off-putting. If the less experienced > developers like myself cannot feel confidant with the build system for > 2.2 what hope do we have of users embracing it? IIUC, the users should not build cocoon 2.2, they will just use maven to fetch an archetype, write their sitemaps and stuff there, configure their dependencies, and then use again maven to build it. Maven will fetch cocoon core, all the needed blocks, and produce a war or launch jetty with it. > > Sorry this is in no way intended as a personal criticism, merely a > statement of facts as I perceive them. Same here, nothing wrong at all with the incredible work that has been made on 2.2. The real problem at the moment, in my opinion, are not the users, but the *developers*. I've been using 2.2 in last 4 months, experimenting with it a lot, but still don't know how many things work, things changes continuously, and we (even committers) don't know what still has to be done and how. It's not a matter of code by itself, or maven, or osgi. > > From my PoV, the areas most urgently in need of documentation are : > > A cookbook for how to develop 2.2 (as you describe) > Recipes for starting your own project. > Troubleshooting hint for solving common build problems. Again, absolutely, and I'd like to add also : A clear and detailed roadmap to 2.2 Currently about 3 to 5 people are *really working* on 2.2. Many other people (me for example) would like to contribute more, but we don't know exactly what has to be done. It would be a good idea, IMO, to stop developing for a few days, share knowledge with others (documentation and roadmap), assign roles to people (by block?), so that the 3/4 days "lost" by a small group in producing documenta can be recovered by a joint effort of more people. WDYT? Simone
Re: [2.1.10] WildcardHelperTestCase fails
On Tue, 2006-12-05 at 11:02 +0100, Carsten Ziegeler wrote: > Afaik, the code for the wildcard helper has been replaced after that by > someone else. > > Carsten > Bertrand Delacretaz wrote: > > Just tried to run the junit tests on BRANCH_2_1_X, and the second > > assertion in WildcardHelperTestCase fails: > > > > public void testEndPattern() throws Exception { WildcardHelper is rotten and has been deprecated in favor of WildcardMatcherHelper. However, WildcardHelper is still used by CocoonBean and portal's UserRightService. Anyone who knows these two classes and could clean them out? Also there are two distinct copies of WildcardHelperTestCase in src/test/org/apache/cocoon/util/test and src/test/org/apache/cocoon/matching/helpers which both should go. Cheers, Alfred.
[FYI] m2-ibiblio-rsync-repository sync times
(forwarded from repository@) it starts every four hours, starting at 0 CST On 12/5/06, Jorg Heymans <[EMAIL PROTECTED]> wrote: > > I don't know if this came up before, but is it documented somewhere at > which times this automatic sync occurs? It would help projects to avoid > releasing during a sync. > > Jorg > > Reinhard Poetz wrote: As you can see from the message below, m2-ibiblio-rsync-repository is automatically synchronized with the central Maven repository. No need for sync requests on repository@apache.org anymore. (This makes a staging repository even more necessary and useful.) Subject: Re: Sync Request: Apache MINA 1.0.1 From: "Carlos Sanchez" <[EMAIL PROTECTED]> Date: Mon, 4 Dec 2006 22:37:47 -0800 To: repository@apache.org To: repository@apache.org now it's automatic On 12/4/06, Trustin Lee <[EMAIL PROTECTED]> wrote: Hello, Please sync the latest release of Apache MINA to the mirrors. The groupId is org.apache.mina. Thank you in advance, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: Releasing 2.1.10
hepabolu wrote: If there are no outstanding issues I will assemble a release next monday (11th), put it up for downloading and testing and if nothing bad happens do the release of that assembled version on monday, 18th. +0, won't be able to help though +1 , I can't be of much help either though sorry.. Jorg
Re: Updating POM versions throughout our codebase
2006/12/5, Reinhard Poetz <[EMAIL PROTECTED]>: I forgot one thing to ask: Do we already have a script that updates all dependencies of a library/module to a new version? Without it, it isn't really fun to do a release. If not, help is more than appreciated! See https://issues.apache.org/jira/browse/COCOON-1890. If you need some help just ask ... (I can't do the release today as I don't have enough time. I will let you know as soon as I have time, if nobody is faster than me!) -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach -- Andreas
Re: Building changes into the top level sitemap
On Dec 5, 2006, at 8:50 AM, Jeremy Quinn wrote: I have just been working on an established project that is built from 2.2 and I could see the advantages of the new platform. Yeah, it's awesome. However, many perceive 2.2 as almost unusable. Well, it is nearly unusable, but I guess that will change very soon. This is why it's not been released yet :-) It clearly is being used but the procedures are very different from 2.1 . the results can be completely unpredictable . it will compile one minute and not the next, this is very off-putting. If the less experienced developers like myself cannot feel confidant with the build system for 2.2 what hope do we have of users embracing it? My point would be, don't assume that "nearly unusable" implies a great gap to be crossed to reach "fully usable". My impression is that trunk isn't pervasively unstable, it's just unstable at a few key points, and those are being ironed out by the people who also know how to work around, etc. and also how to just plain use the frigging thing without any documention. So trunk right now is like riding a wild bear, and there's only a few people who know how to ride the bear. Two things to do: (1) tame the bear, and (2) teach ordinary people how to ride a tame bear! This is my observation as a relative outsider, i.e. non-wild-bear-rider. My impression is that (1) is very close. I'm trying to learn now (even though the bear is still a little bit wild), so that I can help with (2). —ml—
Re: i18nTransformer problems with static pages
Sorry Piotr, which version of IE are you using? I can see pages containing xmlns declarations with all IE versions I have here in my office. Quite commonly the "blank page in IE" is caused by a head like this : IE is intelligent enought to think that the full page is a title. This happens at least in versions 5.x of IE, and generating such a head is pretty simple : Are you sure the problem is the attribute? Cause if not we are talking about a nice feature but absolutely non blocking and by far not a priority. Simone falcorn wrote: > I removed dtd declaration and xml:space attribute has gone; > But there is declaration of xmlns:i18n at html tag. > And IE dosen't like this attribute. I get blank page. > In FF everything is correct, I only get some warrnings from Tidy that there > is not standard attribute at html tag: xmlns:i18n > greetings > Piotr Idzikowski >
Re: i18nTransformer problems with static pages
Ard Schrijvers wrote: ...I replaced this xsl transformer with a custom StripNameSpacesTransformer (about just 10 lines), which outperforms the slow xsl transformation a factor 30... This would be useful to have in Cocoon, go for it! I thought it was too trivial :-) There is also less trivial CleanupTransformer [1]. It is overkill though for simple namespace stripping. Vadim [1] http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/CleanupTransformer.html
Re: svn commit: r482168 - in /cocoon/branches/BRANCH_2_1_X: legal/ lib/optional/
Hi, On 4 Dec 2006, at 08:27, [EMAIL PROTECTED] wrote: Author: cziegeler Date: Mon Dec 4 05:27:17 2006 New Revision: 482168 URL: http://svn.apache.org/viewvc?view=rev&rev=482168 Log: Update to released version of jackrabbit Just curious - Jackrabbit released 1.1.1 yesterday, did you mean to add that rather than 1.0.1? cocoon/branches/BRANCH_2_1_X/lib/optional/jackrabbit- core-1.0.1.jar (with props) Thanks, 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/ Sourcesense: http://www.sourcesense.com/
Re: [SURVEY] cocoon eventcache block
Ard Schrijvers wrote: Hello, I am wondering if there is anybody using the cocoon eventcache block (without using hippo jars), or are planning to do so in the future? Not using over here. However I was thinking of doing some work on reducing coupling between eventcache and other blocks. Vadim
Re: i18nTransformer problems with static pages
On Dec 5, 2006, at 9:29 AM, Simone Gianni wrote: Yep, the problem with this approach is that you manage to know if a namespace declaration has been used only when you reach the end of the document (after checking that no element used it) Yeah, it takes two passes. Better to declare up-front which namespaces to preserve... What i was proposing would be simply to enable it by default (already too many options in cocoon, and if a page containing a i18n namespace declaration is not visualized by IE, by default cocoon should not send it), but limit it's influence on a set of namespaces (all namespaces http://cocoon.apache.org for example) and eventually have this set configurable by the user so that there will be no need in the future for remove-that-certain-unwanted-ns.xsl files :D I'm not keen on magic or specialness based on either (a) IE misbehavior, or (b) cocoon URIs. Anyway, like you have said, this thing is starting to have too many options for "common feature of XML/HTML serializers"... I'm now leaning back toward the idea of a transformer. The objection that it's onerous to include this transformer "in every pipeline" is weak, because (a) it doesn't have to be "in every pipeline", only in final presentation pipelines, and (b) you'd naturally factor that and the serializer into a anyway. How about a NamspaceTransformer, configured with URI . . . Where: 1) If is present, then the null NS is the default NS 2) Otherwise, the NS with @default="true" is the default NS (more than 1 such = error, or > 0 if we have 3) @prefix is optional; if not set, then use the first prefix found for the NS 4) The transformer writes all the namespace declarations into the root element, deletes them from any descendant elements 5) If a namespace is found that is not in the configured , throw an error How does that sound? —ml—
[jira] Updated: (COCOON-1964) Redirects inside a block called via the blocks protocol fail
[ http://issues.apache.org/jira/browse/COCOON-1964?page=all ] Alexander Klimetschek updated COCOON-1964: -- Attachment: cocoon-allow-redirect-in-called-block.patch Affects only the cocoon-blocks-fw-impl module. > Redirects inside a block called via the blocks protocol fail > > > Key: COCOON-1964 > URL: http://issues.apache.org/jira/browse/COCOON-1964 > Project: Cocoon > Issue Type: Bug > Components: - Blocks Framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Alexander Klimetschek > Attachments: cocoon-allow-redirect-in-called-block.patch > > > If you do a redirect (from within a piece of flowscript > "cocoon.redirectTo('cocoon:/foobar')" or via redirect-to in the sitemap) > inside a block that was called via the block: protocol will fail since the > re-use of the outputstream of the response (which happens to be a > BlockCallHttpServletResponse) does not work. > This is due to the use of getWriter() after getOutputStream() has already > been called. The servlet api says that only one of them should be called, so > there is a check in the implementation of getWriter() that will throw an > IllegalStateException. The patch removes that check, which is kinda hack, but > I don't know of any other cases within cocoon where such a re-use is made. > The problem could be avoided if during the redirect a reset() or > resetBuffer() would be called on the response, but for some reason this does > not happen with a redirect from within a flowscript for a form. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1964) Redirects inside a block called via the blocks protocol fail
Redirects inside a block called via the blocks protocol fail Key: COCOON-1964 URL: http://issues.apache.org/jira/browse/COCOON-1964 Project: Cocoon Issue Type: Bug Components: - Blocks Framework Affects Versions: 2.2-dev (Current SVN) Reporter: Alexander Klimetschek If you do a redirect (from within a piece of flowscript "cocoon.redirectTo('cocoon:/foobar')" or via redirect-to in the sitemap) inside a block that was called via the block: protocol will fail since the re-use of the outputstream of the response (which happens to be a BlockCallHttpServletResponse) does not work. This is due to the use of getWriter() after getOutputStream() has already been called. The servlet api says that only one of them should be called, so there is a check in the implementation of getWriter() that will throw an IllegalStateException. The patch removes that check, which is kinda hack, but I don't know of any other cases within cocoon where such a re-use is made. The problem could be avoided if during the redirect a reset() or resetBuffer() would be called on the response, but for some reason this does not happen with a redirect from within a flowscript for a form. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 17:38, Jeremy Quinn wrote: Am I looking in the right place? OK, so as Jetty starts up, it reports that it loads ~/.m2/repository/ org/apache/cocoon/cocoon-ajax-impl/1.0.0-M2-SNAPSHOT/cocoon-ajax- impl-1.0.0-M2-SNAPSHOT.jar. I can confirm that the system resources I seek exist there too. regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
OK, so even though I could not get $ mvn package to run inside the dists/cocoon-dist-samples, I found that the changes to the top-level sitemap from core/cocoon-webapp/ had in fact been added to the sitemap at : dists/cocoon-dist-samples/target/cocoon-samples/ sitemap.xmap I was able to start Jetty in : dists/cocoon-dist-samples When I went to http://localhost:/_cocoon/system/ajax/upload/ status I get this error : java.io.FileNotFoundException: Could not open ServletContext resource [/resource://org/apache/cocoon/ajax/system/sitemap.xmap] Why should it say "/resource://" ? (the leading slash is not in the sitemap.) Doing a $ jar -tf dists/cocoon-dist-samples/target/cocoon-samples/WEB- INF/lib/cocoon-ajax-impl-1.0.0-M2-SNAPSHOT.jar I see all of the new stuff that is needed : . . . org/apache/cocoon/ajax/system/i18n/messages.xml org/apache/cocoon/ajax/system/sitemap.xmap org/apache/cocoon/ajax/system/System.JSON.js org/apache/cocoon/ajax/system/System.Upload.js . . . Am I looking in the right place? Thanks regards Jeremy On 5 Dec 2006, at 17:08, Jeremy Quinn wrote: On 5 Dec 2006, at 13:42, Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Quinn wrote: I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : You probably have to use 'mvn install' as 'mvn package' only build the jar in you target folder of the block whareas you'll need it to be installed into your local repository so other parts of the build system can take them from there. Ever since I ran $ mvn install in core/cocoon-webapp/, I cannot get $ mvn package to work in dists/cocoon-dist-samples/. No matter how many times I run it (I also went back and did a complete clean install from root) I get this from the build : smime.p7s Description: S/MIME cryptographic signature
[jira] Updated: (COCOON-1963) Add a redirect action to the browser update handler
[ http://issues.apache.org/jira/browse/COCOON-1963?page=all ] Alexander Klimetschek updated COCOON-1963: -- Attachment: RedirectTransformer.java The RedirectTransformer with a different package name. Should IMHO go into cocoon ajax, just next to the BrowserUpdateTransformer. > Add a redirect action to the browser update handler > --- > > Key: COCOON-1963 > URL: http://issues.apache.org/jira/browse/COCOON-1963 > Project: Cocoon > Issue Type: New Feature > Components: Blocks: Ajax >Affects Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) >Reporter: Alexander Klimetschek > Attachments: BUHandler.js, RedirectTransformer.java > > > In some situations you want to redirect the browser to a different page > inside a cforms action, eg. you have a REST-style interface and create > something under the URL /new (which shows a form to enter your new data) and > on save you want to redirect the user to a page where that new data is stored > (e.g. /foobar42). To do so in an ajax-environment, where the save action will > be answered with a browser-update XML snippet, you need a separate action in > the browser update handler. This patch adds the handling of a simple > "redirect" action to the BUHandler.js: > > > > If you want to have a fallback solution for non-AJAX cases, you need to > trigger a normal HTTP redirect from your pipeline. This must happen when this > bu:redirect is inside the XML stream, otherwise all content should be > serialized to the browser. That functionality is provided by the attached > RedirectTransformer. The usage would be like: > > > > > > The server-side javascript snippet for the save action should look like (form > is the Form object and documentID="foobar42"): > if (newDocument) { > form.getWidget().endProcessing(false); > cocoon.redirectTo("cocoon:/redirectTo/" + documentID); > } > There should be a pipeline that matches "/redirectTo/*" and that serves the > bu:document like above (eg. via a jx template to insert the documentID). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1963) Add a redirect action to the browser update handler
[ http://issues.apache.org/jira/browse/COCOON-1963?page=all ] Alexander Klimetschek updated COCOON-1963: -- Attachment: BUHandler.js Not a patch, but the entire new version of BUHandler.js (sorry, but I currently don't have the environment to test it out directly in cocoon-ajax) > Add a redirect action to the browser update handler > --- > > Key: COCOON-1963 > URL: http://issues.apache.org/jira/browse/COCOON-1963 > Project: Cocoon > Issue Type: New Feature > Components: Blocks: Ajax >Affects Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) >Reporter: Alexander Klimetschek > Attachments: BUHandler.js > > > In some situations you want to redirect the browser to a different page > inside a cforms action, eg. you have a REST-style interface and create > something under the URL /new (which shows a form to enter your new data) and > on save you want to redirect the user to a page where that new data is stored > (e.g. /foobar42). To do so in an ajax-environment, where the save action will > be answered with a browser-update XML snippet, you need a separate action in > the browser update handler. This patch adds the handling of a simple > "redirect" action to the BUHandler.js: > > > > If you want to have a fallback solution for non-AJAX cases, you need to > trigger a normal HTTP redirect from your pipeline. This must happen when this > bu:redirect is inside the XML stream, otherwise all content should be > serialized to the browser. That functionality is provided by the attached > RedirectTransformer. The usage would be like: > > > > > > The server-side javascript snippet for the save action should look like (form > is the Form object and documentID="foobar42"): > if (newDocument) { > form.getWidget().endProcessing(false); > cocoon.redirectTo("cocoon:/redirectTo/" + documentID); > } > There should be a pipeline that matches "/redirectTo/*" and that serves the > bu:document like above (eg. via a jx template to insert the documentID). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1963) Add a redirect action to the browser update handler
Add a redirect action to the browser update handler --- Key: COCOON-1963 URL: http://issues.apache.org/jira/browse/COCOON-1963 Project: Cocoon Issue Type: New Feature Components: Blocks: Ajax Affects Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) Reporter: Alexander Klimetschek In some situations you want to redirect the browser to a different page inside a cforms action, eg. you have a REST-style interface and create something under the URL /new (which shows a form to enter your new data) and on save you want to redirect the user to a page where that new data is stored (e.g. /foobar42). To do so in an ajax-environment, where the save action will be answered with a browser-update XML snippet, you need a separate action in the browser update handler. This patch adds the handling of a simple "redirect" action to the BUHandler.js: If you want to have a fallback solution for non-AJAX cases, you need to trigger a normal HTTP redirect from your pipeline. This must happen when this bu:redirect is inside the XML stream, otherwise all content should be serialized to the browser. That functionality is provided by the attached RedirectTransformer. The usage would be like: The server-side javascript snippet for the save action should look like (form is the Form object and documentID="foobar42"): if (newDocument) { form.getWidget().endProcessing(false); cocoon.redirectTo("cocoon:/redirectTo/" + documentID); } There should be a pipeline that matches "/redirectTo/*" and that serves the bu:document like above (eg. via a jx template to insert the documentID). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: i18nTransformer problems with static pages
Mark Lundquist wrote: > > Is there ever a need to retain namespace declarations for namespaces > that are not actually used in the result document, i.e. for which > there is no element with that namespace? I think the idea is to just > delete extraneous namespace declarations, not to delete them all... Yep, the problem with this approach is that you manage to know if a namespace declaration has been used only when you reach the end of the document (after checking that no element used it), while the declaration is quite commonly on the root element. Buffering all the SAX event for each html page served by cocoon would be a problem :) What i was proposing would be simply to enable it by default (already too many options in cocoon, and if a page containing a i18n namespace declaration is not visualized by IE, by default cocoon should not send it), but limit it's influence on a set of namespaces (all namespaces http://cocoon.apache.org for example) and eventually have this set configurable by the user so that there will be no need in the future for remove-that-certain-unwanted-ns.xsl files :D Simone
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 13:42, Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Quinn wrote: I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : You probably have to use 'mvn install' as 'mvn package' only build the jar in you target folder of the block whareas you'll need it to be installed into your local repository so other parts of the build system can take them from there. Ever since I ran $ mvn install in core/cocoon-webapp/, I cannot get $ mvn package to work in dists/cocoon-dist-samples/. No matter how many times I run it (I also went back and did a complete clean install from root) I get this from the build : [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.war.AbstractWarMojo.unpack (AbstractWarMojo.java:704) at org.apache.maven.plugin.war.AbstractWarMojo.unpackWarToTempDirectory (AbstractWarMojo.java:680) at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp (AbstractWarMojo.java:600) at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp (AbstractWarMojo.java:379) at org.apache.cocoon.maven.deployer.AbstractDeployMojo.deployMonolithicCoco onAppAsWebapp(AbstractDeployMojo.java:182) at org.apache.cocoon.maven.deployer.DeployExplodedMojo.execute (DeployExplodedMojo.java:64) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java: 322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced (Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) And of course I don't have a clue where to start looking . regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: i18nTransformer problems with static pages
On 12/5/06, Mark Lundquist <[EMAIL PROTECTED]> wrote: On Dec 5, 2006, at 8:38 AM, Simone Gianni wrote: > Care is required : some emerging internet standards (XForms for > example, > but also others) do require namespaces, so : > - Okay for the HTML serializer > - Not okay for the Xhtml serializer, in this case eventually provide a > list of namespaces to remove, and by default fill this list with > namespaces from cocoon. > - Obviously not for the XML output (note that xhtml and xml serializer > are the same class) Is there ever a need to retain namespace declarations for namespaces that are not actually used in the result document, i.e. for which there is no element with that namespace? I think the idea is to just delete extraneous namespace declarations, not to delete them all... I could see both options. There are some cases where I really don't need any namespaced elements at all on my output (eg, stuff I'm manipulating for AJAX code). We strip them out with XSLT at the moment, but... -- Peter Hunsberger
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 16:25, Reinhard Poetz wrote: Jeremy Quinn wrote: On 5 Dec 2006, at 13:49, Reinhard Poetz wrote: For system resources we should provide a "system-resources" block. For now it could be mounted at "_cocoon", later we should install a LinkRewritingTransformer that is aware of blocks. The idea was that any block could provide a system pipeline. In this case, the system pipeline is provided by the Ajax Block. This shouldn't be a problem because from the "Java level" POV there is no concept of blocks. Good, that is what I thought. Thanks. regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 14:04, Daniel Fagerstrom wrote: Jeremy Quinn skrev: Hi Guys I am trying to get support for the new Upload Progress Bar working in Cocoon 2.2. I need to add a new system pipeline to the top-level sitemap, like (and adjacent to) the one that handles : this is the snippet : prefix="_cocoon/system/"/> The purpose is to mount Block-Level system pipelines. I /think/ the place I make this change is in : /core/cocoon-webapp/src/main/webapp/sitemap.xmap (But TBH I am not sure) Yes, that should be the place. Good :) Next I am trying to get this compiled in, so that it is available for the 'cocoon-dist-samples' and everything else that may be built from this distribution. I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : core/cocoon-webapp/ dists/cocoon-dist-samples/ Neither results in the changes happening to the file at : dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap TBH I find this new build system so deeply opaque, I do not know where to start solving this. What am I supposed to do ? First, the dist samples (cocoon-dist-samples, cocoon-dist- publishing) are really just distribution samples. They just unpack and package together the cocoon-webapp and samples and implementations from the various blocks. For development of samples it would be really inconvenient to work from the dist samples as you would need to rebuild about the whole trunk after each change. OK So what I would recommend to do is to start from the cocoon-webapp instead and to add (locally) all the block samples you need for your work, as dependencies to cocoon-webapp. What happens then is that during startup Cocoon will find all the COB-INF directories from the block samples from the class path. From here two different things can happen: if the block is in a jar at the class path, the COB-INF directory of the block will be unpacked in a blocks/ directory in the temp directory of the servlet container. If the block is in a class directory (if you devolop in Eclipse e.g. and your cocoon-webapp depends on another block project), Cocoon will read directly from the block without any unpacking. All this is done by using a new blockcontext protocol that is aware of the locations of the blocks (see http://marc.theaimsgroup.com/? l=xml-cocoon-dev&m=116326232408386&w=2). So the above should hopefully make it easier to work on making the new stuff functional. After that you can try to compile the dist samples and see if it works in them as well. The above described functionality actually make it easier and faster than ever to develop samples, as you can test them without any copying or jetty restarts at all in Eclipse. But some documentation about this would probably not hurt ;) Documentation would really help. I have just been working on an established project that is built from 2.2 and I could see the advantages of the new platform. However, many perceive 2.2 as almost unusable. It clearly is being used but the procedures are very different from 2.1 . the results can be completely unpredictable . it will compile one minute and not the next, this is very off-putting. If the less experienced developers like myself cannot feel confidant with the build system for 2.2 what hope do we have of users embracing it? Sorry this is in no way intended as a personal criticism, merely a statement of facts as I perceive them. From my PoV, the areas most urgently in need of documentation are : A cookbook for how to develop 2.2 (as you describe) Recipes for starting your own project. Troubleshooting hint for solving common build problems. Reading the Maven2 manual as Giacomo suggested, may well help :) but that still leaves understanding how 2.2 performs it's built using Maven. Thanks for your reply :) regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: i18nTransformer problems with static pages
On Dec 5, 2006, at 8:38 AM, Simone Gianni wrote: Care is required : some emerging internet standards (XForms for example, but also others) do require namespaces, so : - Okay for the HTML serializer - Not okay for the Xhtml serializer, in this case eventually provide a list of namespaces to remove, and by default fill this list with namespaces from cocoon. - Obviously not for the XML output (note that xhtml and xml serializer are the same class) Is there ever a need to retain namespace declarations for namespaces that are not actually used in the result document, i.e. for which there is no element with that namespace? I think the idea is to just delete extraneous namespace declarations, not to delete them all... —ml—
Re: i18nTransformer problems with static pages
On 12/5/06, Simone Gianni <[EMAIL PROTECTED]> wrote: Peter Hunsberger wrote: > Instead of requiring that an extra transformer be added to the > pipeline would it make sense to add this capability as a configuration > option on the HTML/XHTML serializers? > Care is required : some emerging internet standards (XForms for example, but also others) do require namespaces, so : - Okay for the HTML serializer - Not okay for the Xhtml serializer, in this case eventually provide a list of namespaces to remove, and by default fill this list with namespaces from cocoon. Umm, that's why it would be an _option_... (obviously not the default). - Obviously not for the XML output (note that xhtml and xml serializer are the same class) -- Peter Hunsberger
Re: i18nTransformer problems with static pages
Peter Hunsberger wrote: > Instead of requiring that an extra transformer be added to the > pipeline would it make sense to add this capability as a configuration > option on the HTML/XHTML serializers? > Care is required : some emerging internet standards (XForms for example, but also others) do require namespaces, so : - Okay for the HTML serializer - Not okay for the Xhtml serializer, in this case eventually provide a list of namespaces to remove, and by default fill this list with namespaces from cocoon. - Obviously not for the XML output (note that xhtml and xml serializer are the same class) Simone
Re: Building changes into the top level sitemap
Jeremy Quinn wrote: On 5 Dec 2006, at 13:49, Reinhard Poetz wrote: For system resources we should provide a "system-resources" block. For now it could be mounted at "_cocoon", later we should install a LinkRewritingTransformer that is aware of blocks. The idea was that any block could provide a system pipeline. In this case, the system pipeline is provided by the Ajax Block. This shouldn't be a problem because from the "Java level" POV there is no concept of blocks. -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 13:49, Reinhard Poetz wrote: Jeremy Quinn wrote: Hi Guys I am trying to get support for the new Upload Progress Bar working in Cocoon 2.2. I need to add a new system pipeline to the top-level sitemap, like (and adjacent to) the one that handles : this is the snippet : prefix="_cocoon/system/"/> The purpose is to mount Block-Level system pipelines. I /think/ the place I make this change is in : /core/cocoon-webapp/src/main/webapp/sitemap.xmap (But TBH I am not sure) Next I am trying to get this compiled in, so that it is available for the 'cocoon-dist-samples' and everything else that may be built from this distribution. I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : core/cocoon-webapp/ dists/cocoon-dist-samples/ Neither results in the changes happening to the file at : dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap TBH I find this new build system so deeply opaque, I do not know where to start solving this. What am I supposed to do ? Thanks for any suggestions One of our problems is that we use the styling resources from cocoon-webapp. We have to move all styling related things into cocoon-samples-style-default and use it from all our sample blocks instead of using the infamous context protocol. For system resources we should provide a "system-resources" block. For now it could be mounted at "_cocoon", later we should install a LinkRewritingTransformer that is aware of blocks. The idea was that any block could provide a system pipeline. In this case, the system pipeline is provided by the Ajax Block. One problem with these changes is, that they are incomptable with 2.1. As we are sharing them across both versions. For this reason I propose to create a cocoon-forms-samples-22 block that makes use of blocks and we have the opportunity to tidy up a bit. AFAICS this is the one and only change required to support Upload Progress that is not shared by Trunk and Branch. regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 13:42, Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Quinn wrote: I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : You probably have to use 'mvn install' as 'mvn package' only build the jar in you target folder of the block whareas you'll need it to be installed into your local repository so other parts of the build system can take them from there. OK, Thanks, I am trying that now . Getting NPEs from org.apache.maven.plugin.war.AbstractWarMojo.unpack (AbstractWarMojo.java:704) now while trying to run $ mvn install or $ mvn package in dists/cocoon-dist-samples/ Trying a complete clean install from scratch. (Why does this happen in such an unpredictable way ?) core/cocoon-webapp/ dists/cocoon-dist-samples/ Neither results in the changes happening to the file at : dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap TBH I find this new build system so deeply opaque, I do not know where to start solving this. Read the Maven Manuals as you've read the Ant one years ago :-) Excuse the mild sarcasm, but I never actually had to read the Ant manual to develop for Cocoon 2.1 :-) Thanks for your reply regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: i18nTransformer problems with static pages
On Dec 5, 2006, at 7:35 AM, Peter Hunsberger wrote: Instead of requiring that an extra transformer be added to the pipeline would it make sense to add this capability as a configuration option on the HTML/XHTML serializers? +1 IIRC this very thing was proposed some time ago and either rejected for some reason, or just didn't happen. I think it's a great idea, but it'd be worth a troll through the archives to see if there isn't some compelling reason not to. —ml—
Re: [RT] Improved matching & selecting
Hi Alfred, On Dec 4, 2006, at 12:46 PM, Alfred Nathaniel wrote: Or use different tags, say in resemblance to XSLT: ... I'm not so keen on that, 'cause I'm actually trying to get away from using 2 different elements for this. Rationale: 1) The precedent of and would have conditioned users to interpret and as referring to two different kinds of sitemap components ("Iffer"s and "Choose"rs? :-). I'd like the syntax to emphasize that it's all matching and there is only one component now, The Matcher. 2) The sitemap language is not XSLT and has nothing to do with XSLT. The only relationship is that the sitemap has to do with Cocoon and Cocoon uses XSLT... big deal! :-) Trying to imitate XSLT in the sitemap in the interest of familiarity IMHO is misguided and results in confusion. Things that are different should look and feel different. For example: in XSLT and , the @test clause contains a predicate. This is fundamentally different then in the sitemap, where the corresponding attribute contains a pattern, and the predicate comprises some kind of (implicit or configured) match of this pattern against a configured target value. Now the way this is expressed in the "classic" sitemap, the version puts this value into an attribute called "test" — probably, again, in deference to XSLT, and IMHO confusing — while the version puts it in an attribute called "pattern". But in either case, the semantics are rather different than XSLT owing to the difference between "predicate" and "pattern". 3) I think XSLT got it wrong :-). They should have used something like "" for both, and treated @test like I treat @value in my proposal. An analogy between and a "switch" or "case" statement is flawed, the correct analogy is to "if()... else if()" — again, because of the distinction between predicate and pattern! Switch/case is really like today's !!! "if()..." inaugurates a conditional using the same keyword regardless of how many alternatives there are — one, or many. That's how sitemap matching (which has only patterns) should do it, and that's how XSLT (which has only predicates) should have done it. No need for two different keywords. cheers and thx for the feedback :-), —ml—
Re: i18nTransformer problems with static pages
On 12/5/06, Ard Schrijvers <[EMAIL PROTECTED]> wrote: > You should add an extra stylesheet that removes superfluous namespace > attributes. This is what I've done: I used to use this strategy as well, though recently I replaced this xsl transformer with a custom StripNameSpacesTransformer (about just 10 lines), which outperforms the slow xsl transformation a factor 30 for small xml docs, over hundreds of times for bigger xml docs. I am not sure if it is already available in cocoon in some transformer. If somebody is interested in the code, I can attach it, Instead of requiring that an extra transformer be added to the pipeline would it make sense to add this capability as a configuration option on the HTML/XHTML serializers? -- Peter Hunsberger
Updating POM versions throughout our codebase
I forgot one thing to ask: Do we already have a script that updates all dependencies of a library/module to a new version? Without it, it isn't really fun to do a release. If not, help is more than appreciated! (I can't do the release today as I don't have enough time. I will let you know as soon as I have time, if nobody is faster than me!) -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Building changes into the top level sitemap
Jeremy Quinn skrev: Hi Guys I am trying to get support for the new Upload Progress Bar working in Cocoon 2.2. I need to add a new system pipeline to the top-level sitemap, like (and adjacent to) the one that handles : this is the snippet : uri-prefix="_cocoon/system/"/> src="resource://org/apache/cocoon/{1}/system/sitemap.xmap" uri-prefix="_cocoon/system/{1}/"/> The purpose is to mount Block-Level system pipelines. I /think/ the place I make this change is in : /core/cocoon-webapp/src/main/webapp/sitemap.xmap (But TBH I am not sure) Yes, that should be the place. Next I am trying to get this compiled in, so that it is available for the 'cocoon-dist-samples' and everything else that may be built from this distribution. I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : core/cocoon-webapp/ dists/cocoon-dist-samples/ Neither results in the changes happening to the file at : dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap TBH I find this new build system so deeply opaque, I do not know where to start solving this. What am I supposed to do ? First, the dist samples (cocoon-dist-samples, cocoon-dist-publishing) are really just distribution samples. They just unpack and package together the cocoon-webapp and samples and implementations from the various blocks. For development of samples it would be really inconvenient to work from the dist samples as you would need to rebuild about the whole trunk after each change. So what I would recommend to do is to start from the cocoon-webapp instead and to add (locally) all the block samples you need for your work, as dependencies to cocoon-webapp. What happens then is that during startup Cocoon will find all the COB-INF directories from the block samples from the class path. From here two different things can happen: if the block is in a jar at the class path, the COB-INF directory of the block will be unpacked in a blocks/ directory in the temp directory of the servlet container. If the block is in a class directory (if you devolop in Eclipse e.g. and your cocoon-webapp depends on another block project), Cocoon will read directly from the block without any unpacking. All this is done by using a new blockcontext protocol that is aware of the locations of the blocks (see http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=116326232408386&w=2). So the above should hopefully make it easier to work on making the new stuff functional. After that you can try to compile the dist samples and see if it works in them as well. The above described functionality actually make it easier and faster than ever to develop samples, as you can test them without any copying or jetty restarts at all in Eclipse. But some documentation about this would probably not hurt ;) /Daniel
Re: Building changes into the top level sitemap
Jeremy Quinn wrote: Hi Guys I am trying to get support for the new Upload Progress Bar working in Cocoon 2.2. I need to add a new system pipeline to the top-level sitemap, like (and adjacent to) the one that handles : this is the snippet : uri-prefix="_cocoon/system/"/> src="resource://org/apache/cocoon/{1}/system/sitemap.xmap" uri-prefix="_cocoon/system/{1}/"/> The purpose is to mount Block-Level system pipelines. I /think/ the place I make this change is in : /core/cocoon-webapp/src/main/webapp/sitemap.xmap (But TBH I am not sure) Next I am trying to get this compiled in, so that it is available for the 'cocoon-dist-samples' and everything else that may be built from this distribution. I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : core/cocoon-webapp/ dists/cocoon-dist-samples/ Neither results in the changes happening to the file at : dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap TBH I find this new build system so deeply opaque, I do not know where to start solving this. What am I supposed to do ? Thanks for any suggestions One of our problems is that we use the styling resources from cocoon-webapp. We have to move all styling related things into cocoon-samples-style-default and use it from all our sample blocks instead of using the infamous context protocol. For system resources we should provide a "system-resources" block. For now it could be mounted at "_cocoon", later we should install a LinkRewritingTransformer that is aware of blocks. One problem with these changes is, that they are incomptable with 2.1. As we are sharing them across both versions. For this reason I propose to create a cocoon-forms-samples-22 block that makes use of blocks and we have the opportunity to tidy up a bit. -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Building changes into the top level sitemap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Quinn wrote: > I have tried to compile this in, but it never becomes available to the > samples. > > I tried running $ mvn package in both : You probably have to use 'mvn install' as 'mvn package' only build the jar in you target folder of the block whareas you'll need it to be installed into your local repository so other parts of the build system can take them from there. > core/cocoon-webapp/ > dists/cocoon-dist-samples/ > > Neither results in the changes happening to the file at : > > dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap > > TBH I find this new build system so deeply opaque, I do not know where > to start solving this. Read the Maven Manuals as you've read the Ant one years ago :-) Ciao - -- Otego AG Tel: +41 (0)1 240 00 55 Giacomo Pati, CTO Mobile:+41 (0)79 262 21 04 Apache Software Foundation Member Mailto:[EMAIL PROTECTED] Hohlstrasse 216 Mailto:[EMAIL PROTECTED] CH-8004 Zuerich http://www.otego.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFdXc/LNdJvZjjVZARAmJlAJoCunJ9CFm17/S+04n7/Bc3f0GVIwCeIUh6 DsTMtr3sN+t4/cJf6MFaOps= =Y0ix -END PGP SIGNATURE-
Building changes into the top level sitemap
Hi Guys I am trying to get support for the new Upload Progress Bar working in Cocoon 2.2. I need to add a new system pipeline to the top-level sitemap, like (and adjacent to) the one that handles : this is the snippet : prefix="_cocoon/system/"/> The purpose is to mount Block-Level system pipelines. I /think/ the place I make this change is in : /core/cocoon-webapp/src/main/webapp/sitemap.xmap (But TBH I am not sure) Next I am trying to get this compiled in, so that it is available for the 'cocoon-dist-samples' and everything else that may be built from this distribution. I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : core/cocoon-webapp/ dists/cocoon-dist-samples/ Neither results in the changes happening to the file at : dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap TBH I find this new build system so deeply opaque, I do not know where to start solving this. What am I supposed to do ? Thanks for any suggestions regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: [SURVEY] cocoon eventcache block
Ard Schrijvers wrote: Hello, I am wondering if there is anybody using the cocoon eventcache block (without using hippo jars), or are planning to do so in the future? I'm working on a cocoon-daisy block which will make use of the EventCache too. -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
[SURVEY] cocoon eventcache block
Hello, I am wondering if there is anybody using the cocoon eventcache block (without using hippo jars), or are planning to do so in the future? Regards Ard -- Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / http://www.hippo.nl --
Re: i18nTransformer problems with static pages
Ard Schrijvers said the following on 5/12/06 12:40: ...I replaced this xsl transformer with a custom StripNameSpacesTransformer (about just 10 lines), which outperforms the slow xsl transformation a factor 30... This would be useful to have in Cocoon, go for it! I thought it was too trivial :-) Will add it to trunk/branch As a friend of mine says: it's always amazing to see how easy it is to make Cocoon do very difficult things when it is so hard to make it do the trivial things, so by all means submit your transformer and I'm your first customer. ;-) Bye, Helma
RE: i18nTransformer problems with static pages
> > > ...I replaced this xsl transformer with a custom > StripNameSpacesTransformer > > (about just 10 lines), which outperforms the slow xsl > transformation a factor 30... > > This would be useful to have in Cocoon, go for it! I thought it was too trivial :-) Will add it to trunk/branch Ard > -Bertrand >
Re: i18nTransformer problems with static pages
On 12/5/06, Ard Schrijvers <[EMAIL PROTECTED]> wrote: ...I replaced this xsl transformer with a custom StripNameSpacesTransformer (about just 10 lines), which outperforms the slow xsl transformation a factor 30... This would be useful to have in Cocoon, go for it! -Bertrand
Re: i18nTransformer problems with static pages
Ard Schrijvers wrote: You should add an extra stylesheet that removes superfluous namespace attributes. This is what I've done: I used to use this strategy as well, though recently I replaced this xsl transformer with a custom StripNameSpacesTransformer (about just 10 lines), which outperforms the slow xsl transformation a factor 30 for small xml docs, over hundreds of times for bigger xml docs. I am not sure if it is already available in cocoon in some transformer. If somebody is interested in the code, I can attach it, if you mean adding to trunk/branch21, +1 -- Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
RE: i18nTransformer problems with static pages
> You should add an extra stylesheet that removes superfluous namespace > attributes. This is what I've done: I used to use this strategy as well, though recently I replaced this xsl transformer with a custom StripNameSpacesTransformer (about just 10 lines), which outperforms the slow xsl transformation a factor 30 for small xml docs, over hundreds of times for bigger xml docs. I am not sure if it is already available in cocoon in some transformer. If somebody is interested in the code, I can attach it, Regards Ard > > > > > > > > > > > > > > > > Add a generic catchall template or you end up with nothing: > > > > > > > > > > > > HTH > > Bye, Helma > >
Re: [2.1.10] WildcardHelperTestCase fails
Afaik, the code for the wildcard helper has been replaced after that by someone else. Carsten Bertrand Delacretaz wrote: > Just tried to run the junit tests on BRANCH_2_1_X, and the second > assertion in WildcardHelperTestCase fails: > > public void testEndPattern() throws Exception { > final Map resultMap = new HashMap(); > final String pattern = "*/"; > final int[] expr = WildcardHelper.compilePattern(pattern); > boolean result = WildcardHelper.match(resultMap, "foo/bar/", expr); > > // this one passes > assertFalse("Url 'foo/bar/' should not match pattern '*/'.", result); > > // this one fails > result = WildcardHelper.match(resultMap, "test/foo/bar/", expr); > assertFalse("Url 'test/foo/bar/' should not match pattern > '*/'.", result); > > result = WildcardHelper.match(resultMap, "foo/", expr); > assertTrue("Url 'foo/' should match pattern '*/'", result); > > IIUC, this is related to http://tinyurl.com/ydvkcb , but Carsten says > in that thread that the bug has been fixed. Any clues? > > (environment: macosx 10.4.8, JDK 1.5.0_06) > > -Bertrand > -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/