Re: [VOTE] Switch to Maven NOW
Carsten Ziegeler wrote: So please cast your votes for switching to Maven2 NOW as outlined/discussed in the proposal thread. +1
Re: Cocoon stacktraces in trunk.
Thorsten Scherler wrote: On Thu, 2005-08-18 at 20:13 +0200, Sylvain Wallez wrote: Hi all, I just committed the Cocoon stacktraces stuff to trunk. Cheers. Especially for forrest ;-) Ah, and this includes also the update to TraxTransformer that no more eats downstream exceptions. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Cocoon stacktraces in trunk.
Il giorno 18/ago/05, alle 20:13, Sylvain Wallez ha scritto: I just committed the Cocoon stacktraces stuff to trunk. Neato! There's just a small problem in this. Apparently, the exception2html.xslt stylesheet is not compatible with Saxon8. I will try to investigate the issue and maybe come up with a fix later. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: Cocoon stacktraces in trunk.
Carsten Ziegeler wrote: Current I can't compile trunk. It seems that this class is missing: org.apache.cocoon.util.location.LocatorToAttributesPipe; Sorry, I forgot to commit DomHelper in CForms (I guess this is where you have the error). Having different ongoing works in the same checkout isn't always easy to manage ;-) Anyway, this should be fixed now. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Cocoon stacktraces in trunk.
Ugo Cei wrote: Il giorno 18/ago/05, alle 20:13, Sylvain Wallez ha scritto: I just committed the Cocoon stacktraces stuff to trunk. Neato! There's just a small problem in this. Apparently, the exception2html.xslt stylesheet is not compatible with Saxon8. I will try to investigate the issue and maybe come up with a fix later. Hmm... nothing fancy in this XSL, except the use of exslt... It was quickly hacked though, so if you can come up with something nicer, just do it! Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Cocoon stacktraces in trunk.
Sylvain Wallez wrote: Sorry, I forgot to commit DomHelper in CForms (I guess this is where you have the error). Having different ongoing works in the same checkout isn't always easy to manage ;-) Anyway, this should be fixed now. :) No problem, now it compiles again. Thanks for the great work, Sylvain!! Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[FYI] followers :-)
http://www.orbeon.com/blog/2005/08/16/ops-stack-traces/ Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
[CFORMS] onsubmit called twice! with text field and @submit-on-change
I have a text field with submit-on-change and a submit button on my form:
fd:field id=P_CODPOS
fi:styling submit-on-change=true/
fd:labelC.P./fd:label
fd:hintCodi Postal/fd:hint
fd:datatype base=string/
fd:on-value-changed
javascript
...
/javascript
/fd:on-value-changed
/fd:field
fd:submit id=B_MODIFICA_PERSONA validate=true
fd:labelModificar dades/fd:label
/fd:submit
I get an alert with the message onsubmit called twice! when change the
field value and, before leave the field, push the submit button.
The same occur if I change the value of P_CODPOS and press Enter key for
submit the form.
When the field is a selection list this behavior can occur too. If I
change value and push the submit button quickly but its more improbable
the user make it voluntarily.
I have tested in Cocoon 2.1.7 with Firefox 1.0.6 and Explorer 6.0.
Is that the wished behavior?
In the forms-lib.js there is the function forms_onsubmit():
function forms_onsubmit() {
if (forms_onsubmitHandlers == null) {
alert(onsubmit called twice!);
}
for (var i = 0; i forms_onsubmitHandlers.length; i++) {
forms_onsubmitHandlers[i].forms_onsubmit();
}
// clear it
forms_onsubmitHandlers = null;
}
This function is called each time a submit is fired. The first time is
fired by the onchange event of P_CODPOS field and later the event of
submit button.
In any case, I think that this behavior of the user is possible. Must
the user see this message? It's safe just:
if (forms_onsubmitHandlers == null) {
return;
}
This don't show the alert, but follow the submit process.
Thanks,
--
Josep A. Frau [EMAIL PROTECTED]
Centre de Tecnologies de la Informació
Universitat de les Illes Balears
Re: [FYI] followers :-)
Il giorno 19/ago/05, alle 11:34, Sylvain Wallez ha scritto: http://www.orbeon.com/blog/2005/08/16/ops-stack-traces/ Yeah, but their new ajaxified XForms engine looks cool. At least, the demos do. I'm wondering whether we could reuse something for CForms. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
More Ajax in Cocoon (was Re: [FYI] followers :-))
Ugo Cei wrote: Il giorno 19/ago/05, alle 11:34, Sylvain Wallez ha scritto: http://www.orbeon.com/blog/2005/08/16/ops-stack-traces/ Yeah, but their new ajaxified XForms engine looks cool. What do you find particularily cool? Except the eye-candy when focus enters a list, I wasn't impressed. I was also surprised to see that almost every user action triggers a roundtrip to the server (the Loading spinning wheel), which puts a useless load on the server, especially on large forms where the user may tab quickly to navigate inputs. At least, the demos do. I'm wondering whether we could reuse something for CForms. The icons and the CSS? I also started looking at integrating Scriptaculous [1] and Rico's LiveGrid [2] in Cocoon, but as always it requires to dedicate time, i.e. finding a project that needs it. Scriptaculous is RoR's Ajax library and it uses a very similar approach to CForms, by sending HTML snippets for partial page updates rather than requiring large amounts of client-side application-specific logic. Actually, Ajax in Cocoon should be separated from CForms, and this is why the BrowserUpdateTransformer is in core and not in CForms. Now if we're to add more Ajax-related stuff in Cocoon, I'm not sure putting it in the core is a good thing, and a separate Ajax block may be better. WDYT? Sylvain [1] http://script.aculo.us/ [2] http://openrico.org/rico/livegrid.page -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [CFORMS] onsubmit called twice! with text field and @submit-on-change
Josep A. Frau wrote:
I have a text field with submit-on-change and a submit button on my form:
fd:field id=P_CODPOS
fi:styling submit-on-change=true/
fd:labelC.P./fd:label
fd:hintCodi Postal/fd:hint
fd:datatype base=string/
fd:on-value-changed
javascript
...
/javascript
/fd:on-value-changed
/fd:field
fd:submit id=B_MODIFICA_PERSONA validate=true
fd:labelModificar dades/fd:label
/fd:submit
I get an alert with the message onsubmit called twice! when change
the field value and, before leave the field, push the submit button.
The same occur if I change the value of P_CODPOS and press Enter key
for submit the form.
When the field is a selection list this behavior can occur too. If I
change value and push the submit button quickly but its more
improbable the user make it voluntarily.
I have tested in Cocoon 2.1.7 with Firefox 1.0.6 and Explorer 6.0.
Is that the wished behavior?
In the forms-lib.js there is the function forms_onsubmit():
function forms_onsubmit() {
if (forms_onsubmitHandlers == null) {
alert(onsubmit called twice!);
}
for (var i = 0; i forms_onsubmitHandlers.length; i++) {
forms_onsubmitHandlers[i].forms_onsubmit();
}
// clear it
forms_onsubmitHandlers = null;
}
This function is called each time a submit is fired. The first time is
fired by the onchange event of P_CODPOS field and later the event of
submit button.
In any case, I think that this behavior of the user is possible. Must
the user see this message? It's safe just:
if (forms_onsubmitHandlers == null) {
return;
}
This don't show the alert, but follow the submit process.
This occurs because the click on the button triggers both the input's
onchange and the form submit. I'll fix this.
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: Cocoon stacktraces in trunk.
On Aug 19, 2005, at 11:23 AM, Sylvain Wallez wrote:
Ugo Cei wr
Hmm... nothing fancy in this XSL, except the use of exslt... It was
quickly hacked though, so if you can come up with something nicer,
just do it!
Here's the error I get:
Error on line 61 of file:/Users/ugocei/Projects/Pulse/src/webapp/
stylesheets/exception2html.xsl:
Cannot find a matching 2-argument function named {http://exslt.org/
strings}split()
Transformation failed: Run-time errors were reported
Actually, the line with split seems to be 60 and not 61:
xsl:for-each select=str:split(ex:message, '#10;')
Which looks kosher according to http://exslt.org/str/functions/split/
index.html but Saxon does not support the EXSLT string module, it
seems: http://exslt.org/str/functions/split/index.html
The only compatible solution I see is replacing the call to str:split
with a recursive template. I'm not sure this is worth doing, as I can
work around the issue by using Xalan in my error pipelines.
WDYT?
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Wine Food Blog: http://www.divinocibo.it/
Re: Cocoon stacktraces in trunk.
Ugo Cei wrote:
On Aug 19, 2005, at 11:23 AM, Sylvain Wallez wrote:
Ugo Cei wr
Hmm... nothing fancy in this XSL, except the use of exslt... It was
quickly hacked though, so if you can come up with something nicer,
just do it!
Here's the error I get:
Error on line 61 of file:/Users/ugocei/Projects/Pulse/src/webapp/
stylesheets/exception2html.xsl:
Cannot find a matching 2-argument function named {http://exslt.org/
strings}split()
Transformation failed: Run-time errors were reported
Actually, the line with split seems to be 60 and not 61:
xsl:for-each select=str:split(ex:message, '#10;')
Which looks kosher according to http://exslt.org/str/functions/split/
index.html but Saxon does not support the EXSLT string module, it
seems: http://exslt.org/str/functions/split/index.html
The only compatible solution I see is replacing the call to str:split
with a recursive template. I'm not sure this is worth doing, as I can
work around the issue by using Xalan in my error pipelines.
WDYT?
+1 for standard xslt solution.
Vadim
Re: Cocoon stacktraces in trunk.
Hi Ugo, On Aug 19, 2005, at 5:44 AM, Ugo Cei wrote: Actually, the line with split seems to be 60 and not 61: xsl:for-each select=str:split(ex:message, '#10;') Which looks kosher according to http://exslt.org/str/functions/split/index.html but Saxon does not support the EXSLT string module, it seems That's correct; it doesn't. The only compatible solution I see is replacing the call to str:split with a recursive template. I'm not sure this is worth doing, as I can work around the issue by using Xalan in my error pipelines. How about xsl:for-each select=fn:tokenize (ex:message, '#10;') cheers, —ml—
Re: Cocoon stacktraces in trunk.
On Aug 19, 2005, at 5:58 AM, Mark Lundquist wrote: How about xsl:for-each select=fn:tokenize (ex:message, '#10;') Oops, I went off half-cocked... you need something that will still work for Xalan, huh? Never mind... —ml—
Re: More Ajax in Cocoon (was Re: [FYI] followers :-))
Sylvain Wallez wrote: Yeah, but their new ajaxified XForms engine looks cool. What do you find particularily cool? Except the eye-candy when focus enters a list, I wasn't impressed. I was also surprised to see that The icons and the CSS? I do remember my promise to build CSS-based (rather than table-based) CForms samples. Would that be still useful? I did quite some work on it in the branch version just before/after the release of 2.1.7, so I can take it up again or start from scratch with new insights etc. Are the forms-samples-styling.xsl stylesheet the same for BRANCH and TRUNK? Or do I have to redo the work? Bye, Helma
Re: Cocoon stacktraces in trunk.
Mark Lundquist wrote: On Aug 19, 2005, at 5:58 AM, Mark Lundquist wrote: How about xsl:for-each select=fn:tokenize (ex:message, '#10;') Oops, I went off half-cocked... you need something that will still work for Xalan, huh? Never mind... —ml— Maybe one can use function-available http://www.w3.org/TR/xslt#function-function-available to test if fn:tokenize or str:split exists. /Daniel
Re: More Ajax in Cocoon (was Re: [FYI] followers :-))
hepabolu wrote: Sylvain Wallez wrote: Yeah, but their new ajaxified XForms engine looks cool. What do you find particularily cool? Except the eye-candy when focus enters a list, I wasn't impressed. I was also surprised to see that The icons and the CSS? I do remember my promise to build CSS-based (rather than table-based) CForms samples. Would that be still useful? I did quite some work on it in the branch version just before/after the release of 2.1.7, so I can take it up again or start from scratch with new insights etc. Please, go ahead. Are the forms-samples-styling.xsl stylesheet the same for BRANCH and TRUNK? Or do I have to redo the work? Identical. Vadim
Re: More Ajax in Cocoon (was Re: [FYI] followers :-))
I'd move it out if keeping it in is going to keep CForms from being marked stable in 2.1.8. Sylvain Wallez wrote: Actually, Ajax in Cocoon should be separated from CForms, and this is why the BrowserUpdateTransformer is in core and not in CForms. Now if we're to add more Ajax-related stuff in Cocoon, I'm not sure putting it in the core is a good thing, and a separate Ajax block may be better. WDYT? Sylvain
Re: More Ajax in Cocoon (was Re: [FYI] followers :-))
Il giorno 19/ago/05, alle 14:25, Sylvain Wallez ha scritto: Yeah, but their new ajaxified XForms engine looks cool. What do you find particularily cool? Except the eye-candy when focus enters a list, I wasn't impressed. I was also surprised to see that almost every user action triggers a roundtrip to the server (the Loading spinning wheel), which puts a useless load on the server, especially on large forms where the user may tab quickly to navigate inputs. What I find interesting is being able to proocess XForms on the client without plugins, applets or other proprietary extensions. Like it or not, XForms is becoming more popular and having XForms support in Cocoon means that fewer people will look somewhere else when they learn that Cocoon has a proprietary forms framework, even if it currently is the best around. Being enthusiast about Ajax, I think the best way to support XForms in a browser is to use that (or the next version of Firefox, when it will have native support for XForms/SVG/etc.). Since the implementation in OPS is Open Source (AFAIK), it might be worthwhile to take a look at it. Of course, this means having another 12 hours extra per day, in addition to the 36 we all already need. ;-) Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: More Ajax in Cocoon (was Re: [FYI] followers :-))
Ugo Cei wrote: Il giorno 19/ago/05, alle 14:25, Sylvain Wallez ha scritto: Yeah, but their new ajaxified XForms engine looks cool. What do you find particularily cool? Except the eye-candy when focus enters a list, I wasn't impressed. I was also surprised to see that almost every user action triggers a roundtrip to the server (the Loading spinning wheel), which puts a useless load on the server, especially on large forms where the user may tab quickly to navigate inputs. What I find interesting is being able to proocess XForms on the client without plugins, applets or other proprietary extensions. Like it or not, XForms is becoming more popular and having XForms support in Cocoon means that fewer people will look somewhere else when they learn that Cocoon has a proprietary forms framework, even if it currently is the best around. Ah ok, I thought it was about the feature showcased in the demos. Being enthusiast about Ajax, I think the best way to support XForms in a browser is to use that (or the next version of Firefox, when it will have native support for XForms/SVG/etc.). Since the implementation in OPS is Open Source (AFAIK), it might be worthwhile to take a look at it. There's also Chiba which has Cocoon integration. I don't know its status though. Something that may be worth investigating also is a XForms-CForms translator. Could this be a bunch of XSLs? Of course, this means having another 12 hours extra per day, in addition to the 36 we all already need. ;-) I personally would like 42 hours a day (H2G2 just went out in theaters here) :-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: More Ajax in Cocoon (was Re: [FYI] followers :-))
Ralph Goers wrote: I'd move it out if keeping it in is going to keep CForms from being marked stable in 2.1.8. This has actually no relation with Ajax being in core or in a separate block. Sylvain Wallez wrote: Actually, Ajax in Cocoon should be separated from CForms, and this is why the BrowserUpdateTransformer is in core and not in CForms. Now if we're to add more Ajax-related stuff in Cocoon, I'm not sure putting it in the core is a good thing, and a separate Ajax block may be better. WDYT? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Cocoon stacktraces in trunk.
Ugo Cei wrote:
On Aug 19, 2005, at 11:23 AM, Sylvain Wallez wrote:
Ugo Cei wr
Hmm... nothing fancy in this XSL, except the use of exslt... It was
quickly hacked though, so if you can come up with something nicer,
just do it!
Here's the error I get:
Error on line 61 of file:/Users/ugocei/Projects/Pulse/src/webapp/
stylesheets/exception2html.xsl:
Cannot find a matching 2-argument function named {http://exslt.org/
strings}split()
Transformation failed: Run-time errors were reported
Actually, the line with split seems to be 60 and not 61:
xsl:for-each select=str:split(ex:message, '#10;')
Which looks kosher according to http://exslt.org/str/functions/split/
index.html but Saxon does not support the EXSLT string module, it
seems: http://exslt.org/str/functions/split/index.html
The extlt.org page is outdated, but the Saxon doc is clear about that:
http://www.saxonica.com/documentation/extensions/exslt.html
Too bad, the string module in exslt is my favourite :-(
The only compatible solution I see is replacing the call to str:split
with a recursive template. I'm not sure this is worth doing, as I can
work around the issue by using Xalan in my error pipelines.
WDYT?
Well, standard is the way to go as we can't assume everybody will want
to deploy Xalan just to have error pages.
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
wget Cocoon BRANCH 2.1.x?
Is there any URL that returns a tarball for BRANCH 2.1.x (needed to build lenya 1.4dev)? If not, is there any chance someone can create a temporary file for me somewhere? I'm working on a laptop with a mobile connection and would like to avoid paying for checking out from SVN/uploading to remote server (which does not have SVN). http://svn.apache.org/snapshots/cocoon/ does not work for me. Thanks, Manos
Re: wget Cocoon BRANCH 2.1.x?
Emmanouil Batsis wrote: http://svn.apache.org/snapshots/cocoon/ does not work for me. try http://svn.apache.org/snapshots/cocoon-2.1/
DO NOT REPLY [Bug 34069] - upgrade MyFaces libraries
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34069. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34069 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-19 16:38 --- updated to r233484. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
Re: wget Cocoon BRANCH 2.1.x?
On Friday 19 August 2005 17:29, Jorg Heymans wrote: Emmanouil Batsis wrote: http://svn.apache.org/snapshots/cocoon/ does not work for me. try http://svn.apache.org/snapshots/cocoon-2.1/ That does not seem to work either :-( Manos
Re: wget Cocoon BRANCH 2.1.x?
Emmanouil Batsis wrote: On Friday 19 August 2005 17:29, Jorg Heymans wrote: Emmanouil Batsis wrote: http://svn.apache.org/snapshots/cocoon/ does not work for me. try http://svn.apache.org/snapshots/cocoon-2.1/ That does not seem to work either :-( Do you have a hosted linux server anywhere? Log onto that, do a checkout, make your zip (even build Cocoon with just the blocks you want) zip up whatever is left and download it. Regards, Upayavira
Re: wget Cocoon BRANCH 2.1.x?
On Friday 19 August 2005 18:01, Upayavira wrote: Do you have a hosted linux server anywhere? Log onto that, do a checkout, make your zip (even build Cocoon with just the blocks you want) zip up whatever is left and download it. Unfortunately the server does not offer SVN and i have no rights to install it :-( Manos
Re: wget Cocoon BRANCH 2.1.x?
Emmanouil Batsis wrote: On Friday 19 August 2005 18:01, Upayavira wrote: Do you have a hosted linux server anywhere? Log onto that, do a checkout, make your zip (even build Cocoon with just the blocks you want) zip up whatever is left and download it. Unfortunately the server does not offer SVN and i have no rights to install it :-( wget does crawl, so if you point it to the SVN URL you can get what you want.
Re: wget Cocoon BRANCH 2.1.x?
Emmanouil Batsis wrote: Is there any URL that returns a tarball for BRANCH 2.1.x (needed to build lenya 1.4dev)? If not, is there any chance someone can create a temporary file for me somewhere? I'm working on a laptop with a mobile connection and would like to avoid paying for checking out from SVN/uploading to remote server (which does not have SVN). http://svn.apache.org/snapshots/cocoon/ does not work for me. Thanks, Manos With the impending switch to Maven, I would think that there will eventually be full binary builds. Tony
Re: wget Cocoon BRANCH 2.1.x?
On Friday 19 August 2005 18:55, Berin Loritsch wrote: wget does crawl, so if you point it to the SVN URL you can get what you want. I have already tried wget -r --no-parent http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X but that only gives me . |-- index.html `-- svn.apache.org |-- repos | `-- asf | `-- cocoon | `-- branches | `-- BRANCH_2_1_X | `-- index.html `-- robots.txt
Re: wget Cocoon BRANCH 2.1.x?
Emmanouil Batsis wrote: On Friday 19 August 2005 17:29, Jorg Heymans wrote: Emmanouil Batsis wrote: http://svn.apache.org/snapshots/cocoon/ does not work for me. try http://svn.apache.org/snapshots/cocoon-2.1/ That does not seem to work either :-( Why? These are plain tgz files... Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: wget Cocoon BRANCH 2.1.x?
Emmanouil Batsis said the following on 19.08.2005 18:15: I have already tried wget -r --no-parent http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X It works well for me: # wget http://svn.apache.org/snapshots/cocoon-2.1/cocoon-2.1_20050819161251.tar.gz Thats a snapshot of the current development tree. You want that? Greets -- Oliver Schalch [EMAIL PROTECTED] Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org smime.p7s Description: S/MIME Cryptographic Signature
Re: More Ajax in Cocoon (was Re: [FYI] followers :-))
On 19 Aug 2005, at 13:25, Sylvain Wallez wrote: Ugo Cei wrote: Il giorno 19/ago/05, alle 11:34, Sylvain Wallez ha scritto: http://www.orbeon.com/blog/2005/08/16/ops-stack-traces/ Yeah, but their new ajaxified XForms engine looks cool. What do you find particularily cool? Except the eye-candy when focus enters a list, I wasn't impressed. I was also surprised to see that almost every user action triggers a roundtrip to the server (the Loading spinning wheel), which puts a useless load on the server, especially on large forms where the user may tab quickly to navigate inputs. At least, the demos do. I'm wondering whether we could reuse something for CForms. The icons and the CSS? I also started looking at integrating Scriptaculous [1] and Rico's LiveGrid [2] in Cocoon, but as always it requires to dedicate time, i.e. finding a project that needs it. Scriptaculous is RoR's Ajax library and it uses a very similar approach to CForms, by sending HTML snippets for partial page updates rather than requiring large amounts of client-side application-specific logic. Actually, Ajax in Cocoon should be separated from CForms, and this is why the BrowserUpdateTransformer is in core and not in CForms. Now if we're to add more Ajax-related stuff in Cocoon, I'm not sure putting it in the core is a good thing, and a separate Ajax block may be better. I already have a desire to separate the BrowserUpdate and DOMUtils JavaScript Objects out of cforms.js, as I am using them outside the context of CForms. I can add (either to the wiki, or as a sample in a new AJAX Block) a JX Macro and JS file (TimedBrowserUpdate) that allow you to have regions of your page update in the background using BrowserUpdate on a periodic basis, if there are changes in the underlying data. We are using it to update the user on the status of asynchronous processes. regards Jeremy smime.p7s Description: S/MIME cryptographic signature
DO NOT REPLY [Bug 36279] New: - [Link] Plaudit Design
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36279. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36279 Summary: [Link] Plaudit Design Product: Cocoon 2 Version: 2.1.7 Platform: Other URL: http://www.plauditdesign.com OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Documentation AssignedTo: dev@cocoon.apache.org ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] URL of the website: http://www.plauditdesign.com Title of the website: Plaudit Design Cocoon version used: 2.1.7 Short summary: Minneapolis web site design company How can we verify this site is actually built with Cocoon? Site can also be viewed through its Cocoon-native address at http://lizard.plaudit.net:8080/cocoon/plauditdesign.com/ How much traffic does the site handle? Over 1,000 unique visitors monthly What made you choose Cocoon to build the site? Stable fast framework with flexibility of XML and all the functionality of Java. Made it easy to seperate content from design. Also it made it simple to pass most accessibility and validation tests. What other information do you want to disclose (e.g. how does it work, how did you build it, what parts of Cocoon did you use)? Sitemap determines different content that needs to be aggregated together and styles the pages accordingly using XSL extensively. Custom library was written for the content form. Can you provide a contact email address if people want further information? [EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36279] - [Link] Plaudit Design
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36279. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36279 --- Additional Comments From [EMAIL PROTECTED] 2005-08-19 20:15 --- Please use [EMAIL PROTECTED] instead of [EMAIL PROTECTED] Also, Custom library was written for the content form. should read Custom library was written for the contact form. (CONTACT, not CONTENT). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Cocoon stacktraces in trunk.
Il giorno 19/ago/05, alle 16:03, Sylvain Wallez ha scritto: Well, standard is the way to go as we can't assume everybody will want to deploy Xalan just to have error pages. Hmmm, I have a better idea, inspired once again by the Orbeon folks (don't whine, it was you who pointed to http://www.orbeon.com/blog/2005/08/16/ops-stack-traces/ first ;-) ). Why don't we modify the Exception generator so that, instead of outputting the Java stacktrace as a text, we do a getStackTrace on the exception, traverse the returned array of StackTraceElement's and for each one we output a ex:stackTraceElement having ex:className, ex:methoName, etc. as children? This would give us much more flexibility in presenting stacktraces, without having to convert newlines into brs and such silliness. Only problem, Throwable.getStackTrace was introduced in 1.4, AFAIK. So we could do this for trunk only, unless there's another method to get to the same info. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Slightly OT: Eclipse is acting up with SVN on OS X. Please help.
Guys, I use Eclipse for Mac OS X: Version: 3.1.0 Build id: I20050401-1645 with Subclipse 0.9.30. It works fine. I figured I might as well move to the official release of Eclipse 3.1 with the current Subclipse 0.9.32. However, when I now try to open the SVN repository perspective I get an error. I moved back to the previous version (i.e. the combination I started with), all is fine. Does anyone have a clue? Thanks. Bye, Helma
Re: wget Cocoon BRANCH 2.1.x?
On Friday 19 August 2005 19:22, Sylvain Wallez wrote: Emmanouil Batsis wrote: On Friday 19 August 2005 17:29, Jorg Heymans wrote: Emmanouil Batsis wrote: http://svn.apache.org/snapshots/cocoon/ does not work for me. try http://svn.apache.org/snapshots/cocoon-2.1/ That does not seem to work either :-( Why? These are plain tgz files... The page did not load at all in my browser, although it works fine now. Anyway, i dont think the tars there correspond to the 2.1.x branch i need to build lenya 1.4.a1, people there told me i need to checkout http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/ Manos
Re: Cocoon stacktraces in trunk.
Ugo Cei wrote: Il giorno 19/ago/05, alle 16:03, Sylvain Wallez ha scritto: Well, standard is the way to go as we can't assume everybody will want to deploy Xalan just to have error pages. Hmmm, I have a better idea, inspired once again by the Orbeon folks (don't whine, it was you who pointed to http://www.orbeon.com/blog/2005/08/16/ops-stack-traces/ first ;-) ). Why don't we modify the Exception generator so that, instead of outputting the Java stacktrace as a text, we do a getStackTrace on the exception, traverse the returned array of StackTraceElement's and for each one we output a ex:stackTraceElement having ex:className, ex:methoName, etc. as children? This would give us much more flexibility in presenting stacktraces, without having to convert newlines into brs and such silliness. For sure the ops stracktrace has more eye-candy at first look, but the experience shows that it often happens that Java stacktraces are copy/pasted to be send by mail or IM (happens to me at least once a day). I'm not sure a fancy html layout would survive this. And well, converting br isn't that hard. I just committed an updated version that no more uses exslt, so Saxon will be happy. Only problem, Throwable.getStackTrace was introduced in 1.4, AFAIK. So we could do this for trunk only, unless there's another method to get to the same info. Yup. That would mean either more code for JDK 1.3 compatibility or different DTDs in branch and trunk. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: More Ajax in Cocoon (was Re: [FYI] followers :-))
Jeremy Quinn wrote: On 19 Aug 2005, at 13:25, Sylvain Wallez wrote: snip/ Actually, Ajax in Cocoon should be separated from CForms, and this is why the BrowserUpdateTransformer is in core and not in CForms. Now if we're to add more Ajax-related stuff in Cocoon, I'm not sure putting it in the core is a good thing, and a separate Ajax block may be better. I already have a desire to separate the BrowserUpdate and DOMUtils JavaScript Objects out of cforms.js, as I am using them outside the context of CForms. I can add (either to the wiki, or as a sample in a new AJAX Block) a JX Macro and JS file (TimedBrowserUpdate) that allow you to have regions of your page update in the background using BrowserUpdate on a periodic basis, if there are changes in the underlying data. We are using it to update the user on the status of asynchronous processes. Yes, yes, please do :-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Slightly OT: Eclipse is acting up with SVN on OS X. Please help.
Hi Helma, I struck the same problem (solved it the same way), and mentioned it here: http://cocoon.zones.apache.org/daisy/cocooninaction/g3/22/g1/24.html I did read something about the cause being related to JNI. Sorry I can't help more! Mark On 19 Aug 2005, at 22:07, hepabolu wrote: Guys, I use Eclipse for Mac OS X: Version: 3.1.0 Build id: I20050401-1645 with Subclipse 0.9.30. It works fine. I figured I might as well move to the official release of Eclipse 3.1 with the current Subclipse 0.9.32. However, when I now try to open the SVN repository perspective I get an error. I moved back to the previous version (i.e. the combination I started with), all is fine. Does anyone have a clue? Thanks. Bye, Helma
Re: Slightly OT: Eclipse is acting up with SVN on OS X. Please help.
Il giorno 19/ago/05, alle 23:07, hepabolu ha scritto: However, when I now try to open the SVN repository perspective I get an error. I moved back to the previous version (i.e. the combination I started with), all is fine. What kind of error? With that combination I had problems whenever my project directory was a symlink. For instance, I normally place my Cocoon working directory under workspace/apache/cocoon/trunk or similar, but Eclipse insists on having the project right under workspace, so I figured I could dupe it with a symlink. This works well as long as you don't try to do an update or a commit with subclipse. If this is your case, try moving your project directory under workspace or whatever your Eclipse workspace directory is. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: wget Cocoon BRANCH 2.1.x?
Oliver Schalch wrote: It works well for me: # wget http://svn.apache.org/snapshots/cocoon-2.1/cocoon-2.1_20050819161251.tar.gz Thats a snapshot of the current development tree. You want that? It is a good link with bad content. ;-) The http://svn.apache.org/snapshots/cocoon-* links are broken, they are from the CVS not from the SVN. We already reported back and we are waiting for the fix of that. Note that most of the project that already migrated ot SVN have the same problem. Best Regards, Antonio Gallardo
