[jira] Commented: (COCOON-2247) Default matcher no longer works when divider character part of match
[
https://issues.apache.org/jira/browse/COCOON-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660652#action_12660652
]
Kamal Bhatt commented on COCOON-2247:
-
Is this a problem with cocoon 2.2 as well?
> Default matcher no longer works when divider character part of match
>
>
> Key: COCOON-2247
> URL: https://issues.apache.org/jira/browse/COCOON-2247
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
>Affects Versions: 2.1.11
>Reporter: Kamal Bhatt
>
> Example sitemap:
>
>
> src="../cmsblocks/holidayImg/{1}/{2}">
>
>
>
>
>
>
>
> Using the following match:
> image_list_images_TE_tours
> You get the following error:
> ../cmsblocks/holidayImg/images_TE/tours is not a directory.
> The match is completely foobar. This used to work in 2.1.9
> I have not had a chance to see how it works in 2.2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2247) Default matcher no longer works when divider character part of match
[
https://issues.apache.org/jira/browse/COCOON-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660651#action_12660651
]
Kamal Bhatt commented on COCOON-2247:
-
We will also change our app, but it becomes a real nuisance if you have free
format fields on a form that submit to a Cocoon pipeline.
> Default matcher no longer works when divider character part of match
>
>
> Key: COCOON-2247
> URL: https://issues.apache.org/jira/browse/COCOON-2247
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
>Affects Versions: 2.1.11
>Reporter: Kamal Bhatt
>
> Example sitemap:
>
>
> src="../cmsblocks/holidayImg/{1}/{2}">
>
>
>
>
>
>
>
> Using the following match:
> image_list_images_TE_tours
> You get the following error:
> ../cmsblocks/holidayImg/images_TE/tours is not a directory.
> The match is completely foobar. This used to work in 2.1.9
> I have not had a chance to see how it works in 2.2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2247) Default matcher no longer works when divider character part of match
[
https://issues.apache.org/jira/browse/COCOON-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kamal Bhatt updated COCOON-2247:
Description:
Example sitemap:
Using the following match:
image_list_images_TE_tours
You get the following error:
../cmsblocks/holidayImg/images_TE/tours is not a directory.
The match is completely foobar. This used to work in 2.1.9
I have not had a chance to see how it works in 2.2.
was:
Example sitemap:
Using the following match:
image_list_images_TE_tours
You get the following error:
../cmsblocks/holidayImg/images_TE/tours is not a directory.
The match is completely foobar. This used to work in 2.1.9
> Default matcher no longer works when divider character part of match
>
>
> Key: COCOON-2247
> URL: https://issues.apache.org/jira/browse/COCOON-2247
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
>Affects Versions: 2.1.11
> Reporter: Kamal Bhatt
>
> Example sitemap:
>
>
> src="../cmsblocks/holidayImg/{1}/{2}">
>
>
>
>
>
>
>
> Using the following match:
> image_list_images_TE_tours
> You get the following error:
> ../cmsblocks/holidayImg/images_TE/tours is not a directory.
> The match is completely foobar. This used to work in 2.1.9
> I have not had a chance to see how it works in 2.2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2247) Default matcher no longer works when divider character part of match
Default matcher no longer works when divider character part of match Key: COCOON-2247 URL: https://issues.apache.org/jira/browse/COCOON-2247 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11 Reporter: Kamal Bhatt Example sitemap: Using the following match: image_list_images_TE_tours You get the following error: ../cmsblocks/holidayImg/images_TE/tours is not a directory. The match is completely foobar. This used to work in 2.1.9 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Proposal - JS Reader
Reinhard Pötz wrote: Kamal Bhatt wrote: Reinhard Pötz wrote: Kamal wrote: Hi, It occured to me that Cocoon could probably benefit from a Javascript Reader. This JS Reader would do what a normal resource reader would, unless the user specifies a compression-method parameter. If the compression method is supported, then the JS will be compressed. Right now, I think we can only use JSMin[1] or Package[4], as Dojo ShrinkSafe[2] and YUI compressor [3] rely on custom version of Rhino. Packer [4] is written in plain old javascript. JSMin and Packer are open source, but it is not distributed on any Maven repositories that I can see, so we would need to include them in source. Have you had a look at http://alchim.sourceforge.net/yuicompressor-maven-plugin/overview.html? This plugin could be used as part of the build process. Then you could use the uncompressed Javascript files for development and then when the module is packaged, the Javascript and CSS files could be compressed. And, AFAICS, this plugin uses standard Rhino (1.6R7). See http://repo1.maven.org/maven2/net/sf/alchim/yuicompressor-maven-plugin/0.7.1/yuicompressor-maven-plugin-0.7.1.pom Hmmm... Don't know how they did that. I will look into it. This would be useful for the (very large) JS dependencies in CForms (though, it could be argued that we should be bundling the already compressed version of Dojo and the other Cocoon JS files). I, personally, would find something like this really useful as we have lots of code that we like to keep uncompressed for development, but compress at runtime. What does everyone think? I don't mind coding this up (using just JSMin). I'm not sure if it is really good idea to compress Javascript files at runtime. I guess that depends (in part) on whether people generate javascript at run time. If so, then it would be useful to create this reader. If you write the plugin, it would also be possible to reuse the yuicompressor-maven-plugin but not as Maven plugin but as a normal dependency. By doing it this way you wouldn't have to pull in any third-party code into our code base. I don't follow this, can you elaborate? A Maven plugin is just a JAR file that can be used as a normal dependency. The yuicompressor-maven-plugin already contains com.yahoo.platform.yui.compressor classes that can be used this way: net.sf.alchim yuicompressor-maven-plugin 0.7.1 Provided that it's legally correct for an Apache project to depend on this code (needs to be checked before somebody starts to code!!!), this looks to be the simplest way to use a Javascript/CSS compressor. OK, I think I get you. So we can use this plugin as a way of getting the YUI code without including it in Cocoon. Assuming there is interest in this project (of course). -- Kamal Bhatt
Re: Proposal - JS Reader
Reinhard Pötz wrote: Kamal wrote: Hi, It occured to me that Cocoon could probably benefit from a Javascript Reader. This JS Reader would do what a normal resource reader would, unless the user specifies a compression-method parameter. If the compression method is supported, then the JS will be compressed. Right now, I think we can only use JSMin[1] or Package[4], as Dojo ShrinkSafe[2] and YUI compressor [3] rely on custom version of Rhino. Packer [4] is written in plain old javascript. JSMin and Packer are open source, but it is not distributed on any Maven repositories that I can see, so we would need to include them in source. Have you had a look at http://alchim.sourceforge.net/yuicompressor-maven-plugin/overview.html? This plugin could be used as part of the build process. Then you could use the uncompressed Javascript files for development and then when the module is packaged, the Javascript and CSS files could be compressed. And, AFAICS, this plugin uses standard Rhino (1.6R7). See http://repo1.maven.org/maven2/net/sf/alchim/yuicompressor-maven-plugin/0.7.1/yuicompressor-maven-plugin-0.7.1.pom Hmmm... Don't know how they did that. I will look into it. This would be useful for the (very large) JS dependencies in CForms (though, it could be argued that we should be bundling the already compressed version of Dojo and the other Cocoon JS files). I, personally, would find something like this really useful as we have lots of code that we like to keep uncompressed for development, but compress at runtime. What does everyone think? I don't mind coding this up (using just JSMin). I'm not sure if it is really good idea to compress Javascript files at runtime. I guess that depends (in part) on whether people generate javascript at run time. If so, then it would be useful to create this reader. If you write the plugin, it would also be possible to reuse the yuicompressor-maven-plugin but not as Maven plugin but as a normal dependency. By doing it this way you wouldn't have to pull in any third-party code into our code base. I don't follow this, can you elaborate? -- Kamal Bhatt
Re: Client-side validation in CForms
Jeremy Quinn wrote: Dear Kamal Many thanks for your response. On 9 Jul 2008, at 23:18, Kamal Bhatt wrote: Jeremy Quinn wrote: Hi All As you may know, I am working heavily on the revamp of Dojo on the client-side of CForms. In Dojo it is possible to perform quite a lot of validation on form fields. There is a partial match between the validation capabilities of CForms and those of Dojo. Several people have thought in the past that it would be good to have the same validation occur on both the server and the client. OTTOMH, the kind of validators we could probably make work in both places would be : email, length, mod10, range and regexp (plus maybe javascript, if we can sort out any context differences) On re-examination, the list of validators that could have an equivalent client-side validator auto-generated is probably shorter . as I am not sure ATM how to implement the expressions possible in some of them . eg. assert, length, range etc. Maybe this is my ignorance speaking, but I don't see any (clean) way of making client side validation work. How a validation message is presentated is left up to forms-styling (or whatever you wish to call it), so you cannot make assumptions about how the validation is presented. Yes, this is an issue that needs addressing. However, there may be an answer . both Cocoon and Dojo are i18n capable, even though they both use different i18n catalogue formats, Cocoon i18n files could be provided to Dojo via a special transformation. Or maybe I am still being naive ; ) I don't know enough about i18n to say. The closest solution I can see is if you created a hook function for all validation and had the hook function propargate the errors that way. Could you expand on what you mean by a hook function? When you get a client side error, you pass information to a function that will indicate what the error is and the field it is associated with. This function will then manipulate the HTML to give you the effect you want (new class, change in the tabbing, etc...). Maybe this doesn't quite work with Dojo, I don't know. That still sounds rather messy and sounds like a duplication of effort. Also (if the application is fast), it would lead to some bad UI if some of the validation is done client side some server side. Now, if validation were rewritten in such a way that the hook functions were called for even server side validation errors, it might provide a rather neat way of getting around some of the problems that Ajax CForms throw up as well as reducing duplication. I really wish I had a better understanding of Dojo so I could fix up some of the issues related to validation and Ajax. ATM however, no validation information is output by the form generation process. Datatypes are there (which I can initially use) but no validation. So my question is, would someone volunteer to either add the definition's validation tags to the output or help work out the cleanest approach to adding it? thanks regards Jeremy -- Kamal Bhatt
Re: Client-side validation in CForms
Jeremy Quinn wrote: Hi All As you may know, I am working heavily on the revamp of Dojo on the client-side of CForms. In Dojo it is possible to perform quite a lot of validation on form fields. There is a partial match between the validation capabilities of CForms and those of Dojo. Several people have thought in the past that it would be good to have the same validation occur on both the server and the client. OTTOMH, the kind of validators we could probably make work in both places would be : email, length, mod10, range and regexp (plus maybe javascript, if we can sort out any context differences) Maybe this is my ignorance speaking, but I don't see any (clean) way of making client side validation work. How a validation message is presentated is left up to forms-styling (or whatever you wish to call it), so you cannot make assumptions about how the validation is presented. The closest solution I can see is if you created a hook function for all validation and had the hook function propargate the errors that way. That still sounds rather messy and sounds like a duplication of effort. Also (if the application is fast), it would lead to some bad UI if some of the validation is done client side some server side. Now, if validation were rewritten in such a way that the hook functions were called for even server side validation errors, it might provide a rather neat way of getting around some of the problems that Ajax CForms throw up as well as reducing duplication. I really wish I had a better understanding of Dojo so I could fix up some of the issues related to validation and Ajax. ATM however, no validation information is output by the form generation process. Datatypes are there (which I can initially use) but no validation. So my question is, would someone volunteer to either add the definition's validation tags to the output or help work out the cleanest approach to adding it? Many thanks regards Jeremy -- Kamal Bhatt
Re: Problem to integrate a website in cocoon
David Crossley wrote: doog4064 wrote: I'm using the 2.1.11 version of cocoon Please discuss such issues on the "users" mail list, rather than this "dev" list. Whoops, didn't notice that. Yes, Post this on the user mailing list. -David Kamal-6 wrote: What version of Cocoon are you using? hi evrybody, I'm a beginner in cocoon, I've been spending days finding out how does apache cocoon works, but all the docs i've found didn't help me to answer my questions. I just get a web site developped on cocoon, so i've installed the server but I can not find where i have to copy the directory or what i have to do, to make it work. I really have problems to figure out how this all thing work. So, if someone could explain to me what are the manipulations to do to run my website, please help me. Thank you so much. -- View this message in context: http://www.nabble.com/Problem-to-integrate-a-website-in-cocoon-tp18281481p18311503.html Sent from the Cocoon - Dev mailing list archive at Nabble.com. -- Kamal Bhatt
Re: What is Corona?
That sounds amazing. So is Cocoon 2.2 going to employ Corona?
5. Having a serious look into Corona.
Forgive my ignorance, but I assume you are not risking blindness or
are intending to drink lots of beer, so what is Corona?
At Indoqa we have been working on a complete rewrite of Cocoon that we
called Corona. The most basic module of Corona is the
'corona-pipeline' module. It is easily embeddable into any Java
application because it comes with no dependency but the classes coming
with the JRE. Here is an example for the pipeline API:
Pipeline pipeline = new NonCachingPipeline();
pipeline.addComponent(new FileGenerator(
PipelineTest.class.getResource("/test.xml")));
pipeline.addComponent(new XSLTTransformer(
PipelineTest.class.getResource("/test.xslt")));
pipeline.addComponent(new XMLSerializer());
pipeline.execute(null, System.out);
We also had the chance to tidy up a lot of things because the core of
Cocoon isn't easily comprehensible after having been under development
for about 7 years.
On top of corona-pipeline we put the corona-sitemap module. It
implements more or less the sitemap language that you know from Cocoon
2.x. Like Cocoon 2.2 the sitemap components are managed by Spring but
the dependency on Spring should be easily replaceable because it is
hidden behind an interface whose implementation class is really simple.
The third layer of Corona is the 'corona-servlet' module. It provides
a servlet that can be used together with the servlet-service framework.
From my POV the most important features have been implemented by now.
Some things have to be cleaned up and error reporting has to be
improved but I'm optimistic that this will happen in the next few
weeks. Additionally we will donate another module to Corona that
provides a way to implement controller logic for RESTful web
applications/services.
Apparently the two missing things are documentation (I've already
started with it) and an alpha-1 release. Of course the latter needs to
be discussed by this community. For this purpose I will start a
separate thread soon.
--
Kamal Bhatt
Re: FYI: I'll be working for Workflow company over summer
Grzegorz Kossakowski wrote: Hi guys, I thought that it's a good idea to clearly state that I'll be working for Workflow company from Vienna. My employment will probably drive my most of the interest in working on C2.2 over this summer. Anyway, I was lucky enough to find a job that will give me a chance to work on my favorite Cocoon parts. My plan for this summer is (apart from bug-fixing and maintenance work of course): 1. Upgrade of our documentation system to Daisy 2.2 once released (quite tedious I guess) 2. Collaboration of Dojo 1.1 migration of Forms. Here I speak to you Jeremy, I will finally have enough time to give you a serious feedback, probably some code and plenty of tips when it comes to 2.2. Others interested in this work are invited to participate in the effort of course! I would love to understand Dojo as it is used in CForms. I would like to solve some mysteries such as what attaches events to the form. It would be nice if a fix were put in for the ongoing issue with non widget elements from not rendering in Ajax [1]. This might be better handled with the formalising the hack mentioned at the end of page, which doesn't work anymore (or by creating a new kind of widget) 3. I finally want to learn how to make releases, I'll probably start with Template 1.0.0 and Forms 1.0.0. If successful, then I want to release Template 1.2.0 that includes contributions from Kamal Bhatt (jx:element). Good to hear. 4. Some work on Cocoon's core leading to 2.3 release of _Cocoon core_ only (will write an e-mail about it later this week). 5. Having a serious look into Corona. Forgive my ignorance, but I assume you are not risking blindness or are intending to drink lots of beer, so what is Corona? 6. First release of my Cocoon blog project. (this will probably have the highest priority) [1] https://issues.apache.org/jira/browse/COCOON-1570 -- Kamal Bhatt
Re: Cocoon-fop-impl using old version of fop.jar
This has been done in trunk (I think) https://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-fop/cocoon-fop-ng-impl/ I don't know why this hasn't been released, a committer can give more information on what needs to be done to make this a stable, released block. Unfortunately, when the Fop crew moved to 0.9x they completely rewrote the API for embedding which makes the upgrade a little more difficult than simply changing the version number. Also, 0.9x works very differently to 0.20.5. From my understanding 0.20.5 had many deviations from the XSL FO standard, which were rectified in 0.9x. This means that there are probably many people out there who would scream bloody murder if we simply moved to 0.9x as all their stylesheets would break. I assume the reason why both 0.20.5 and 0.9x were not supported in the same transformer was because of clashing classes. For more details see here: http://xmlgraphics.apache.org/fop/0.94/upgrading.html Hi guys, Any particular reason why we still use the DINO-version of the fop.jar (0.20.5) ? I would like to use at least the stable 0.94 or even try out the 0.95 beta. What is the easiest way to accomplish this? Currently I have just added the FOP-dependency to my pom like below: org.apache.cocoon cocoon-fop-impl 1.0.0 Any help would be most appreciated. Cheers, Robby Pelssers -- Kamal Bhatt
[jira] Updated: (COCOON-2212) jx:attribute does not check name is correct before proceeding
[ https://issues.apache.org/jira/browse/COCOON-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamal Bhatt updated COCOON-2212: Description: Currently, jx:attribute does not validate that the name is correct before generating attribute. This patch fixes this. Also, refactored the JXTemplateGeneratorTestCase was: Currently, jx:attribute does not validate that the name is correct before generating attribute. This patch fixes this. Also, refactors the JXTemplateGeneratorTestCase > jx:attribute does not check name is correct before proceeding > - > > Key: COCOON-2212 > URL: https://issues.apache.org/jira/browse/COCOON-2212 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: Templating >Affects Versions: 2.1.12-dev (Current SVN), 2.2, 2.2-dev (Current SVN) > Reporter: Kamal Bhatt > Fix For: 2.2-dev (Current SVN) > > Attachments: JXtemplateAttributePatch > > > Currently, jx:attribute does not validate that the name is correct before > generating attribute. This patch fixes this. > Also, refactored the JXTemplateGeneratorTestCase -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2212) jx:attribute does not check name is correct before proceeding
[ https://issues.apache.org/jira/browse/COCOON-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamal Bhatt updated COCOON-2212: Attachment: JXtemplateAttributePatch > jx:attribute does not check name is correct before proceeding > - > > Key: COCOON-2212 > URL: https://issues.apache.org/jira/browse/COCOON-2212 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: Templating >Affects Versions: 2.1.12-dev (Current SVN), 2.2, 2.2-dev (Current SVN) > Reporter: Kamal Bhatt > Fix For: 2.2-dev (Current SVN) > > Attachments: JXtemplateAttributePatch > > > Currently, jx:attribute does not validate that the name is correct before > generating attribute. This patch fixes this. > Also, refactors the JXTemplateGeneratorTestCase -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2212) jx:attribute does not check name is correct before proceeding
jx:attribute does not check name is correct before proceeding - Key: COCOON-2212 URL: https://issues.apache.org/jira/browse/COCOON-2212 Project: Cocoon Issue Type: Improvement Components: Blocks: Templating Affects Versions: 2.1.12-dev (Current SVN), 2.2, 2.2-dev (Current SVN) Reporter: Kamal Bhatt Fix For: 2.2-dev (Current SVN) Currently, jx:attribute does not validate that the name is correct before generating attribute. This patch fixes this. Also, refactors the JXTemplateGeneratorTestCase -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2211) Support for jx:element
[ https://issues.apache.org/jira/browse/COCOON-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamal Bhatt updated COCOON-2211: Affects Version/s: (was: 2.1.12-dev (Current SVN)) 2.2-dev (Current SVN) 2.2 > Support for jx:element > -- > > Key: COCOON-2211 > URL: https://issues.apache.org/jira/browse/COCOON-2211 > Project: Cocoon > Issue Type: New Feature > Components: Blocks: Templating >Affects Versions: 2.2, 2.2-dev (Current SVN) > Reporter: Kamal Bhatt > Attachments: JXtemplateElementPatch > > > JXTemplate does n't support a jx:element instruction. This patch provides > this support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2211) Support for jx:element
[ https://issues.apache.org/jira/browse/COCOON-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamal Bhatt updated COCOON-2211: Attachment: JXtemplateElementPatch > Support for jx:element > -- > > Key: COCOON-2211 > URL: https://issues.apache.org/jira/browse/COCOON-2211 > Project: Cocoon > Issue Type: New Feature > Components: Blocks: Templating >Affects Versions: 2.2, 2.2-dev (Current SVN) > Reporter: Kamal Bhatt > Attachments: JXtemplateElementPatch > > > JXTemplate does n't support a jx:element instruction. This patch provides > this support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2211) Support for jx:element
Support for jx:element -- Key: COCOON-2211 URL: https://issues.apache.org/jira/browse/COCOON-2211 Project: Cocoon Issue Type: New Feature Components: Blocks: Templating Affects Versions: 2.1.12-dev (Current SVN) Reporter: Kamal Bhatt JXTemplate does n't support a jx:element instruction. This patch provides this support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: XSP block
I am not really a committer to Cocoon, but I was wondering about this
whole JXtemplates + Flowscript replaces XSPs advice. I feel that
JXTemplates + Flowscript is a poor substitute. Here are my reasons why:
1. It leads to an explosion in pipelines. Instead of one pipeline, you
now have 2 (at least)
2. There is so much that isn't easily ported to a JXTemplates +
flowscript environment. For example, there is no analogy to xsp:element.
3. No analogous functionality to the esql logicsheet. You basically have
to create your own and for simple queries, this can quickly become a hassle.
I have put my hand up for (2), and when I find some time I will look
into it. I cannot see any way of rectifying (3), which is unfortnate
because I suspect that is the biggest reason why people will not move
away from XSPs. As for (1), I was wondering if anyone has thought of
creating an extension to JXTemplates to support a new style of template.
One where you can specify a javascript/Java/Ruby/whatever at the top and
the presentation after that. For example, something like this:
return({content : "123"});
Is this possible? In some cases, I think this will be a neat solution as
you still have a clear separation between logic and presentation, but
you don't need to open three separate files to see what is going on.
Also, I don't see this as a replacement for flowscript, just another
tool in the toolbox that is Cocoon.
Anyway, my 2c.
Moving this discussion from users list (for reference [1]) to dev list.
On 06.06.2008 19:02, Alfred Nathaniel wrote:
Warning: I'm stating my own opinion here, nothing official or
something like that.
There are at least three problems with XSP:
1. No active committer is interested in XSP anymore, and even more,
hardly anyone wants to invest her time in technology that seems to
be deprecated in every dev's head but still block is not officially
marked as deprecated.
I may be not as active as you but I am a committer who is still very
interested in XSP. In may daytime job we have 1000+ XSPs in production
and no intention to drop that technology in the forseeable future. XSP
has its shortcomings and pitfalls but after 7 years experience we know
how to handle that.
2. The only reason why people keep trying to use XSP is that it has
decent documentation on our site and this documentation has no
information about XSP status. We should really explain people that
Templates + Flowscript is much better approach.
I think the reason why XSP appeals to newcomer is that the concept is
familiar from JSP, and it is a combination of the three core
technologies which Cocoon handles extremely well:
XSP = XML + XSLT + Java.
Personally, I still do not consider Flowscript an alternative for
enterprise websites for three reasons:
a.) Serverside JavaScript is an additional level in the technology stack
you and your team have to master.
b.) I would not bet my head on Rhino being threadsafe, and it is such a
big beast to debug it yourself.
c.) Continuations are a great idea, but how do you know when it is safe
to free the memory?
3. XSP is really old technique and is not maintained by anyone
(again officially, at dev/commits list). I'm not the one willing to
take costs of XSP maintenance in C2.2 therefore I'll probably vote
-1 for any actions leading to release of XSP block for C2.2. This is
my first such a strong voice in this case but I firmly believe it's
a high time have a concrete opinion.
XSP is a really mature technology which hardly needs any maintenance any
more. The reason why the XSP block (as many other blocks) is not
released yet is actually more of a C2.2 issue than an XSP problem.
Still, I'm open for discussion of course.
I'd prefer to have this sort of discussion on the dev-list.
I completely agree with Alfred. I don't see any reason for not
releasing XSP block. Yes, somebody has to do the actual work. But why
blocking it when somebody puts in the effort? You can estimate the
maintenance costs by looking at the changes in the last years in the
2.1 branch.
Joerg
[1] http://marc.info/?t=12124988641&r=1&w=4
--
Kamal Bhatt
[jira] Commented: (COCOON-2207) Validatiion errors not working in ajax
[ https://issues.apache.org/jira/browse/COCOON-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600950#action_12600950 ] Kamal Bhatt commented on COCOON-2207: - Sorry, never submitted on a widget (I used the submit). I did this a long time ago, and maybe someone put a patch through that changed the functionality. What I recommend is that you turn of Ajax, work out what the save widget calls, then replicate it. That is how I worked out how to turn off ajax. I suspect it isn't going to be forms_onsubmit(). Be aware that whatever you do here is not going to work if you upgrade to 2.1.11 as they have changed how Cocoon submits. I have a sneaking suspicion that (intentionally or otherwise) someone has made this sort of hack near impossible using the standard dojo set. Also, you should probably continue this discussion on the mailing list as it this conversation doesn't belong on an issue. > Validatiion errors not working in ajax > -- > > Key: COCOON-2207 > URL: https://issues.apache.org/jira/browse/COCOON-2207 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.10 >Reporter: Mohammed Aashik > > Hi, > Im using Cocoon 2.1.10. I've implemented ajax in my form. > My form has plenty of widgets. So,i need to have a general area to show all > the validation error messages. > When im using ajax , is NOT working but when i make > ajax="false" > is working fine. > And one more thing if i make ajax="false" a validation error Message > (Exclamation mark) is shown near the tab, > but if i make ajax="true" validation error Message (Exclamation mark) is NOT > shown near the tab. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2207) Validatiion errors not working in ajax
[ https://issues.apache.org/jira/browse/COCOON-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600720#action_12600720 ] Kamal Bhatt commented on COCOON-2207: - Bad news, fi:validation-errors is busted in a non-ajax environment. See this issue: https://issues.apache.org/jira/browse/COCOON-1570 Don't expect anyone to fix this problem any time soon. Good news, you are using Cocoon 2.1.10 so it is easy enough to turn off validation on submission. See this post: http://java2.5341.com/msg/228810.html This ticket should probably closed as it is a duplicate. > Validatiion errors not working in ajax > -- > > Key: COCOON-2207 > URL: https://issues.apache.org/jira/browse/COCOON-2207 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.10 >Reporter: Mohammed Aashik > > Hi, > Im using Cocoon 2.1.10. I've implemented ajax in my form. > My form has plenty of widgets. So,i need to have a general area to show all > the validation error messages. > When im using ajax , is NOT working but when i make > ajax="false" > is working fine. > And one more thing if i make ajax="false" a validation error Message > (Exclamation mark) is shown near the tab, > but if i make ajax="true" validation error Message (Exclamation mark) is NOT > shown near the tab. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Drop JDK1.3 support for Cocoon 2.1.11 and newer versions
Felix Knecht wrote: Please cast your votes! +1 Felix +1 -- Kamal Bhatt
[jira] Commented: (COCOON-2204) ft:group internal div not handled correctly.
[ https://issues.apache.org/jira/browse/COCOON-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592718#action_12592718 ] Kamal Bhatt commented on COCOON-2204: - Thanks. Am I correct in saying that this issue: https://issues.apache.org/jira/browse/COCOON-1825 Is redundant? > ft:group internal div not handled correctly. > > > Key: COCOON-2204 > URL: https://issues.apache.org/jira/browse/COCOON-2204 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Forms >Affects Versions: 2.2 >Reporter: Kamal Bhatt >Assignee: Jörg Heinicke >Priority: Minor > Fix For: 2.2-dev (Current SVN) > > > According to this page: > http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html > If you you are using Ajax, a div (or similar element) must surround the > fields of a group. eg: > > > > > > > CForms (through the magic of the forms-field-styling.xsl) will put the > group's id on the div. The code to this, seems broken as it does not match on > the div, but on the fi:group. > NOTE: This is another solution to the problem described here: > https://issues.apache.org/jira/browse/COCOON-1825 > However, the solution described within it seems to make the suggestion in > http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html redundant. Either > way, either this issue or that one is not necessary. > Patch is provided below: > Index: > D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl > === > --- > D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl > (revision 651922) > +++ > D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl > (working copy) > @@ -706,7 +706,7 @@ > > > > - > + > > select="../@id"/> > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (COCOON-2204) ft:group internal div not handled correctly.
[
https://issues.apache.org/jira/browse/COCOON-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592684#action_12592684
]
kambha edited comment on COCOON-2204 at 4/27/08 3:07 PM:
--
Quote: Is there still any documentation out there in which we say to prefix
summary with [PATCH]? We have the "Patch available" check box now which is
sufficient.
Probably not. Case of Monkey see, Monkey do.
was (Author: kambha):
{quote}
Is there still any documentation out there in which we say to prefix summary
with [PATCH]? We have the "Patch available" check box now which is sufficient.
{quote}
Probably not. Case of Monkey see, Monkey do.
> ft:group internal div not handled correctly.
>
>
> Key: COCOON-2204
> URL: https://issues.apache.org/jira/browse/COCOON-2204
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Forms
>Affects Versions: 2.2, 2.2-dev (Current SVN)
>Reporter: Kamal Bhatt
> Fix For: 2.2-dev (Current SVN)
>
>
> According to this page:
> http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html
> If you you are using Ajax, a div (or similar element) must surround the
> fields of a group. eg:
>
>
>
>
>
>
> CForms (through the magic of the forms-field-styling.xsl) will put the
> group's id on the div. The code to this, seems broken as it does not match on
> the div, but on the fi:group.
> NOTE: This is another solution to the problem described here:
> https://issues.apache.org/jira/browse/COCOON-1825
> However, the solution described within it seems to make the suggestion in
> http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html redundant. Either
> way, either this issue or that one is not necessary.
> Patch is provided below:
> Index:
> D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl
> ===
> ---
> D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl
> (revision 651922)
> +++
> D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl
> (working copy)
> @@ -706,7 +706,7 @@
>
>
>
> -
> +
>
> select="../@id"/>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2204) ft:group internal div not handled correctly.
[
https://issues.apache.org/jira/browse/COCOON-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592684#action_12592684
]
Kamal Bhatt commented on COCOON-2204:
-
{quote}
Is there still any documentation out there in which we say to prefix summary
with [PATCH]? We have the "Patch available" check box now which is sufficient.
{quote}
Probably not. Case of Monkey see, Monkey do.
> ft:group internal div not handled correctly.
>
>
> Key: COCOON-2204
> URL: https://issues.apache.org/jira/browse/COCOON-2204
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Forms
>Affects Versions: 2.2, 2.2-dev (Current SVN)
>Reporter: Kamal Bhatt
> Fix For: 2.2-dev (Current SVN)
>
>
> According to this page:
> http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html
> If you you are using Ajax, a div (or similar element) must surround the
> fields of a group. eg:
>
>
>
>
>
>
> CForms (through the magic of the forms-field-styling.xsl) will put the
> group's id on the div. The code to this, seems broken as it does not match on
> the div, but on the fi:group.
> NOTE: This is another solution to the problem described here:
> https://issues.apache.org/jira/browse/COCOON-1825
> However, the solution described within it seems to make the suggestion in
> http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html redundant. Either
> way, either this issue or that one is not necessary.
> Patch is provided below:
> Index:
> D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl
> ===
> ---
> D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl
> (revision 651922)
> +++
> D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl
> (working copy)
> @@ -706,7 +706,7 @@
>
>
>
> -
> +
>
> select="../@id"/>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2204) [PATCH] ft:group internal div not handled correctly.
[ https://issues.apache.org/jira/browse/COCOON-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamal Bhatt updated COCOON-2204: Summary: [PATCH] ft:group internal div not handled correctly. (was: [PATCH] ) Changed title to something more descriptive than just [PATCH]. > [PATCH] ft:group internal div not handled correctly. > > > Key: COCOON-2204 > URL: https://issues.apache.org/jira/browse/COCOON-2204 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Forms >Affects Versions: 2.2, 2.2-dev (Current SVN) > Reporter: Kamal Bhatt > Fix For: 2.2-dev (Current SVN) > > > According to this page: > http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html > If you you are using Ajax, a div (or similar element) must surround the > fields of a group. eg: > > > > > > > CForms (through the magic of the forms-field-styling.xsl) will put the > group's id on the div. The code to this, seems broken as it does not match on > the div, but on the fi:group. > NOTE: This is another solution to the problem described here: > https://issues.apache.org/jira/browse/COCOON-1825 > However, the solution described within it seems to make the suggestion in > http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html redundant. Either > way, either this issue or that one is not necessary. > Patch is provided below: > Index: > D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl > === > --- > D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl > (revision 651922) > +++ > D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl > (working copy) > @@ -706,7 +706,7 @@ > > > > - > + > > select="../@id"/> > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2204) [PATCH]
[PATCH] Key: COCOON-2204 URL: https://issues.apache.org/jira/browse/COCOON-2204 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2, 2.2-dev (Current SVN) Reporter: Kamal Bhatt Fix For: 2.2-dev (Current SVN) According to this page: http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html If you you are using Ajax, a div (or similar element) must surround the fields of a group. eg: CForms (through the magic of the forms-field-styling.xsl) will put the group's id on the div. The code to this, seems broken as it does not match on the div, but on the fi:group. NOTE: This is another solution to the problem described here: https://issues.apache.org/jira/browse/COCOON-1825 However, the solution described within it seems to make the suggestion in http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html redundant. Either way, either this issue or that one is not necessary. Patch is provided below: Index: D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl === --- D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (revision 651922) +++ D:/workspace-java/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/forms-field-styling.xsl (working copy) @@ -706,7 +706,7 @@ - + -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-1902) Remove reliance on Ajax for non-ajax CForms
Remove reliance on Ajax for non-ajax CForms --- Key: COCOON-1902 URL: http://issues.apache.org/jira/browse/COCOON-1902 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.8, 2.1.9, 2.1.10-dev (current SVN) Reporter: Kamal Bhatt Currently, Ajax libraries are required for CForms, even when they are not used. This adds over 200KB to a page, making CForms unacceptable option for commercial, consumer websites. For CForms to be viable option for entry forms on a commercial, consumer website, the amount of javascript code that is bundled with CForms need to greatly reduced. This was not a problem in 2.1.7. -- 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-1896) Sendmail requires documentation on geronmio libraries
Sendmail requires documentation on geronmio libraries - Key: COCOON-1896 URL: http://issues.apache.org/jira/browse/COCOON-1896 Project: Cocoon Issue Type: Improvement Components: - Documentation Affects Versions: 2.1.8, 2.1.9, 2.1.10-dev (current SVN) Reporter: Kamal Bhatt Currently, if you want to use the sendmail action (http://cocoon.apache.org/2.1/userdocs/optional/sendmail-action.html), you must ensure that the geronimo-spec-javamail-*.jar and geronimo-spec-activation-*.jar are not bundled with your webapp. This is mentioned in wiki, but should be on the main website as it leads to strange behaviour (the email says it is sent successfully, but it is not sent at all). The same probably applies to the sendmail logicsheet (http://cocoon.apache.org/2.1/userdocs/logicsheets/sendmail.html). -- 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
