Re: Next releases of JNet, SSF and blockdeployment
Grzegorz Kossakowski pisze: Reinhard Pötz pisze: Yes. If you can help me with updating the docs, changes.xml and announcements ([EMAIL PROTECTED] and website), we can have a release this week, otherwise I'm not sure if I can do it this week. I'll have a free time until Thursday and call help with whatever is needed. When it comes to changes.xml they already include information about changes I've made. I guess you refer to filling this files with correct information about release like date of release, right? I can prepare announcement where we explain what's the idea of all these releases. When can we start? Reinhard, I would like to ask for some time before we start release process. I fear that I've discovered even more regressions in SSF compared to 1.0.0 version. :-( -- Grzegorz Kossakowski
[jira] Created: (COCOON-2239) Add support for servlet protocol in flow's sendPage
Add support for servlet protocol in flow's sendPage --- Key: COCOON-2239 URL: https://issues.apache.org/jira/browse/COCOON-2239 Project: Cocoon Issue Type: Task Components: - Components: Sitemap, - Flowscript Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski The idea of this task is introduce support for servlet: protocol in sendPage calls. Current behaviour is that if one called sendPage(some/path) it will get translated into redirection to cocoon:/some/path so any custom protocol is disallowed in sendPage calls. I would like to introduce support for sendPage(servlet:/some/path) calls that explicitly make use of servlet: protocol. In such case, processing should be redirected to ServletSource and SSF machinery. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Differences between Cocoon 2.1 and 2.2 (was: Re: Renaming Corona to Cocoon 3.0 and infrastructure)
Hi Jeremy, Jeremy Quinn pisze: From the PoV of users, it should also be clear : If you want or have to use Ant, use 2.1 If you want or have to use Maven, use 2.2 If you just need the Pipeline API, use 3.0 I'm not sure if I get you here correctly so I'll ask: Do you express your own wish or your own perception of situation we have when it comes to differences between 2.1 and 2.2? There should be no other difference in quality between the release versions, and none should be implied. I'm afraid that it's not a case for some time at least according to my understand of Cocoon 2.2. -- Best regards, Grzegorz Kossakowski
Re: [jira] Created: (COCOON-2239) Add support for servlet protocol in flow's sendPage
Grzegorz Kossakowski (JIRA) pisze: Add support for servlet protocol in flow's sendPage --- Key: COCOON-2239 URL: https://issues.apache.org/jira/browse/COCOON-2239 Project: Cocoon Issue Type: Task Components: - Components: Sitemap, - Flowscript Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski The idea of this task is introduce support for servlet: protocol in sendPage calls. Current behaviour is that if one called sendPage(some/path) it will get translated into redirection to cocoon:/some/path so any custom protocol is disallowed in sendPage calls. I would like to introduce support for sendPage(servlet:/some/path) calls that explicitly make use of servlet: protocol. In such case, processing should be redirected to ServletSource and SSF machinery. As description of this issue states I want to introduce support for servlet: protocol in flow's sendPage function so people can use it instead of cocoon: protocol that is enforced by hard-coded functionality in AbstractInterpreter class. If nobody objects I'll start adding support for this feature tomorrow. One important note: This support won't introduce any hard dependency on SSF neither in Cocoon's core nor in flow implementations. -- Grzegorz Kossakowski
Re: Differences between Cocoon 2.1 and 2.2 (was: Re: Renaming Corona to Cocoon 3.0 and infrastructure)
Hi Grzegorz, Many thanks for your response : ) On 19 Aug 2008, at 12:54, Grzegorz Kossakowski wrote: Hi Jeremy, Jeremy Quinn pisze: From the PoV of users, it should also be clear : If you want or have to use Ant, use 2.1 If you want or have to use Maven, use 2.2 If you just need the Pipeline API, use 3.0 I'm not sure if I get you here correctly so I'll ask: Do you express your own wish or your own perception of situation we have when it comes to differences between 2.1 and 2.2? I am trying to think about this from a 'marketing' perspective. It would be typical to assume (IMHO) that 3.0 is somehow better than 2.2 which is somehow better than 2.1, just because of the version numbers. Whereas from the point of view of a User, making projects (using SiteMaps, XML, XSLT, JXTemplate, FlowScript, etc. etc.) 2.1 and 2.2 are as much as possible, completely compatible and mostly just as capable as each other. The fact that once a User has a suitable build, it makes very little difference whether they use 2.1 or 2.2 (not sure about 3.0) is something that I think we should put across more clearly. It would be a shame to loose potential Users, because they perceived that the version that used their preferred build-technology, was in some way obsolete (which could now happen with both 2.1 and 2.2). Maybe a capability matrix of some sort, would help a User trying to decide which version to use, would provide more reassurance that the 3 versions (or at least 2.1 and 2.2) would provide a viable, stable, long-lasting platform, even though the version numbers may say otherwise. There should be no other difference in quality between the release versions, and none should be implied. I'm afraid that it's not a case for some time at least according to my understand of Cocoon 2.2. The build and distribution system for 2.2 is clearly more modern and sophisticated. It has a polymorphic block paradigm that suits the build technology, it has the powerful concept of virtual pipelines etc. etc. And this is all great ! But from the Users' PoV of making projects, I cannot imagine a project that could be made successfully with 2.2 that could not be made using 2.1 (don't know enough about 3.0). My assumption is that you personally find 2.2 more powerful because you prefer the build technology, not because 2.2 is intrinsically more powerful, or less buggy. This is why I propose that we should give a clear message that all release versions are valid choices, primarily dependant on the build- technology that you prefer, not on specific version numbers. AFAIU, TomCat is in a similar situation, where the different primary versions, represent not quality, but the version of the ServletAPI and JSP Spec they support. see: http://tomcat.apache.org/whichversion.html I hope this is clearer best regards Jeremy
Re: Differences between Cocoon 2.1 and 2.2 (was: Re: Renaming Corona to Cocoon 3.0 and infrastructure)
Just an added note On 19 Aug 2008, at 16:04, Jeremy Quinn wrote: It would be typical to assume (IMHO) that 3.0 is somehow better than 2.2 which is somehow better than 2.1, just because of the version numbers. This assumption is so easy to make, because for instance : 2.1 was better than 2.0 which was MUCH better than 1.0 etc. But now, we seem to use version numbers differently. regards Jeremy
Re: request encoding conundrum
Hi Grzegorz, Sorry for the delay, but I finally got to look at the Upload Sample in CForms. The simple one, without the progress bar does seem to work in my local copy of 2.1.12-dev that I am working on. I tried the sample string below and it came through correctly. Does switching ajax on or off make any difference on your setup? Sorry I could not reproduce your problem :-/ regards Jeremy On 27 Jul 2008, at 18:51, Grzegorz Kossakowski wrote: I've tested it (combined with fix from COCOON-1917) and on the server side everything looks correct now. Great !!! The only problem is that browser sometimes does not behave correctly. I noticed that sometimes when I enter non-latin characters to the text field they get escaped by a browser. So when I enter something like: światło the browser posts to the server such value: #347;wiat#322;o Yes, I see this a lot. I also see UTF-8 encoding like this : %E2%82%AC (which is the 3 byte encoding for the Euro symbol). I have not found this encoding to be a problem. I thought that browser should never escape characters if it's not absolutely necessary. If browser was submitting the data using UTF-8 then that wouldn't be necessary right? What problem does this cause you? Our samples are simply broken that's the problem :-) If you try to use this upload sample I've already pointed you to then you will see that result page produced after forms is submitted contains escaped characters. (additionally there is parameter: dojo.transport=xmlhttp) This is one of the standard parameters that CForms has to add to form submits. CForms uses 3 different transports, depending on context: 1) ajax-off : normal whole page submit 2) ajax-on : xmlhttp 3) ajax-on + form contains a 'file' field : iframe-transport Unfortunately, the response to each of these needs to be serialized differently, hence the need to a very complicated sitemap for cforms and this special parameter. I see. Still I don't understand why our samples are broken. Since I don't know how these things are handled on the client side I'm not sure how to fix it. Any ideas? I need more details of what problem it causes I hope you can reproduce it with upload sample we have in Cocoon.
