Re: [GSoC-Springification] Status
Lukas Lang wrote:
Hello everybody,
I want to notify you about my actual status on my GSoC project.
The eventcache block has already been migrated to Spring, which means,
the project is on track.
Currently, I'm setting up integration tests for the
block and fixing small bugs, occured through migration.
I will approximately finish eventcache this week (including JIRA issues
patches).
Reinhard I were discussing, if moving the pipes section from the xmap
to the Spring xml-bean definition is required.
... and of course it's not your job to migrate pipeline implementations
from Avalon to Spring.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
AW: Client-side validation in CForms
When I was working on my first attempts to do exactly what you are trying to do (CForms using dojo 1.1 and client side validation), I ran into exactly the same problem as you did. I too think it would be easily possible to implement client and server-side validation using dojo. Even if it would not be possible to implement all. Unfortunately the fi-output is hard-coded into the widget class implementation and no validation information is sent. Making client-side validation work, it would make it necessary to patch every single Widget class to output this validation-data, but should be easy to accomplish. I stopped my work on this, since I had doubt's anyone would be interested in a feature like this and the thought of having to maintain patches for so many classes let me drop that idea. Chris -Ursprüngliche Nachricht- Von: Jeremy Quinn [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 9. Juli 2008 17:17 An: dev@cocoon.apache.org Betreff: Client-side validation in CForms 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) 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
Re: Proposal - JS Reader
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
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.
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.
Apologies if something like this already exists.
Not that I know of. You are welcome!
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
Re: [Corona] PIpeline API
Carsten Ziegeler wrote:
Hi,
I'm currently looking for a nice and simple pipeline api to be
integrated with Apache Sling :)
And of course I had a quick look at Corona (as everything else I found
was not what I was searching for) which would be the prefered way of
implementing pipelines :)
great!
Now, I only need the naked pipeline stuff - and most important here are
the interfaces and perhaps a simple pipeline implementation (without
caching).
There are some points I would like to discuss:
a) Simple API separated from the implementation
I think it makes sense to put all API stuff into one single package,
these are only a handfull of classes - perhaps there might be an
additional util package.
The implementations of the various components should go into a different
module as they are not needed by everyone. At least they should be in a
different package for modularization purposes.
I would also package the whole caching stuff into an own module.
I agree with you that the package structure should be cleaned up. It's
also a good idea to create a 'corona-pipeline-sax' module that contains
the SAX based components. I'm not so sure if we should really move the
pipeline implementations into their own modules. This seems to be too
much modularization for my taste. (The corona-pipeline.jar, that
currently contains the SAX components, is about 70kb only.)
b) Actions should not be part of the pipeline api
I think we discussed this some time ago :) Removing actions from the
pipeline stuff does not really hurt - they are invoked before the
pipeline, so it shouldn't be too hard to build custom code which
collects actions, assembles the pipeline, invokes the actions and then
the pipeline.
no objection ;-)
c) Pre and post processing
As the pipeline interfaces are not tied to sax or any other model (which
is ok), there is no explicit notion of indicating that the processing
starts or is finished - the latter is especially interesting for
cleanup. So I think we should add these two lifecycle methods to the
pipeline component interface.
I don't see any problem either. Being curious, what are your use cases?
d) Splitting setup and execute
I would like to split the Pipeline#execute method into two, one for
initialisation and one (without arguments) for executing.
I was thinking about this myself because we need this separation also to
optimize conditional GET operations when the servlet URLs are involved.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
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: Proposal - JS Reader
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:
dependencies
dependency
groupIdnet.sf.alchim/groupId
artifactIdyuicompressor-maven-plugin/artifactId
version0.7.1/version
/dependency
/dependencies
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.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
