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: 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. 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: [Corona] PIpeline API
Reinhard Pötz wrote: 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.) Yes, I'm not concerned about the jar size itself, I'm concerned about dependencies. The ideal solution would be to have an api jar which has no other dependencies, perhaps one to a logging framework if we provide utility or abstract classes. 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? I've some pipeline components that open/close resources, like a JCR session for instance. If the contract includes that the pre and post processing methods are always called, the post processing method acts like kind of a disposal method where I can close my session. I've other - in this sense rather obscure - use cases where the pipeline components need to pass information back to the caller before the processing starts. So the caller calls the pre processing method where the pipeline component adds something to the map, the caller can pick it up and then start the processing based in this information. 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. Great :) So how do we proceed? Do you mind if I start with the minor changes? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Gabriel Gruber/Workflow is out of office.
I will be out of the office starting 14.07.2008 and will not return until 31.07.2008. Ich bin bis zum 30.07.2008 auf Urlaub und ab 31.07.2008 wieder für Sie erreichbar. Bei technischen Fragen zum System Webdesk wenden Sie sich bitte vertrauensvoll an Hrn. Gutzelnig oder Hrn. Stastny. Bei Fragen zu laufenden Projekten wenden Sie sich bitte an Hrn. Gutzelnig! In dringenden Fällen versuchen Sie es auf meinem Handy: +43 - 676 - 3939435! mit freundlichen Grüssen Gabriel Gruber
Re: [Corona] PIpeline API
Carsten Ziegeler wrote:
Reinhard Pötz wrote:
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.)
Yes, I'm not concerned about the jar size itself, I'm concerned about
dependencies. The ideal solution would be to have an api jar which has
no other dependencies, perhaps one to a logging framework if we provide
utility or abstract classes.
currently corona-pipeline (pipeline API, pipeline impls, SAX components)
only has a dependency on commons-logging. Is this good enough for your
needs?
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?
I've some pipeline components that open/close resources, like a JCR
session for instance. If the contract includes that the pre and post
processing methods are always called, the post processing method acts
like kind of a disposal method where I can close my session.
I've other - in this sense rather obscure - use cases where the pipeline
components need to pass information back to the caller before the
processing starts. So the caller calls the pre processing method where
the pipeline component adds something to the map, the caller can pick it
up and then start the processing based in this information.
thanks
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.
Great :)
So how do we proceed? Do you mind if I start with the minor changes?
of course not :-)
Corona comes with integration tests that you can run by invoking
mvn clean install -P it -Dhtmlunit.base-url=http://localhost:
from the root directory. Please make sure that they run through after
your refactorings. Many thanks in advance!
--
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: AW: Client-side validation in CForms
Hi Christofer On 13 Jul 2008, at 13:13, Christofer Dutz wrote: 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. I had a look as well and did not fancy ploughing in to the code to add this right now, as I have so much else to do before I can release the client-side stuff (hence asking for volunteers ) What I am working on in the meantime is using the (existing) fi:datatype base=string|integer|long|double|float|decimal/ tags to perform basic datatype validation on the client. My hope is that adding support for this now, will make it easier to add fuller validation client-side in the future. BTW. Christofer, I attempted to contact you earlier about the private work you said you had been doing on Dojo 1.1, to see if I could roll it into my work. If you are interested in contributing, please contact me off-list. Many thanks regards Jeremy -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
Hi Kamal One of the items on my (long) list of jobs to get done, in my re- working of CForms/Dojo is compression/minifying/packaging etc. There are a number of different scenarios that I can imagine people will want to for it, but TBH, I have not thought it all through yet 1) development : uncompressed/un-minified, each 'class' loads separately 2) production (a) : single compressed/minified js file containing just the dojo and cforms code to support one cform, application or site. 3) production (b) : single compressed/minified js file containing just the cforms code to support one cform, application or site, with dojo loaded from CDN. 4) production (c) : load everything from CDN (i.e. arrange to put versionned CForms JS in eg. http://code.google.com/apis/ajaxlibs/) no idea if they'd be up for it . As I said, I have not looked into this very closely yet, but I assumed the first level of support would be documentation on how to use Dojo's built-in compressor within Cocoon manually, with support in the XSLT to allow a developer to specify a specific js file to load instead of all of individual dojo/cforms. I think you need a config file to drive dojo's compressor. It would be interesting to see if this could be automated by a maven or ant build task. regards Jeremy On 12 Jul 2008, at 05:24, 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. 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). Apologies if something like this already exists. Cheers. [1] http://www.crockford.com/javascript/jsmin.html [2] http://dojotoolkit.org/docs/shrinksafe [3] http://developer.yahoo.com/yui/compressor/ [4] http://dean.edwards.name/packer/src/
AW: AW: Client-side validation in CForms
Hi Jeremy,
Doesn't dojo already add support for this? I have a custom xslt transforming
integer-widgets to NumberTextBox dates to DateTextBox and so on. One thing I
was working on was to support server side validation errors. The only
solution I could come up for here, was to add a client side regexp that is
always false, but I thought yuck! every time I saw the code so I removed
it again ... I'll send you my xslt (even if it depends on some Java-Script I
wrote). It's really basic and only supports the usecases I used in my
application. But maybe it helps. Now please don't complain about the really
basic xslt ... I didnt want to get lost in XSLT issues and wanted to
concentrate on the Dojo Support ... One thing I have to mention ... I user
TinyMCE as HTMLArea Widget.
I think generating the validation-output needed for client side-validation
shouldn't be a big problem, since its the same for almost all widgets the
class having to be patched should be the simple Widget base-classes. I would
volunteer implementing it, but only if it is really wanted.
Chris
?xml version=1.0?
xsl:stylesheet version=2.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:fi=http://apache.org/cocoon/forms/1.0#instance;
exclude-result-prefixes=fi
xsl:template match=page
page
!--xsl:if test=//fi:field[(fi:datatype/@type='string') and
(fi:styling/@type='htmlarea')]
xsl:text disable-output-escaping=yes
![CDATA[script language=javascript type=text/javascript
src=/resources/forms/tiny_mce/tiny_mce_src.js/script]]
/xsl:text
/xsl:if--
script type=text/javascript dojo.require(dijit.form.TextBox);
xsl:if
test=//fi:field/fi:[EMAIL PROTECTED]'date']dojo.require(dijit.form.DateTex
tBox); /xsl:if
xsl:if test=//fi:field[(fi:datatype/@type='integer') or
(fi:datatype/@type='float')]
dojo.require(dijit.form.NumberTextBox); /xsl:if
xsl:if test=//fi:field[(fi:datatype/@type='string') and
fi:selection-list]
dojo.require(dijit.form.FilteringSelect); /xsl:if
xsl:if
test=//fi:booleanfielddojo.require(dijit.form.CheckBox); /xsl:if
dojo.parser.parse(dojo.byId('xsl:value-of select=@name/'));
/script
xsl:apply-templates select=* | text()/
/page
/xsl:template
!--
Form Fields handling
--
xsl:template match=fi:[EMAIL PROTECTED] = 'cweb'] priority=5
form id=[EMAIL PROTECTED] class=soria onsubmit=return false;
xsl:copy-of select=@*/
input type=hidden name=forms_submit_id/
xsl:apply-templates/
/form
xsl:if test=//fi:validation-message
table
xsl:for-each select=//fi:validation-message
tr
td
xsl:value-of select=../@id/: xsl:value-of select=./
/td
/tr
/xsl:for-each
/table
/xsl:if
/xsl:template
xsl:template match=fi:form-template priority=0
form class=soria
xsl:copy-of select=@*/
xsl:apply-templates/
/form
xsl:if test=//fi:validation-message
table
xsl:for-each select=//fi:validation-message
tr
td
xsl:value-of select=../@id/: xsl:value-of select=./
/td
/tr
/xsl:for-each
/table
/xsl:if
/xsl:template
xsl:template match=fi:continuation-id
input type=hidden name=continuation-id value={.}/
/xsl:template
!--
//
// Widget definitions
//
/
--
xsl:template match=fi:field[fi:styling/@type='hidden'] priority=6
input type=hidden name=[EMAIL PROTECTED]
xsl:attribute name=value
xsl:value-of select=fi:value/
/xsl:attribute
/input
/xsl:template
!--
date widget
--
xsl:template match=fi:field[fi:datatype/@type='date'] priority=0
xsl:choose
xsl:when test=@state = 'output'
xsl:value-of select=fi:value/
/xsl:when
xsl:when test=@state = 'active'
input type=text name=[EMAIL PROTECTED]
dojoType=dijit.form.DateTextBox
xsl:attribute name=value
xsl:value-of select=fi:value/
/xsl:attribute
xsl:if test=@required = 'true'
xsl:attribute name=requiredtrue/xsl:attribute
/xsl:if
xsl:if test=@listening = 'true'
xsl:attribute
name=onchangeforms_submitForm(this)/xsl:attribute
/xsl:if
xsl:copy-of select=fi:styling/@style/
/input
/xsl:when
/xsl:choose
/xsl:template
!--
integer widget
--
xsl:template match=fi:field[fi:datatype/@type='integer'] priority=0
xsl:choose
xsl:when test=@state = 'output'
xsl:value-of select=fi:value/
/xsl:when
xsl:when test=@state = 'active'
input type=text name=[EMAIL PROTECTED]
dojoType=dijit.form.NumberTextBox
Re: Objects inherited in subrequests
sorry, was to quick :(( So I decided to patch the DefaultIncludeCacheManager to work in the same way as the IncludeTransformer does, by setting up the child threads with the same context/environment: // Setup this thread's environment RequestContextHolder.setRequestAttributes( this.session.getRequestAttributes()); EnvironmentHelper.enterProcessor(this.session.getProcessor(), this.session.getEnvironment()); I'll test this out, and if it work's I send in the patch. it does not help. It's the way it's meant to work, but it doesn't. Somehow the ObjectModels in the parallel running JXTemplateGenerators affect each other and we have strange side affects on most of our request. we are digging around, but no ideas any more how to fix it... any help would be appreciated. Christoph
Re: Objects inherited in subrequests
Hello all
Grzegorz as u wrote...
Therefore I would like to propose introduction of a new scope called
request-inheritable which
would allow beans (like ObjectModel) to be inherited but by cloning.
can you please elaborate on that ... coz thats where we are stuck ...
if u have a look at the AbstractInterpreter.java file
public void forwardTo(String uri, Object bizData,
WebContinuation continuation,
Redirector redirector)
throws Exception {
if (SourceUtil.indexOfSchemeColon(uri) == -1) {
uri = cocoon:/ + uri;
final Map objectModel =
this.processInfoProvider.getObjectModel();
FlowHelper.setWebContinuation(objectModel, newObjectModel,
continuation);
FlowHelper.setContextObject(objectModel, newObjectModel,
bizData);
if (redirector.hasRedirected()) {
throw new IllegalStateException(Pipeline has already
been processed for this request);
}
// this is a hint for the redirector
objectModel.put(cocoon:forward, true);
redirector.redirect(false, uri);
} else {
throw new Exception(uri is not allowed to contain a scheme
(cocoon:/ is always automatically used));
}
}
so the instance of newObjectModel is the one from the bean factory ...
and if u have multithreading then all the threads change that
objectmodel simultaneously and then finally the objectmodel coming to
the JXTemplategenerator(Injected by spring) is not thread specific ...
in the setup method of the generator class we replace the objectmodel
injected by spring with the one passed with that method ... after doing
this the errors are not that frequent .. but they are still there :( ..
its still being modified by some other threads ...
Could you please let us know how do u intend to implement ur proposed
solution
regards
Imran
Christoph Gaffga (triplemind.com) wrote:
sorry, was to quick :((
So I decided to patch the DefaultIncludeCacheManager to work in the
same
way as the IncludeTransformer does, by setting up the child threads
with
the same context/environment:
// Setup this thread's environment
RequestContextHolder.setRequestAttributes(
this.session.getRequestAttributes());
EnvironmentHelper.enterProcessor(this.session.getProcessor(),
this.session.getEnvironment());
I'll test this out, and if it work's I send in the patch.
it does not help. It's the way it's meant to work, but it doesn't.
Somehow the ObjectModels in the parallel running JXTemplateGenerators
affect each other and we have strange side affects on most of our
request.
we are digging around, but no ideas any more how to fix it...
any help would be appreciated.
Christoph
