Re: regexp
Ralph Goers wrote: So once all references in our code are gone it can be removed? Maybe not, ie xalan needs regexp. :-S Best Regards, Antonio Gallardo. Joerg Heinicke wrote: On 10.02.2006 23:29, Ralph Goers wrote: I ran a grep a while ago and found that there was one other place that used Jakarta regexp. I think it was SourceUtil. I did not change that. Jakarta regexp is in the lib/endorsed directory. I have no idea why. I presume some other package we are using requires it. It is in the endorsed dir because an older version of it comes with the newer Sun JDKs (I think 1.5 and later). So we have the same problem as with the XML libs. Jörg
Re: regexp
So once all references in our code are gone it can be removed? Joerg Heinicke wrote: On 10.02.2006 23:29, Ralph Goers wrote: I ran a grep a while ago and found that there was one other place that used Jakarta regexp. I think it was SourceUtil. I did not change that. Jakarta regexp is in the lib/endorsed directory. I have no idea why. I presume some other package we are using requires it. It is in the endorsed dir because an older version of it comes with the newer Sun JDKs (I think 1.5 and later). So we have the same problem as with the XML libs. Jörg
Re: Fine Tuning Ajax Handling in CForms
> Why do you need such flexibility? Concretely, I was running in to http://issues.apache.org/jira/browse/COCOON-1570 and realized that I could get what I needed by simply switching out of ajax mode (plus scrolling back up to the top of the page). And then I discovered that there was no simple way to switch out of ajax mode. The first way I discovered to switch out of ajax mode was to embellish onclick with "cocoon.forms.ajax=false; forms_submitForm(this, '[EMAIL PROTECTED]'); return false". I could do that with fi:style, but it was clunky. I tried to embellish the onclick and onsubmit in the xsl, but that still felt clunky, so my approach evolved a bit. Bottom line, in my current application, I have certain page widgets that benefit from ajax updates to the form, however, the final form-level validation is simpler if i can switch out of ajax mode. This patch lets me do that. It felt useful, but I could be convinced otherwise. It /may/ be that once I fix 1570, that 1774 will be less critical, but I don't like that AJAX is all or nothing, as to me it feels a bit like it should be a per-widget decision. > > Note that the patch files also include a fix to a separate AJAX issue. > > > > forms_onsubmitHandlers = null > > > > Causes problems when in AJAX mode - submit handlers are only called > > the first time an ajax submit is called. Thereafter, the array of > > handlers is null, and none are called. > > > > Yeah, that's a problem. But we cannot keep it either, as some of the > handlers are registered by widgets that are replaced by the update. > > The move to Dojo which I'm currently working on should solve this issue. Excellent. We can keep or leave those lines, but my application doesn't work without a patch. I tried to still clear the forms_onsubmitHandlers when not in ajax mode. I'm open to alternate suggestions. This related item also seemed interesting http://issues.apache.org/jira/browse/COCOON-1718 and may relate to these types of issues. Let me know if I can be helpful with the Dojo work. Regards, Eric
Re: regexp
On 10.02.2006 23:29, Ralph Goers wrote: I ran a grep a while ago and found that there was one other place that used Jakarta regexp. I think it was SourceUtil. I did not change that. Jakarta regexp is in the lib/endorsed directory. I have no idea why. I presume some other package we are using requires it. It is in the endorsed dir because an older version of it comes with the newer Sun JDKs (I think 1.5 and later). So we have the same problem as with the XML libs. Jörg
[jira] Commented: (COCOON-1774) Fine Tuning Ajax Handling in CForms
[ http://issues.apache.org/jira/browse/COCOON-1774?page=comments#action_12365995 ] Sylvain Wallez commented on COCOON-1774: Can you elaborate on the need for widget-level ajax="false"? Also the submit handlers cannot be kept after an Ajax submit, as some of the handlers can be registered by widgets that are replaced by the Ajax response > Fine Tuning Ajax Handling in CForms > --- > > Key: COCOON-1774 > URL: http://issues.apache.org/jira/browse/COCOON-1774 > Project: Cocoon > Type: Improvement > Components: Blocks: Forms, Blocks: Ajax > Versions: 2.1.8 > Reporter: Eric Meyer > Assignee: Antonio Gallardo > Attachments: fi-styling-ajax-false.patch.txt > > Currently, it's all or nothing when it comes to using AJAX on a form. With > this enhancement, form widgets can be marked with />, and they will trigger a non-ajax form submission. > This was particularly useful on the main submit buttons on a form > inconjunction with the fi:validation-messages element (see > http://issues.apache.org/jira/browse/COCOON-1570 for why > fi:validation-messages doesn't work with AJAX). Regardless, I believe it is > useful to give the developer control over which widgets use AJAX and which do > not. > Note that the patch files also include a fix to a separate AJAX issue. > forms_onsubmitHandlers = null > Causes problems when in AJAX mode - submit handlers are only called the first > time an ajax submit is called. Thereafter, the array of handlers is null, and > none are called. -- 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: Fine Tuning Ajax Handling in CForms
Quoin Developers wrote: Currently, it's all or nothing when it comes to using AJAX on a form. With this enhancement, form widgets can be marked with , and they will trigger a non-ajax form submission. I believe it is useful to give the developer control over which widgets use AJAX and which do not. Why do you need such flexibility? Note that the patch files also include a fix to a separate AJAX issue. forms_onsubmitHandlers = null Causes problems when in AJAX mode - submit handlers are only called the first time an ajax submit is called. Thereafter, the array of handlers is null, and none are called. Yeah, that's a problem. But we cannot keep it either, as some of the handlers are registered by widgets that are replaced by the update. The move to Dojo which I'm currently working on should solve this issue. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: regexp, Re: svn commit: r375161 - in /cocoon/branches/BRANCH_2_1_X:src/java/org/apache/cocoon/transformatio n/ src/jdk1.3/ src/jdk1.3/java/ src/jdk1.3/java/org/src/jdk1.3/java/o
I was testing the login page of the portal on my 2.4GHz linux machine. I tested using JMeter with from 7 to 20 threads. Before the change I was able to get a throughput of about 3.9 requests/second. After the change it went to 5.4 requests/second. The regexp is hardcoded in the EncodeURLTransformer and did not change. The only change I made was to replace RE with Pattern and the match call to match the JDK 1.4 syntax. I ran a grep a while ago and found that there was one other place that used Jakarta regexp. I think it was SourceUtil. I did not change that. Jakarta regexp is in the lib/endorsed directory. I have no idea why. I presume some other package we are using requires it. Ralph Vadim Gritsenko said: > [EMAIL PROTECTED] wrote: >> Replace jakarta regexp with java.util.regexp on jdk 1.4 builds for >> better reliability and improved performance. > > So question is, is it faster now? How much faster and on what regexp/data? > > Vadim >
Re: New skin for web site
Jean-Baptiste Quenot wrote: * hepabolu: BTW do you like the layout of the Notes, Warnings and Fixes? (See samples page) I'm sure these admonitions could be improved. I would recommend using icons, like these: http://jimmac.musichall.cz/i.php?i=docbook Also available here: http://cvs.gnome.org/viewcvs/gimp-help-2/images/ Under wich License are being distributed this icons? Best Regards, Antonio Gallardo.
[jira] Updated: (COCOON-1774) Fine Tuning Ajax Handling in CForms
[ http://issues.apache.org/jira/browse/COCOON-1774?page=all ] Antonio Gallardo updated COCOON-1774: - Component: Blocks: Ajax Version: 2.1.8 (was: 2.1.9-dev (current SVN)) > Fine Tuning Ajax Handling in CForms > --- > > Key: COCOON-1774 > URL: http://issues.apache.org/jira/browse/COCOON-1774 > Project: Cocoon > Type: Improvement > Components: Blocks: Forms, Blocks: Ajax > Versions: 2.1.8 > Reporter: Eric Meyer > Assignee: Antonio Gallardo > Attachments: fi-styling-ajax-false.patch.txt > > Currently, it's all or nothing when it comes to using AJAX on a form. With > this enhancement, form widgets can be marked with />, and they will trigger a non-ajax form submission. > This was particularly useful on the main submit buttons on a form > inconjunction with the fi:validation-messages element (see > http://issues.apache.org/jira/browse/COCOON-1570 for why > fi:validation-messages doesn't work with AJAX). Regardless, I believe it is > useful to give the developer control over which widgets use AJAX and which do > not. > Note that the patch files also include a fix to a separate AJAX issue. > forms_onsubmitHandlers = null > Causes problems when in AJAX mode - submit handlers are only called the first > time an ajax submit is called. Thereafter, the array of handlers is null, and > none are called. -- 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] Assigned: (COCOON-1774) Fine Tuning Ajax Handling in CForms
[ http://issues.apache.org/jira/browse/COCOON-1774?page=all ] Antonio Gallardo reassigned COCOON-1774: Assign To: Antonio Gallardo > Fine Tuning Ajax Handling in CForms > --- > > Key: COCOON-1774 > URL: http://issues.apache.org/jira/browse/COCOON-1774 > Project: Cocoon > Type: Improvement > Components: Blocks: Forms > Versions: 2.1.9-dev (current SVN) > Reporter: Eric Meyer > Assignee: Antonio Gallardo > Attachments: fi-styling-ajax-false.patch.txt > > Currently, it's all or nothing when it comes to using AJAX on a form. With > this enhancement, form widgets can be marked with />, and they will trigger a non-ajax form submission. > This was particularly useful on the main submit buttons on a form > inconjunction with the fi:validation-messages element (see > http://issues.apache.org/jira/browse/COCOON-1570 for why > fi:validation-messages doesn't work with AJAX). Regardless, I believe it is > useful to give the developer control over which widgets use AJAX and which do > not. > Note that the patch files also include a fix to a separate AJAX issue. > forms_onsubmitHandlers = null > Causes problems when in AJAX mode - submit handlers are only called the first > time an ajax submit is called. Thereafter, the array of handlers is null, and > none are called. -- 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
regexp, Re: svn commit: r375161 - in /cocoon/branches/BRANCH_2_1_X: src/java/org/apache/cocoon/transformation/ src/jdk1.3/ src/jdk1.3/java/ src/jdk1.3/java/org/ src/jdk1.3/java/org/apache/ src/jdk1.3/
[EMAIL PROTECTED] wrote: Replace jakarta regexp with java.util.regexp on jdk 1.4 builds for better reliability and improved performance. So question is, is it faster now? How much faster and on what regexp/data? Vadim
[jira] Commented: (COCOON-1774) Fine Tuning Ajax Handling in CForms
[ http://issues.apache.org/jira/browse/COCOON-1774?page=comments#action_12365953 ] Eric Meyer commented on COCOON-1774: ASF is Granted License to the patch. > Fine Tuning Ajax Handling in CForms > --- > > Key: COCOON-1774 > URL: http://issues.apache.org/jira/browse/COCOON-1774 > Project: Cocoon > Type: Improvement > Components: Blocks: Forms > Versions: 2.1.9-dev (current SVN) > Reporter: Eric Meyer > Attachments: fi-styling-ajax-false.patch.txt > > Currently, it's all or nothing when it comes to using AJAX on a form. With > this enhancement, form widgets can be marked with />, and they will trigger a non-ajax form submission. > This was particularly useful on the main submit buttons on a form > inconjunction with the fi:validation-messages element (see > http://issues.apache.org/jira/browse/COCOON-1570 for why > fi:validation-messages doesn't work with AJAX). Regardless, I believe it is > useful to give the developer control over which widgets use AJAX and which do > not. > Note that the patch files also include a fix to a separate AJAX issue. > forms_onsubmitHandlers = null > Causes problems when in AJAX mode - submit handlers are only called the first > time an ajax submit is called. Thereafter, the array of handlers is null, and > none are called. -- 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
Fine Tuning Ajax Handling in CForms
Currently, it's all or nothing when it comes to using AJAX on a form. With this enhancement, form widgets can be marked with , and they will trigger a non-ajax form submission. I believe it is useful to give the developer control over which widgets use AJAX and which do not. Note that the patch files also include a fix to a separate AJAX issue. forms_onsubmitHandlers = null Causes problems when in AJAX mode - submit handlers are only called the first time an ajax submit is called. Thereafter, the array of handlers is null, and none are called. The patch and more detail is available at http://issues.apache.org/jira/browse/COCOON-1774. Regards, Eric Meyer, VP, Quoin, Inc.
[jira] Created: (COCOON-1774) Fine Tuning Ajax Handling in CForms
Fine Tuning Ajax Handling in CForms --- Key: COCOON-1774 URL: http://issues.apache.org/jira/browse/COCOON-1774 Project: Cocoon Type: Improvement Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Eric Meyer Attachments: fi-styling-ajax-false.patch.txt Currently, it's all or nothing when it comes to using AJAX on a form. With this enhancement, form widgets can be marked with , and they will trigger a non-ajax form submission. This was particularly useful on the main submit buttons on a form inconjunction with the fi:validation-messages element (see http://issues.apache.org/jira/browse/COCOON-1570 for why fi:validation-messages doesn't work with AJAX). Regardless, I believe it is useful to give the developer control over which widgets use AJAX and which do not. Note that the patch files also include a fix to a separate AJAX issue. forms_onsubmitHandlers = null Causes problems when in AJAX mode - submit handlers are only called the first time an ajax submit is called. Thereafter, the array of handlers is null, and none are called. -- 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: [RT] Using Spring instead of ECM++
Carsten Ziegeler wrote: > Vadim Gritsenko wrote: >> Leszek Gawron wrote: >>> Carsten Ziegeler wrote: So what do people think? >>> I haven't read any other replies yet but my small brain tells me to be >>> +100 on this one. >> I don't have any objections either - especially since it is backward >> compatible >> both from component and configuration POV. >> > I'll try to commit some parts of it tomorrow, so others can pick it up > and perhaps help polishing it. > Damn, I just noticed that I left my usb stick with the code on it at my company, so I'll commit it on monday or tuesday then. Grmpf. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Using Spring instead of ECM++
Vadim Gritsenko wrote: > Leszek Gawron wrote: >> Carsten Ziegeler wrote: >>> So what do people think? >> I haven't read any other replies yet but my small brain tells me to be >> +100 on this one. > > I don't have any objections either - especially since it is backward > compatible > both from component and configuration POV. > I'll try to commit some parts of it tomorrow, so others can pick it up and perhaps help polishing it. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Using Spring instead of ECM++
Leszek Gawron wrote: Carsten Ziegeler wrote: So what do people think? I haven't read any other replies yet but my small brain tells me to be +100 on this one. I don't have any objections either - especially since it is backward compatible both from component and configuration POV. Vadim
Re: How to build cocoon trunk?
Daniel Fagerstrom wrote: If you are brave enough, the best bet is by starting by taking a copy of the cocoon-webapp, rename it to something appropriate. The you update the pom to a new artifactId and to depend on the blocks that you need. You also need to copy the component (and other) configuration files _manually_ from the blocks to WEB-INF in your webapp, they are located in the WEB-INF directory of the blocks. This was done by the ant task before, but no one have written any Maven replacement yet. After this it might work ;) /Daniel Thanks a lot for your help Daniel. Vil. -- http://www.vilyaharvey.com
Re: Jira Bug?, Re: [jira] Updated: (COCOON-1558) [PATCH] Fix for validation-error tag in FormsTemplateTransformer
Joerg Heinicke wrote: On 03.02.2006 14:08, Vadim Gritsenko wrote: [ http://issues.apache.org/jira/browse/COCOON-1558?page=all ] Jean-Baptiste Quenot updated COCOON-1558: - Bugzilla Id: (was: 35673) Why bugzilla id is lost here, and in many other issues? Is it Jira bug (or user problem)? If you have a look at the Jira URL you will see that the Jira issue is still correctly linked to the Bugzilla issue. I guess it is due to another bug in it :) Since value was indeed reset as shown on page linked above: Field Original Value New Value Bugzilla Id 35673 (closer to the bottom) We have to thank them for producing bugs in pairs! ;-) Vadim
[jira] Updated: (COCOON-1570) fi:validation-errors styling element does not work in AJAX mode
[ http://issues.apache.org/jira/browse/COCOON-1570?page=all ] Jean-Baptiste Quenot updated COCOON-1570: - Assign To: Jean-Baptiste Quenot (was: Jason Johnston) > fi:validation-errors styling element does not work in AJAX mode > --- > > Key: COCOON-1570 > URL: http://issues.apache.org/jira/browse/COCOON-1570 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.8 > Environment: Operating System: other > Platform: Other > Reporter: Jason Johnston > Assignee: Jean-Baptiste Quenot > > The styling element does not work in AJAX mode, > because > it is not generated by a template element and therefore has no way to signal > whether or not it needs to be updated. > An equivalent template "ft:" element should be created to replace the current > "fi:" element, which creates its own instance representation with the optional > bu:replace wrapper when necessary. > See the following threads for discussion: > http://marc.theaimsgroup.com/?t=11229292151&r=1&w=2 > http://marc.theaimsgroup.com/?t=11229747071&r=1&w=2 -- 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] Commented: (COCOON-1570) fi:validation-errors styling element does not work in AJAX mode
[ http://issues.apache.org/jira/browse/COCOON-1570?page=comments#action_12365874 ] Jean-Baptiste Quenot commented on COCOON-1570: -- Yes indeed, your patch is more than welcome, it will help to resolve this issue in a timely manner. > fi:validation-errors styling element does not work in AJAX mode > --- > > Key: COCOON-1570 > URL: http://issues.apache.org/jira/browse/COCOON-1570 > Project: Cocoon > Type: Bug > Components: Blocks: Forms > Versions: 2.1.8 > Environment: Operating System: other > Platform: Other > Reporter: Jason Johnston > Assignee: Jason Johnston > > The styling element does not work in AJAX mode, > because > it is not generated by a template element and therefore has no way to signal > whether or not it needs to be updated. > An equivalent template "ft:" element should be created to replace the current > "fi:" element, which creates its own instance representation with the optional > bu:replace wrapper when necessary. > See the following threads for discussion: > http://marc.theaimsgroup.com/?t=11229292151&r=1&w=2 > http://marc.theaimsgroup.com/?t=11229747071&r=1&w=2 -- 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: New skin for web site
* hepabolu: > BTW do you like the layout of the Notes, Warnings and Fixes? (See samples > page) I'm sure these admonitions could be improved. I would recommend using icons, like these: http://jimmac.musichall.cz/i.php?i=docbook Also available here: http://cvs.gnome.org/viewcvs/gimp-help-2/images/ -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: OSGi dependencies in cocoon-core
Reinhard Poetz wrote: Do we still need the OSGi dependencies in the cocon-core module? AFAIU the OSGi stuff will go into a separate module (cocoon-blocks-fw-osgi-impl) which will be based on Equinox. Can I do the cleanup? Yes, but you need to move o.a.c.core.osgi from cocoon-core. Maybe you could move it to whiteboard/osgi, so can I find a better home for it later on.. /Daniel
[jira] Closed: (COCOON-1745) [cocoon-deployer-core] Tidy up test suite
[ http://issues.apache.org/jira/browse/COCOON-1745?page=all ] Reinhard Poetz closed COCOON-1745: -- Resolution: Fixed The unit tests reflect the current state of what blocks are again. > [cocoon-deployer-core] Tidy up test suite > - > > Key: COCOON-1745 > URL: http://issues.apache.org/jira/browse/COCOON-1745 > Project: Cocoon > Type: Sub-task > Components: - Build System: Maven > Reporter: Reinhard Poetz > Assignee: Reinhard Poetz > > The test suite runs through (at the moment of writing this) but contains some > wrong examples in parts that are not tested by assertions. This needs to be > corrected so that it doesn't confuse people studying the code. -- 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
OSGi dependencies in cocoon-core
Do we still need the OSGi dependencies in the cocon-core module? AFAIU the OSGi
stuff will go into a separate module (cocoon-blocks-fw-osgi-impl) which will be
based on Equinox. Can I do the cleanup?
--
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
[jira] Created: (COCOON-1773) [cocoon-deployer-core] Make transactional behaviour configureable
[cocoon-deployer-core] Make transactional behaviour configureable - Key: COCOON-1773 URL: http://issues.apache.org/jira/browse/COCOON-1773 Project: Cocoon Type: Sub-task Components: - Build System: Maven Reporter: Reinhard Poetz Assigned to: Reinhard Poetz Priority: Minor The transactional behaviour comes with the price of losing speed when doing filesystem operations. Make it configureable so that the user can decide what he wants. -- 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 trunk
Sounds like a problem that I introduced in a refactoring early this week and removed in revision 376095. Have you updated to that revision? /Daniel Ralph Goers wrote: Well, it almost worked. It started up but when I entered the url in the browser I got javax.servlet.ServletException: Couldn't find COB-INF/block-sitemap.xmap. Reinhard Poetz wrote: Ralph Goers wrote: OK. I am now able to build trunk. Now what? Does anything run at the moment? Yes, ./trunk/cocoon-blocks-fw/cocoon-blocks-fw-sample/ (just call 'mvn package jetty6:run' from the module's base directory) should be useable again and I plan to make the first tutorial (https://issues.apache.org/jira/browse/COCOON-1750) work today (MET).
