Re: [Vote] Jasha Joachimsthal as new Cocoon committer
- Andrew Savory [EMAIL PROTECTED] wrote: It's my pleasure to propose Jasha Joachimsthal as a new committer on the Apache Cocoon project. +1 Ugo -- Ugo Cei Sourcesense - Making sense of Open Source: http://www.sourcesense.com
Test, please ignore
Sorry for the noise, I'm having problems sending messages to Apache mailing lists. Ugo
Re: [vote] Jeroen Reijn as a new Cocoon committer
On Mar 5, 2007, at 9:19 AM, Andrew Savory wrote: I'd like to propose Jeroen Reijn as a Cocoon committer. +1 Ugo -- Ugo Cei Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Evil or Not?: http://evilornot.info/ Company: http://www.sourcesense.com/
Re: [vote] Felix Knecht as a new Cocoon committer
On Mar 5, 2007, at 8:38 PM, Reinhard Poetz wrote: I think that Felix shouldn't write patches any longer but commit them himself. I want to propose Felix as a committer. Felix has been part of this community for more than 6! years. Recently he has provided about 10 patches which prove that he has a good unerstanding of how Cocoon works. And, as I was told, he was the initial author of the LDAPTransformer. Please cast your votes! +1 Ugo
Re: [Vote] Ard Schrijvers as a new Cocoon committer
On Jul 28, 2006, at 7:44 AM, Reinhard Poetz wrote: Please cast your votes! +1 Ugo
Re: i18n
On Jun 13, 2006, at 1:25 PM, Bertrand Delacretaz wrote: On 6/13/06, sat2_waran [EMAIL PROTECTED] wrote: ...If we hardcode the key value like for instance, i18n:texthome/i18n:text then the translated value is getting printed, But if we give the key from xsl variable, i18n:textxsl:value-of select=$home//i18n:text it's not coming... Most probably means that $home is not what you assume - I'd check the output of this transform with the i18n transformer disabled, to see what's being fed into it. Or it might means that the XSLT transformation is done *after* the i18n transformation. Ugo
[jira] Closed: (COCOON-1812) Javaflow and Ajax when sending two forms one after eachother
[ http://issues.apache.org/jira/browse/COCOON-1812?page=all ] Ugo Cei closed COCOON-1812: --- Fix Version: 2.1.9-dev (current SVN) Resolution: Fixed Patch applied. Javaflow and Ajax when sending two forms one after eachother Key: COCOON-1812 URL: http://issues.apache.org/jira/browse/COCOON-1812 Project: Cocoon Type: Bug Components: Blocks: Forms, Blocks: Java Flow Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni Priority: Critical Fix For: 2.1.9-dev (current SVN) Attachments: javaflow-ajax.diff In javaflow, if I try to send an ajax form and then send another ajax form I obtain a NPE originating from JXMacroHelper. For example : FormInstance fi = new FormInstance(myform.def.xml); fi.show(mypipe); fi = new FormInstance(myotherform.def.xml); fi.show(myotherpipe); I receive an NPE originating from JXMacroHelper:162 while showing the second forms. After investigations i noticed that the second form was displayed following the ajax behaviour, while this second form is new and should not be ajaxed. This causes the updatedWidgets list to be null (both in form and in JXMacroHelper) and thus the NPE. Sniffing the http traffic showed me that while in javascript the submission of the first form causes a bu:continue/ and a new non-ajax request from the browser, while with javaflow this does not happen. Seems like the lines from 176 to 201 of /cocoon-2.1.X/src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript/Form.js were not ported to the javaflow FormInstance. -- 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: [vote] Simone Gianni as a new Cocoon committer
Il giorno 24/mar/06, alle ore 11:19, Sylvain Wallez ha scritto: It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. +1 Ugo -- Ugo Cei Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Evil or Not?: http://evilornot.info/ Company: http://www.sourcesense.com/
Re: [Vote] Release plan for 2.1.9
Il giorno 21/mar/06, alle ore 09:20, Carsten Ziegeler ha scritto: So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) Please cast your votes +1 Ugo -- Ugo Cei Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Evil or Not?: http://evilornot.info/ Company: http://www.sourcesense.com/
Re: [RT] a simple release plan
Il giorno 15/mar/06, alle ore 17:00, Carsten Ziegeler ha scritto: Ok, here is a simple plan to continue. snip/ WDYT? I like it. I share Upayavira's and others' frustration at not understanding (our fault entirely) what is going on in trunk and being able to help. Ugo -- Ugo Cei Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Evil or Not?: http://evilornot.info/ Company: http://www.sourcesense.com/
[jira] Assigned: (COCOON-1793) [PATCH] Enum selection list with apache enum support and null-text
[ http://issues.apache.org/jira/browse/COCOON-1793?page=all ] Ugo Cei reassigned COCOON-1793: --- Assign To: Ugo Cei [PATCH] Enum selection list with apache enum support and null-text -- Key: COCOON-1793 URL: http://issues.apache.org/jira/browse/COCOON-1793 Project: Cocoon Type: Improvement Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni Assignee: Ugo Cei Attachments: enumselectionlist-samples.diff, enumselectionlist.diff Added support for apache enum in the EnumSelectionList. This will grant selection list items order on those JREs (expecially IBM, used by WebSphere) that will honor litteraly the Class.getDeclaredFields() javadocs and return elements in random order. This also adds the ability to implement the getEnumList method in the enum classes and implement a custom order. In case it isn't possible to retrieve a valid iterator for the apache enum, then the common way will be used. Since i felt the lack of it, i also added a null-text=i18nkey so that it's now possible to specify a label for the null element when the selection list is nullable=true. The second patch updates the samples adding a PreferredContact apache enum to the Contact bean, the form2 files (both for bean and xml binding) and messages, to demostrate the usage of both apache enum and the new null-text. -- 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-1793) [PATCH] Enum selection list with apache enum support and null-text
[ http://issues.apache.org/jira/browse/COCOON-1793?page=comments#action_12369188 ] Ugo Cei commented on COCOON-1793: - Looks like you forgot to add the PreferredContact class to your patch (forgot to svn add, maybe?). [PATCH] Enum selection list with apache enum support and null-text -- Key: COCOON-1793 URL: http://issues.apache.org/jira/browse/COCOON-1793 Project: Cocoon Type: Improvement Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni Attachments: enumselectionlist-samples.diff, enumselectionlist.diff Added support for apache enum in the EnumSelectionList. This will grant selection list items order on those JREs (expecially IBM, used by WebSphere) that will honor litteraly the Class.getDeclaredFields() javadocs and return elements in random order. This also adds the ability to implement the getEnumList method in the enum classes and implement a custom order. In case it isn't possible to retrieve a valid iterator for the apache enum, then the common way will be used. Since i felt the lack of it, i also added a null-text=i18nkey so that it's now possible to specify a label for the null element when the selection list is nullable=true. The second patch updates the samples adding a PreferredContact apache enum to the Contact bean, the form2 files (both for bean and xml binding) and messages, to demostrate the usage of both apache enum and the new null-text. -- 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] Closed: (COCOON-1793) [PATCH] Enum selection list with apache enum support and null-text
[ http://issues.apache.org/jira/browse/COCOON-1793?page=all ] Ugo Cei closed COCOON-1793: --- Fix Version: 2.1.9-dev (current SVN) Resolution: Fixed Applied. Please cross-check. [PATCH] Enum selection list with apache enum support and null-text -- Key: COCOON-1793 URL: http://issues.apache.org/jira/browse/COCOON-1793 Project: Cocoon Type: Improvement Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni Assignee: Ugo Cei Fix For: 2.1.9-dev (current SVN) Attachments: enumselectionlist-samples.diff, enumselectionlist-samples2.diff, enumselectionlist.diff Added support for apache enum in the EnumSelectionList. This will grant selection list items order on those JREs (expecially IBM, used by WebSphere) that will honor litteraly the Class.getDeclaredFields() javadocs and return elements in random order. This also adds the ability to implement the getEnumList method in the enum classes and implement a custom order. In case it isn't possible to retrieve a valid iterator for the apache enum, then the common way will be used. Since i felt the lack of it, i also added a null-text=i18nkey so that it's now possible to specify a label for the null element when the selection list is nullable=true. The second patch updates the samples adding a PreferredContact apache enum to the Contact bean, the form2 files (both for bean and xml binding) and messages, to demostrate the usage of both apache enum and the new null-text. -- 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-1790) VerifyException Attempt to split long or double on the stack in javaflow
[ http://issues.apache.org/jira/browse/COCOON-1790?page=comments#action_12369000 ] Ugo Cei commented on COCOON-1790: - Did you try it with Sun's JDK as well? VerifyException Attempt to split long or double on the stack in javaflow -- Key: COCOON-1790 URL: http://issues.apache.org/jira/browse/COCOON-1790 Project: Cocoon Type: Bug Components: Blocks: Java Flow Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni When writing code like this : long time = System.currentTimeMillis(); Date date = new Date(time); the given exception is thrown. It's a validation exception. This happens when a long (maybe also a double?) is used in a constructor (not in a function call). The following code is a workaround : Date date = new Date(); date.setTime(time); but can be used only when the object we are instantiating have a getter as an alternative to the constructor parameter. I'm having this problem with a fresh (yesterday) checkout of cocoon 2.1.X branch. Don't know yet if this apply to other versions of cocoon. I'm using Blackdown-1.4.2-02 on a 2.6.12-gentoo-r6 linux machine. Googling around it seems that this exception is raised when the data type in a pop2 JVM instruction is not correct. I think this is one of the side-effects of the javaflow BCEL manipulations, but I'm not skilled enought on BCEL and similar stuff to even think of a possible solution. The exception is raised loading the javaflow class, so it will prevent the entire flow (and not only the affected method) to be used. Also, the exception will just tell you that the class is invalid, and not point you to the place in code where this long is used in a constructor, so you'll have to spot it by hand. I can produce a test case to try to narrow it down, but the given 3 lines of code are enought to produce the error in my javaflows. -- 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: Forms enum selection list order
Il giorno 02/mar/06, alle ore 00:35, Simone Gianni ha scritto: I developed an ApacheEnumSelectionList class and I'm ready to contribute it, but i think it would be nicer to merge this code in the actual EnumSelectionList, so that if the given enum is an apache enum, the getList method is used instead of the getDeclaredFields method. Jakarta Commons enum are already in commons-lang, right? If so, it's a dependency we already have, so why not? Ugo -- Ugo Cei Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Evil or Not?: http://evilornot.info/ Company: http://www.sourcesense.com/
[jira] Updated: (COCOON-1726) Implementation of Source that supports conditional GETs
[ http://issues.apache.org/jira/browse/COCOON-1726?page=all ] Ugo Cei updated COCOON-1726: Attachment: (was: patch.txt) Implementation of Source that supports conditional GETs --- Key: COCOON-1726 URL: http://issues.apache.org/jira/browse/COCOON-1726 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.1.9-dev (current SVN) Reporter: Ugo Cei Provides an implementation of Source that exploits Cocoon's cache to implement conditional GETs. for HTTP resources, i.e. data will be served from the cache if the originating server returns a 304 Not modified response. -- 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: Supporting conditional GET in Cocoon
Il giorno 03/feb/06, alle ore 00:32, David Crossley ha scritto: I got it a few days ago. Perhaps you re-attached the same patch. Took a while for me to find the time to do something about this, but I have a new version of the patch attached to the issue. You might want to test it. Ugo -- Ugo Cei Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Evil or Not?: http://evilornot.info/ Company: http://www.sourcesense.com/
[jira] Updated: (COCOON-1726) Implementation of Source that supports conditional GETs
[ http://issues.apache.org/jira/browse/COCOON-1726?page=all ] Ugo Cei updated COCOON-1726: Attachment: patch2.txt Modified previous version following David's observations. Implementation of Source that supports conditional GETs --- Key: COCOON-1726 URL: http://issues.apache.org/jira/browse/COCOON-1726 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.1.9-dev (current SVN) Reporter: Ugo Cei Attachments: patch2.txt Provides an implementation of Source that exploits Cocoon's cache to implement conditional GETs. for HTTP resources, i.e. data will be served from the cache if the originating server returns a 304 Not modified response. -- 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: [VOTE] Release 2.1.9
Il giorno 20/feb/06, alle ore 22:11, Ralph Goers ha scritto: The forms block is now marked stable. I believe legal has given the OK for us to use the JCR api. To the best of my recollection I believe those were the only two items standing in the way of a 2.1.9 release. So please vote. +1 Ugo -- Ugo Cei Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Evil or Not?: http://evilornot.info/ Company: http://www.sourcesense.com/
Re: [RT] Using Spring instead of ECM++
Il giorno 07/feb/06, alle ore 20:41, Carsten Ziegeler ha scritto: What about replacing ECM++ with Spring? I don't think I have to tell you how much I would love that. However, I'm a bit confused, but it's really my fault, as I haven't been following at all the recent realblocks/osgi/2.2 talk and developments. Is this for 2.1, 2.2, 3.0? How does it relate to OSGi and Real Blocks (TM)? Ugo -- Ugo Cei Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Evil or Not?: http://evilornot.info/ Company: http://www.sourcesense.com/
Re: Java objects in JX templates
Il giorno 27/gen/06, alle ore 21:10, Leszek Gawron ha scritto:
One more thing: this construct
${java.util.StringTokenizer(items, delims)}
will work only when .jx is invoked from flow. This is due to the
fact that neither JEXL nor JXPath is able to reference packages/
create java objects. The functionality in fact is provided by Rhino
library.
According to my tests, it doesn't work in 2.1.8, regardless of
whether I use flow or not and whether I prepend Packages. or not.
Can anyone else confirm this?
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Java objects in JX templates
Our docs [1] state that something like:
jx:forEach var=${var}
items=${java.util.StringTokenizer(items, delims)}
/jx:forEach
should work. However, that doesn't seem to be the case, at least in
2.1.8 while it apparently worked before. I did a few more tests and
discovered that even simple cases like ${java.util.Date()} produce no
output and no error message. This even if I put Packages. in front
of the package name. Is this a bug or what?
Ugo
[1] http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html
--
Ugo Cei
Tech Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Re: Java objects in JX templates
Il giorno 27/gen/06, alle ore 15:54, Leszek Gawron ha scritto:
Ugo Cei wrote:
Our docs [1] state that something like:
jx:forEach var=${var}
items=${java.util.StringTokenizer(items, delims)}
/jx:forEach
should work. However, that doesn't seem to be the case, at least
in 2.1.8 while it apparently worked before. I did a few more
tests and discovered that even simple cases like ${java.util.Date
()} produce no output and no error message. This even if I put
Packages. in front of the package name. Is this a bug or what?
Ugo
[1] http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html
Didn't you want to do:
jx:forEach var=varName
items=${java.util.StringTokenizer(items, delims)}
/jx:forEach
The code I copied above is straight from our docs, but it doesn't
make an inch of a difference whether I change to what you suggest or
not. The problem is that invoking Java class constructors or calling
static methods does not work.
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Re: Release 2.1.9
Il giorno 13/gen/06, alle ore 00:24, Ralph Goers ha scritto: I would like to propose a 2.1.9 release. It has been about 2 months since 2.1.8. We are needing to upgrade and I would really need to pick up the mapping file changes I made to the portal (this is quite a serious bug) and it would be very nice to have a version with CForms marked stable. +1 Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/
Re: [vote] moving the template block in 2.1
Il giorno 13/gen/06, alle ore 11:17, Sylvain Wallez ha scritto: [X ] move template block to 2.1 and keep the old implementation For 2.1.9, I say keep the old one and release 2.1.9 ASAP. If everything is OK, we can ditch the old one in 2.1.10. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/
Re: Supporting conditional GET in Cocoon
Il giorno 29/dic/05, alle ore 23:45, Sylvain Wallez ha scritto: Ears aren't deaf, but on vacation :-) Going to be deaf in a couple of days due to firecrackers anyway ;) I don't understand why you need a ThreadLocal. Isn't a class member good enough? How would a class member work with multiple threads? Also, this implementation, although useful, works only if the calling environment is validity aware, i.e. keeps the validity of the previous usage of that same URL for comparison. Pardon my ignorance, but what environments are not validity aware? Can you describe a scenario where this implementation would not be useful? I was under the impression that the whole SourceValidity concept was just for these kind of uses. Ah, and a bug I just saw while re-reading the code: a SourceValidity *must* be serializable to be stored in the persistent store. The HttpSourceValidity references a HttpSource which itself is LogEnabled (not serializable) and has a HttpClient. Could be fixed, probably. Having the HttpSource in the validity object is just for convenience. We could get away with just the URL and some refactoring. Still, I'm wondering: didn't anyone ever try to develop a nice web services (particularly of the REST kind) client using Cocoon without rewriting large parts of it? I mean, we don't have conditional GETs, and that's bad enough. But try to fetch a 404 page and catch the error using: map:handle-errors map:select type=exception map:when test=not-found This works for file: URLs but fails for http: URLs, which was totally unexpected to me and the cause of much frustration. Other issues that I'm going to dive into are redirects and cache control. I'm afraid that if we want to make Cocoon into a well- behaved participant in a Web 2.0 world, we have lots of work to do. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
[jira] Updated: (COCOON-1726) Implementation of Source that supports conditional GETs
[ http://issues.apache.org/jira/browse/COCOON-1726?page=all ] Ugo Cei updated COCOON-1726: Attachment: patch.txt Handling of 404s. Don't crash with a NPE if some headers missing. Implementation of Source that supports conditional GETs --- Key: COCOON-1726 URL: http://issues.apache.org/jira/browse/COCOON-1726 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.1.9-dev (current SVN) Reporter: Ugo Cei Attachments: patch.txt, patch.txt Provides an implementation of Source that exploits Cocoon's cache to implement conditional GETs. for HTTP resources, i.e. data will be served from the cache if the originating server returns a 304 Not modified response. -- 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] Updated: (COCOON-1726) Implementation of Source that supports conditional GETs
[ http://issues.apache.org/jira/browse/COCOON-1726?page=all ] Ugo Cei updated COCOON-1726: Attachment: (was: patch.txt) Implementation of Source that supports conditional GETs --- Key: COCOON-1726 URL: http://issues.apache.org/jira/browse/COCOON-1726 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.1.9-dev (current SVN) Reporter: Ugo Cei Attachments: patch.txt Provides an implementation of Source that exploits Cocoon's cache to implement conditional GETs. for HTTP resources, i.e. data will be served from the cache if the originating server returns a 304 Not modified response. -- 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: Supporting conditional GET in Cocoon
Il giorno 30/dic/05, alle ore 16:09, Sylvain Wallez ha scritto: I don't understand why you need a ThreadLocal. Isn't a class member good enough? How would a class member work with multiple threads? I see. This is because the HttpSource is referenced by the HttpSourceValidity, right? Now the serialization problem shows that it may not the right approach. Hmm what about using an common class used both by the source and validity classes to hold the common information? I was assuming that by class member you meant a static class variable. That's where my doubts about multithreading arose. This works for file: URLs but fails for http: URLs, which was totally unexpected to me and the cause of much frustration. Weird. Don't we get an exception of some kind on 404? For a file: source we get a ResourceNotFoundException, but for an http: source we get a ProcessingException that wraps an IOException. Indeed. My impression is that this work is concentrated it two main locations: the http source for incoming streams, and the pipeline engine for outgoing streams where we must better handle etags and last-modified headers. Right. I'm going on vacation in a few minutes, and I don't think I'll be able to contribute much to this discussion or code in the next days, but I'll catch up when I'm back if this thread goes on. Happy New Year Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
[jira] Created: (COCOON-1726) Implementation of Source that supports conditional GETs
Implementation of Source that supports conditional GETs --- Key: COCOON-1726 URL: http://issues.apache.org/jira/browse/COCOON-1726 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.1.9-dev (current SVN) Reporter: Ugo Cei Attachments: patch.txt Provides an implementation of Source that exploits Cocoon's cache to implement conditional GETs. for HTTP resources, i.e. data will be served from the cache if the originating server returns a 304 Not modified response. -- 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
Supporting conditional GET in Cocoon
Given the time of year, I'm afraid this message will fall on deaf ears, but anyway ... I was recently startled to discover that there's apparently no easy way to perform a proper conditional GET [1] using Cocoon's sources. I wonder: didn't anybody ever try to implement an RSS aggregator or other kind of HTTP client that frequently requests seldom changing Web resources? And if someone did, didn't he care about blindly fetching the whole resource every time, even if not necessary? Anyway, I just needed this and tried to see what could be done. And of course, I wanted to exploit Cocoon's caching mechanism to store the contents of already fetched resources. This turned out to be harder than expected, due in part to the way checking the validity of sources works, but mostly to my own ignorance of the subject. First of all, I though that the best place to implement this behavior was in a Source object. This seems to me to be the correct choice, but it has one potentially negative side-effect. More on this later. I also decided to exploit the SourceValidity interface. After all, it's there for this very purpose. Unfortunately, this is where things turned out to be not so simple. To understand why, here is a description of how my first attempt worked: 1. A generator requests an HTTP resource. 2. A suitable factory provides a new instance of class HttpSource. 3. The new Source's getInputStream method is called: this uses Jakarta Commons HttpClient to fetch the requested URL. 4. The new Source's getValidity method is called: this returns a new HttpSourceValidity object containing the values from the Last- modified and Etag response headers, if present. 5. The same HTTP resource is requested again. 6. The SourceValidity object associated with the previous request is recovered and it's isValid method is called. 7. The HttpSourceValidity implementation of the method uses the stored Last-modified and Etag values to perform a proper conditional GET. Here, two things might happen: 8a. A 304 Not Modified status is returned. isValid returns VALID and Cocoon uses the cached version. Everybody is happy. 8b. A 200 OK status is returned, as the original resource has perhaps been modified. isValid returns INVALID and Cocoon calls the Source's getInputStream method anew. Everybody is NOT happy, because the original resource has been fetched twice: once by the SourceValidity and once by the Source itself. You see, the problem is that there's no easy way for the SourceValidity to tell Cocoon that it should reuse what has just been retrieved. I could have used a HEAD request in the SourceValidity. This would have saved some bandwidth but still the server would have had to compute the response twice, if not particularly smart. And still, doing two HTTP requests when one suffices does not seem quite optimal. So I thought really hard about the problem and came up with a (hopefully) brilliant solution: Use a ThreadLocal. The HttpSourceValidity will store in a ThreadLocal the response data (actually an instance of HttpClient's GetMethod class) and the HttpSource will use it later, in the same request and hence in the same thread, to provide an InputStream for reading. I've provided a patch for this (see http://issues.apache.org/jira/ browse/COCOON-1726) against the 2.1 branch. Please have a look at it (particularly the FIXME comments) as I would like some expert advice on the implementation before finalizing it. One problem that might arise is due to the fact that with the cocoon.xconf settings included in the patch, all http URIs will be served by this Source, overriding the default handling by Excalibur's URLSource. This could change the behavior of existing applications, but it would strike me as strange having to use some other pseudo- protocol (cached-http ?). Ugo [1] http://fishbowl.pastiche.org/2002/10/21/ http_conditional_get_for_rss_hackers -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
Please cast your votes! +1 Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: svn commit: r357004 - in /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/datatype/convertor: FormattingDateConvertor.java FormattingDateConvertorBuilder.java Icu4jDateConvertor.java Icu4jD
Il giorno 19/dic/05, alle ore 13:43, Sylvain Wallez ha scritto: Do we really need yet another configuration option? I didn't knew about this date format's leniency, and IMO the date convertor shouldn't be lenient since 12-32-2005 is obviously an invalid input. So what about simply always set lenient to false? The problem is that the default leniency for DateFormat is true, so setting it to false would break backward compatibility (even if it's admittedly improbable that someone would have relied on this behavior). With my fix, we have one more option, but omitting it gives exactly the same behavior as before. All in all, I don't have a strong opinion on this, so we might do a quick informal vote and let people decide. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: svn commit: r357004 - in /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/datatype/convertor: FormattingDateConvertor.java FormattingDateConvertorBuilder.java Icu4jDateConvertor.java Icu4jD
Il giorno 15/dic/05, alle ore 12:24, [EMAIL PROTECTED] ha scritto: Author: ugo Date: Thu Dec 15 03:23:56 2005 New Revision: 357004 URL: http://svn.apache.org/viewcvs?rev=357004view=rev Log: [Forms] Added lenient attribute to date convertors. What this change does is adding a new lenient attribute to the CForms date convertors (formatting AND icu4j). By default, lenient is true and what this means is that a date like 12-32-2005 (Dec. 32nd) is silently converted to 01-01-2006 due to the way Java's DateFormat class works. But if you set lenient=false, a date like that will be rejected and will not pass validation. Now, I'd like to document this, but cocoon.zones.apache.org is down :( Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: svn commit: r357004 - in /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/datatype/convertor: FormattingDateConvertor.java FormattingDateConvertorBuilder.java Icu4jDateConvertor.java Icu4jD
Il giorno 15/dic/05, alle ore 13:53, Bertrand Delacretaz ha scritto: Le 15 déc. 05, à 12:39, Ugo Cei a écrit : Now, I'd like to document this, but cocoon.zones.apache.org is down :( It's back, I have restarted the services. Great. I have registered, but now I think someone has to give me the necessary karma for editing, right? My username is ugo. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [RT] Ditching the environment abstraction
Il giorno 11/dic/05, alle ore 18:56, Daniel Fagerstrom ha scritto: snip/ WDYT? /Daniel Know what? I proposed the same some time ago (I've tried digging out the reference, but couldn't), so a big +1 from me. Ugo
Re: [Vision] Knowing When We are Done
Il giorno 07/dic/05, alle ore 09:40, Torsten Curdt ha scritto: Plus I envision to have good testcase coverage for the whole system. I envision to have a clean core that shines through simplicity. I envision a non-viral component handling (One word: AbstractLogEnabled). POJOs and factories where feasible. I envision being A-ha! This is a longtime favorite of mine. AbstractLogEnabled must DIE, DIE, DIE! ;-) Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [Vision] Knowing When We are Done
Il giorno 07/dic/05, alle ore 10:13, Sylvain Wallez ha scritto: I was expecting you to also add I envision a Cocoon where all exceptions would be unckecked :-) Ça va sans dire. Oh, by the way, how do you expect to be able to distribute Cocoon in France now that they are going to outlaw Open Source software? ;-) Ugo
Re: [Vision] Knowing When We are Done
Il giorno 07/dic/05, alle ore 11:43, Ross Gardler ha scritto: Most businesses are made up of common business processes. The odd one will be unique to that business, but most are common. In the case of the unique practices the software needs to be customised, but in the case of common practices an off-the-shelf solution is sufficient. Sorry but I don't believe this dream of high-level, off-the-shelf, customizable components will ever come to fruition, Cocoon or not. On this point, I agree with Dan Creswell [1]: All attempts at creating high-level business components that can be re-used and re-configured have failed previously. This failure has not been for technical reasons - it happens because the requirements that yielded the original component interface were sufficiently different from the new requirements so as to require re-writing massive chunks of functionality. And David Heinemeier Hansson as well [2]: On the surface, the dream of components sounds great and cursory overviews of new projects also appear to be a perfect fit. But they never are. Reuse is hard. Parameterized reuse is even harder. And in the end, you're left with all the complexity of a swiss army knife that does everything for no one at great cost and pain. I'd be content if Cocoon was simply a powerful and easy-to-use web application development framework. Ugo [1]: http://jroller.com/page/dancres/20050218#soa_doomed [2]: http://www.loudthinking.com/arc/000407.html -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Il giorno 07/dic/05, alle ore 15:23, Berin Loritsch ha scritto: What's your preference for the vision? [ ] All web apps written in JavaScript [X ] All web apps written in pure Java [ ] Mix and match (not as simple, but is status quo with today) Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: An entirely new beast
Il giorno 07/dic/05, alle ore 15:28, Vadim Gritsenko ha scritto: Cocoon NG is nice, even too nice. Cocoon NT or Cocoon XP are much better. No chance that it could be released without renaming. Hmmm ... maybe Cocoon 360? ;-) Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [RT] The next shiny thing?
Il giorno 06/dic/05, alle ore 01:24, David Crossley ha scritto: I started to draft here what the next-generation Cocoon should be. I dubbed it Racoon (with Andrew's permission) as I really think that from a marketing point of view, a new name should be used so that people don't see it as a publication engine, as too many people still see Cocoon. Please don't. Cocoon is the name. I agree that we must keep the Cocoon name, but even if we decide to change it in the end, please not Racoon. From a marketing standpoint, it will always be interpreted as meaning almost like Rails, but not the real thing. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [RT] The next shiny thing?
Il giorno 06/dic/05, alle ore 10:01, Sylvain Wallez ha scritto: Il like this friendly animal and the rhyme with Cocoon. Now there's also Baboon :-) Have a look at http://www.rhymezone.com/r/rhyme.cgi? Word=cocoontypeofrhyme=perfectorg1=sylorg2=l I also see Too soon on that list, which might be descriptive of the feelings of some people on this list ;). Sorry, couldn't resist. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [RT][long] Cocoon 3.0: the necessary mutation
Sylvain, I'm glad to see that, more than one year after my Butterfly Manifesto [1], people are finally coming to the realization that we need a revolutionary change in Cocoon, a change that is targeted towards a radical simplification. Better late than never :-). In order to proceed from here, I think we need to decide what we want Cocoon to be. At present, I see Cocoon as wanting to be at least three different things, all together: 1) A web publishing framework. 2) A web application framework 3) An XML-based sort of engine or hub for producing and consuming web services. Personally, I'm not that much interested in either 1 or 3 above, even though my next project assignment will probably involve building a publishing system for producing a printed book and people are trying to push me towards using Cocoon for doing 3. But I think 1 isn't particularly fun and can be tackled using Cocoon 2.1, and there are probably better solutions for 3 already. Which leaves us with 2, which isn't all that bad if what you want is build the next great Web 2.0 service, earn a decent income selling subscriptions or ad space, and later make a boatload of money by selling to Google, Yahoo or Microsoft ;). Or even if you want to provide applications for your customers or for your internal IT department, which is probably what most of us do day in, day out. To reach this elusive goal, we need a platform that makes it easy to support Ajax and to provide and consume RESTful web services. We need it to be agile, as in needing the shortest roundtrip time between doing an edit and seeing its efffect in a browser window. We need to support a simple persistance mechanism on top of SQL, like ActiveRecord (jDBI looks great for this, but we must leave the door open for people wanting to use Hibernate or JDO or whatever). I agree we need a simple API for the sitemap that makes pipelines composable and content-aware. With such an API, it will be easy to provide either a declarative sitemap configuration file or a programmatic one, using any scripting language that runs on the JVM. I'd also like the controller to be able to adopt the Ajax paradigm (actually the Asynchronous XML over HTTP part of it). By this I mean that it should be possible to use something similar to the XMLHttpRequest object to invoke an external service, process the response using DOM or StAX and, once all pending requests have been satisfied, serve the response to the client. Great for doing mashups. I know it's premature to talk about implementation issues, but since Carsten brought up the issue first, y'all know I have a fondness for Spring, so you know where my heart lies. To Daniel and the others working on Cocoon 2.2: You have a tough job ahead and it's going to get even tougher now that everyone is jumping up and down around this new shiny thing. I'm afraid you're not going to get much help from others, but what you're doing is incredibly valuable for all those companies that have an interest in supporting existing Cocoon 2 solutions, which will be around for a long time. I think what these companies should do is to directly and financially support this effort. It's not going to be fun (for most people, I mean) and it's not going to be rewarded by immense popularity and recognition, so I think it has to be paid for. Just my 0.02€, Ugo [1]: http://wiki.apache.org/cocoon/ButterflyManifesto -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Javaflow requires X11 libraries
Just found out: java.lang.UnsatisfiedLinkError: /usr/local/j2sdk1.4.2_08/jre/lib/i386/ libawt.so: libXp.so.6: cannot open shared object file: No such file or directory at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1503) at java.lang.Runtime.loadLibrary0(Runtime.java:788) at java.lang.System.loadLibrary(System.java:834) at sun.security.action.LoadLibraryAction.run (LoadLibraryAction.java:50) at java.security.AccessController.doPrivileged(Native Method) at java.awt.Toolkit.loadLibraries(Toolkit.java:1437) at java.awt.Toolkit.clinit(Toolkit.java:1458) at java.awt.Color.clinit(Color.java:250) at org.apache.bcel.verifier.structurals.Subroutines.init (Subroutines.java:442) at org.apache.bcel.verifier.structurals.ControlFlowGraph.init (ControlFlowGraph.java:440) at org.apache.cocoon.components.flow.java.ContinuationClassLoader.transform (ContinuationClassLoader.java:145) at org.apache.cocoon.components.flow.java.ContinuationClassLoader.loadClass (ContinuationClassLoader.java:114) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.cocoon.components.flow.java.JavaInterpreter.initialize (JavaInterpreter.java:93) at org.apache.cocoon.components.flow.java.JavaInterpreter.callFunction (JavaInterpreter.java:123) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invo ke(CallFunctionNode.java:138) ... Javaflow (or is it BCEL?) depends on AWT and therefore requires that X11 libs be present on a *nix system in order to run. And no, using - Djava.awt.headless=true is not enough. I had to do apt-get install xlibs to bypass this problem. Is this actually as braindamaged as it appears? Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: Javaflow requires X11 libraries
Il giorno 28/nov/05, alle ore 16:59, Torsten Curdt ha scritto: Thanks for the heads up ...do you mind filing a bug over at jakarta? Done. See bug #37666 on Bugzilla. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: Javaflow requires X11 libraries
Il giorno 28/nov/05, alle ore 19:48, Torsten Curdt ha scritto: Thanks for the heads up ...do you mind filing a bug over at jakarta? Done. See bug #37666 on Bugzilla. Thanks! Looks like it's been fixed in SVN: http://issues.apache.org/bugzilla/ show_bug.cgi?id=37666 Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: Ajax libraries: let's wait a bit
Il giorno 08/nov/05, alle ore 11:06, Sylvain Wallez ha scritto: The framework that currently satisfies these constraints is the Dojo toolkit. It is packed with impressive features, is developped by a community that functions very much like Apache and has an Apache-compatible licence. Have you seen the new Dojo rich text editing widget [1]? Looks simpler (for most forms you don't need lots of fancy editing features) and more robust than HTMLArea. And it works in Safari too. Ugo [1]: http://dojotoolkit.org/docs/rich_text.html -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [Vote] Releasing 2.1.8 tomorrow
Il giorno 08/nov/05, alle ore 11:54, Carsten Ziegeler ha scritto: Please cast your votes for releasing 2.1.8 tomorrow, 8th of November. +1 Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Global variables in flowscript
I am feeling a little confused. What is the expected behavior of te
following flowscript code:
var x = 0;
function fun() { print(++x); }
when it is invoked multiple times by the same user?
I am always getting 1 (with 2.1.8-rc1) as if the value of the
global variable wasn't retained between invocations. I expected to
get an incrementing sequence of values.
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Re: Global variables in flowscript
Il giorno 08/nov/05, alle ore 14:16, Sylvain Wallez ha scritto: Don't you have some session-related problems that could be caused by a proxy server in front of the servlet engine? No. Plain Jetty bundled with Cocoon. But I have resolved the problem. It was caused by having a cocoon.sendPage call at the end of my flowscript that wasn't matched by any pipeline, due to a typo. Apparently, this triggers an error response that doesn't have a cookie in the header. Weird. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
[jira] Closed: (COCOON-1192) calendar (generator) is malfunctioning
[ http://issues.apache.org/jira/browse/COCOON-1192?page=all ] Ugo Cei closed COCOON-1192: --- Resolution: Fixed calendar (generator) is malfunctioning -- Key: COCOON-1192 URL: http://issues.apache.org/jira/browse/COCOON-1192 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.5 Environment: Operating System: Windows XP Platform: PC Reporter: Ian F. Hood Assignee: Ugo Cei Attachments: calendar2html.xslt a quick peek at /samples/cal will make it clear: the top left day 'num' is right, but the full (date) is off by one day. -- 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: [VOTE] Naming rule for HTML IDs generated by CForms
Il giorno 07/nov/05, alle ore 08:36, Sylvain Wallez ha scritto: So I kindly ask people to carefully read and understand the rationale and motivation behind ':'. Alright, you convinced me. I hereby revert my previous vote and vote +1 on using the colon. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [VOTE] Naming rule for HTML IDs generated by CForms
Il giorno 06/nov/05, alle ore 11:51, Sylvain Wallez ha scritto: [ ] foo.bar:input (colon, not CSS-friendly because of IE) [ ] foo.bar..input (double period) [ ] foo.bar.input. (trailing period) [ X] foo.bar._input (underscore, requires to forbid it as the beginning of widget names) Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: Other ID naming proposals (was Re: CForms widget ID naming)
Il giorno 05/nov/05, alle ore 08:46, Sylvain Wallez ha scritto: So let's make other proposals. Let's consider wiget foo.bar (e.g. a fd:field in a fd:group) and the ID of its input. - foo.bar..input: the '.' is doubled, which can never conflict with a widget's full name - foo.bar._input: generated element's name starts with a character that we can forbid as the first character of widget names I prefer the first one (double '.') which is IMO more readable than the second. Another one, which looks more natural: foo.bar.input.: the trailing '.' ensures it cannot conflict with a widget's full name The fact that it is not that readable might be a plus. The problem with double dots or a dot at the end is that it's easy to miss when reading the code. an extra '_' sticks out more and won't be missed as easily. Ugo
Re: a new cocoon logo?
Il giorno 02/nov/05, alle ore 23:06, Stefano Mazzocchi ha scritto: +1 to new skin but only with new content. Agree. -1 to the logo, no reason to change a widely recognized one with a new one just for sake of change. Agree as well. Let's keep the current logo, at least until we release Cocoon 3. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [Vote] Releasing on friday
Il giorno 03/nov/05, alle ore 06:47, Carsten Ziegeler ha scritto: Please cast your votes for releasing 2.1.8 on friday, 4th of November. -0.5. Too many CForms last minute changes, as you wrote in response to Sylvain. Incidentally, I'm +1 on Sylvain's proposed changes to element id generation strategy. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
[jira] Commented: (COCOON-1192) calendar (generator) is malfunctioning
[ http://issues.apache.org/jira/browse/COCOON-1192?page=comments#action_12356315 ] Ugo Cei commented on COCOON-1192: - Eric, you are in the same time zone (CET) as me, I think. I suspect only users in a TZ west of Greenwich are affected by this bug. As soon as I can find a couple of hours to dedicate to this, I plan to verify the bug and test my putative fix. I will look at your stylesheet as well. calendar (generator) is malfunctioning -- Key: COCOON-1192 URL: http://issues.apache.org/jira/browse/COCOON-1192 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.5 Environment: Operating System: Windows XP Platform: PC Reporter: Ian F. Hood Assignee: Ugo Cei Attachments: calendar2html.xslt a quick peek at /samples/cal will make it clear: the top left day 'num' is right, but the full (date) is off by one day. -- 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] Reopened: (COCOON-1192) calendar (generator) is malfunctioning
[ http://issues.apache.org/jira/browse/COCOON-1192?page=all ] Ugo Cei reopened COCOON-1192: - calendar (generator) is malfunctioning -- Key: COCOON-1192 URL: http://issues.apache.org/jira/browse/COCOON-1192 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.5 Environment: Operating System: Windows XP Platform: PC Reporter: Ian F. Hood Assignee: Cocoon Developers Team a quick peek at /samples/cal will make it clear: the top left day 'num' is right, but the full (date) is off by one day. -- 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-1192) calendar (generator) is malfunctioning
[ http://issues.apache.org/jira/browse/COCOON-1192?page=all ] Ugo Cei reassigned COCOON-1192: --- Assign To: Ugo Cei (was: Cocoon Developers Team) calendar (generator) is malfunctioning -- Key: COCOON-1192 URL: http://issues.apache.org/jira/browse/COCOON-1192 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.5 Environment: Operating System: Windows XP Platform: PC Reporter: Ian F. Hood Assignee: Ugo Cei a quick peek at /samples/cal will make it clear: the top left day 'num' is right, but the full (date) is off by one day. -- 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-1192) calendar (generator) is malfunctioning
[ http://issues.apache.org/jira/browse/COCOON-1192?page=comments#action_12356273 ] Ugo Cei commented on COCOON-1192: - I think the original poster was referring to a different kind of bug. Depending on your time zone, the dates that are printed in cells may not correspond to the day numbers that are printed in the top left corner. I think I have a fix for this, but will need people in different time zones to test it, after I have patched the code. Whether Sunday or Monday is to be considered the first day is another problem. In any case, I don't think you should fix it in the stylesheet. The stylesheet is just a sample, and the output of the generator should be correct indepentent of any stylesheet that might be applied to it. calendar (generator) is malfunctioning -- Key: COCOON-1192 URL: http://issues.apache.org/jira/browse/COCOON-1192 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.5 Environment: Operating System: Windows XP Platform: PC Reporter: Ian F. Hood Assignee: Ugo Cei Attachments: calendar2html.xslt a quick peek at /samples/cal will make it clear: the top left day 'num' is right, but the full (date) is off by one day. -- 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: cforms: a bugfix and an update
Il giorno 24/ott/05, alle ore 14:49, Sylvain Wallez ha scritto: I have the updated transformer ready on my HD. Shall I commit it? They look like bugfixes to me. +1. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
[CForms] Ambiguous rule in stylesheets
I just got this error while displaying a previously working form in an application, after having updated Cocoon to the latest revision (326894) from branch 2.1: Ambiguous rule match for /html/body[1]/div[1]/fi:form-template[1]/ fi:group[1]/fi:items[1]/div[2]/fi:field[1]/fi:styling[1]/@type Matches both fi:styling/@type on line 134 of resource://org/apache/ cocoon/forms/resources/forms-field-styling.xsl and fi:styling/@* on line 116 of resource://org/apache/cocoon/forms/ resources/forms-field-styling.xsl I tried to fix it by adding priority=-1 to the template at line 116 and it seems that it works now, but I'm afraid of having broken something else. Could someone else please verify the proposed fix before I commit it? Ugo P.S. Now it works but it's the HTMLArea which stopped working ... sigh -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [CForms] Ambiguous rule in stylesheets
Il giorno 20/ott/05, alle ore 22:14, Peter Hunsberger ha scritto: On 10/20/05, Ugo Cei [EMAIL PROTECTED] wrote: P.S. Now it works but it's the HTMLArea which stopped working ... sigh Try changing thhe priority the other way (bet you're using Saxon?) The problem I have now (and which probably has nothing to do with transformation) is that the contents of the HTMLArea are not copied to the form model upon save ... unless I switch the HTMLArea from WYSIWYG mode to text mode, strange as it may seem. My field is required and no matter what I input, validation always fails. But if I click on the button and submit, then it works. This seems to be the case whether Saxon or Xalan is used. And it happens only in my form and not in the samples. Ugo
Re: Cocoon Setup.exe for Windows
Il giorno 14/ott/05, alle ore 02:02, Antonio Gallardo ha scritto: In short 1 installer for all the platforms. Maybe we can also build a simple GUI for block selection for deployment and so on. ;-) Antonio, weren't you paying attention when I wrote this [1] just a few days ago? ;-) Ugo [1]: http://article.gmane.org/gmane.text.xml.cocoon.user/52218/ -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: ApplesProcessor - a little crazy idea
Il giorno 14/ott/05, alle ore 04:07, David Crossley ha scritto: Then how about mature. I'm afraid a few anti-spam filter might be triggered by that ;-). Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: svn commit: r314929 - in /cocoon: blocks/core-samples-additional/trunk/samples/ blocks/core-samples-additional/trunk/samples/resources/ blocks/core-samples-additional/trunk/samples/resources/i18n/
Il giorno 12/ott/05, alle ore 16:48, Vadim Gritsenko ha scritto: Check your ~/.subversion/config, it should have [auto-props] section set up. For files already added to the svn, use this shell script: Would you be so nice as to share with us the contents of your [auto- props] section? I assume you have added all filename patterns that are relevant for Cocoon sources. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: Question about addition of -input to id of CForms widgets
Il giorno 12/ott/05, alle ore 11:35, Bruno Dumon ha scritto: I've noticed that in 2.1-head all widgets have in their HTML rendering the text -input added to their widget id (and are contained in a span which has the original widget id). I assume this is to support the new ajax stuff, but is there a reason why this couldn't have been done the other way around? e.g. add -container to the surrounding elements' id. The problem is that (at least for me) this requires updating some javascript here and there which makes use of the IDs, and more annoying, that it makes it hard to support both 2.1.7 and 2.1.8 at the same time for the same application. I agree. I discovered this by chance when some scripts I had that used document.getElementById() stopped working after an update. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [VOTE] new committer: Max Pfingsthorn
Il giorno 11/ott/05, alle ore 08:28, Bertrand Delacretaz ha scritto: So I have the pleasure of proposing Max as our new committer! Please cast your votes, here's mine: +1 +1 Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [VOTE] Move to Jira (Was: Re: Jira or Bugzilla...)
Il giorno 11/ott/05, alle ore 12:43, Pier Fumagalli ha scritto: [X] +1 Yes please, let's move all our bugs to Jira and set it up to work in the following way: Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Introducing Guilder
Guilder is a little graphical interface whose aim is to simplify the life of Cocoon newbies by providing: - easy selection of blocks and features, taking dependencies in due consideration - starting the build - starting and stopping Cocoon via Jetty Most of the programming has been done by my colleague Daniele Madama (d.madama AT pronetics DOT it), who already introduced his work in this thread [1]. This is just a first, rough version, but we wanted to commit it as soon as possible, following the OSS mantra of release early, release often and what better occasion than the GetTogether to do it? Much work remains to be done, like for instance: - polishing the UI - stopping Jetty (does not work at the moment) - showing the progress of the build in a window - etc. but now that the code is available, if you want to contribute you can check out the code from [2] and start hacking away. Just use ant to build it. It will copy a JAR file in Cocoon's directory (by default ../../BRANCHES_2_1_X but you can ovveride it in guilder.properties) and you should then launch it by moving to Cocoon's home directory and running java -jar tools/lib/guilder.jar. It is our hope that this tool will make Cocoon more popular by presenting a simpler approach than what is provided by the present installation procedure, which might scare some users away. Once it is sufficiently polished, we could simply distribute the jar together with every Cocoon release, as this is a simple addition that does not change in any other way the existing build. Guilder is just for Cocoon 2.1. The configuration and build procedure in the coming major releases will be very different and won't probably need such a tool, but it is expected that many people will be working with 2.1 for a long time still. Why the name Guilder? The original name was Cocoon builder but soon it became something more than a simple builder. We also wanted to emphasize the GUI aspect. Since I am in Amsterdam right now, the name Guilder came up naturally. Guilder (gulden in Dutch) was the name of the Dutch currency before the Euro. Ugo [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=112722937629151w=2 [2] http://svn.apache.org/repos/asf/cocoon/whiteboard/guilder -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [GT2005] notetaking
Il giorno 05/ott/05, alle 10:59, Arje Cahn ha scritto: we're taking notes now at www.jotlive.com/hippo/Cocoon%20GT And Sorry, you haven't been invited to this page. is what I get here, after having registered. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [GT2005] Jotspot?
Il giorno 03/ott/05, alle 10:38, Arje Cahn ha scritto: Stefano was talking about JotSpot in his RT; did anyone try this? JotSpot Live [1] seems to be the SubEthaEdit-for-those-without-a-Mac (indeed, I'm talking purely for myself ;-) ). Another product in this area is Writeboard http://www.writeboard.com. JotSpot is sold as a real-time collaborative environment, while Writeboard is not. OTOH, Writeboard is free, while JotSpot Live is free for max. 5 pages, which should be enough for the GT. I haven't tried any of them yet, but i read a couple reviews on www.solutionwatch.com Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [GT2005] Mirroring Apache SVN?
Il giorno 27/set/05, alle 15:46, Arje Cahn ha scritto: Last year at the hackaton I found myself waiting for hours for my Eclipse to checkout the latest Cocoon code until I could actually do something. Does anyone know of an option of doing this in advance before the hackaton and have some kind of a mirror/proxy on location? Checking it out on your laptop before coming to the hackathon, maybe? ;-) Sorry, couldn't resist. The proxy idea might be useful, but I don't know how it could be accomplished. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [cforms] rethinking library naming
Il giorno 26/set/05, alle 17:23, Sylvain Wallez ha scritto: - rename fd:class to fd:macro (this is the wording used on the wiki [1][2]) - rename fd:new to fd:expand: expanding is the word used traditionally to denote insertion of the macro contents at the current location. I'd rather use fd:call-macro or something like that to reinforce the idea that what we are expanding is indeed a macro. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: Do we want a GUI installer?
Il giorno 22/set/05, alle 21:32, Upayavira ha scritto: 4. Could you make it use a more modern UI style? What do you mean by modern? Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: Do we want a GUI installer?
Il giorno 22/set/05, alle 23:49, Upayavira ha scritto: The application has the default Java swing look, which isn't very exciting. So, anything that looks a little prettier... Oh, well, on my Mac it has the Aqua look, so it looks rather pretty, but I agree that it could be much prettier. Actually, before I helped Daniele tweak the UI just a little, it looked *really* ugly ;-). If I remember correctly, selecting the default platform LF is quite simple and this would give Windows users a more familiar UI, so I'm +1 on that. As for Linux/Unix people, they are accustomed to ugly, inconsistent GUIs so they shouldn't care much ;-) Besides I think GTK is the default platform LF on Linux starting with JDK 1.5. Personally, I prefer Metal, but that's just me. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: svn commit: r289973 - /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/CalendarGenerator.java
Il giorno 18/set/05, alle 23:00, [EMAIL PROTECTED] ha scritto:
+ protected String weekdays[] = { ,
+ Sunday, Monday, Tuesday, Wednesday, Thursday,
+ Friday, Saturday
+ };
Since the CalendarGenerator strives to be localizable as far as
possible, wouldn't it be better to use Java I18N features for
outputting localized weekday names instead of this?
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Wine Food Blog: http://www.divinocibo.it/
Re: [vote] Arje Cahn as a new Cocoon committer
Il giorno 08/set/05, alle 20:41, Sylvain Wallez ha scritto: I'd like to be the voice of a general opinion among Cocoon developers that Arjé Cahn should be made a Cocoon committer. +1 and welcome! Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: Warped Text...
Il giorno 02/set/05, alle 17:32, Pier Fumagalli ha scritto: Yep, but SVG IMVHO is quite overkill to generate a simple image... Plus I suspect that the blurring algorithm is quite easy to recognize (in terms of running a simple image analysis package over the generated output). Indeed, but my CAPTCHA widget is not tied to a particular image generation algorithm. It just calls a pipeline which must be able to get the string to be rendered from a session attribute. If you want, you can replace the one in the sample with one using your generator. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [CForms] Fixing samples, some questions arise
Il giorno 07/set/05, alle 14:22, hepabolu ha scritto: 1. the XHR_carselector sample is broken. I think it should either be fixed (seems to be difficult) or removed entirely. Since the current AJAX implementation is better, I propose to remove it. +1. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: Warped Text...
Il giorno 08/set/05, alle 18:53, Pier Fumagalli ha scritto: Yep, but SVG IMVHO is quite overkill to generate a simple image... Plus I suspect that the blurring algorithm is quite easy to recognize (in terms of running a simple image analysis package over the generated output). Indeed, but my CAPTCHA widget is not tied to a particular image generation algorithm. It just calls a pipeline which must be able to get the string to be rendered from a session attribute. If you want, you can replace the one in the sample with one using your generator. Chill... No need to be defensive... I assure you that I'm not being defensive at all :-) I was just trying to suggest that your reader would be a good complement to the CAPTCHA support in CForms and it would be better to show them together in a sample rather than not. Cheers, Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: Slightly OT: Eclipse is acting up with SVN on OS X. Please help.
Il giorno 20/ago/05, alle 21:17, hepabolu ha scritto: What kind of error? With that combination I had problems whenever my The error is highly informative: 'Problems opening perspective svnPerspective' and 'Plug-in ...subclipse.ui was unable to load class SVNPreferencesPage'. :-( No, that's a different error. I got it working with these SVN packages: http://metissian.com/projects/macosx/subversion/ Together with Eclipse 3.1 and the latest Subclipse (0.9.32) , under Panther (JDK 1.4) and Tiger (JDK 1.5) as well. Apart from the symlink issue, everything works pretty much as expected. I encourage you to try the Metissian svn packages. 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.
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: [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/
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: 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: 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/
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: [VOTE] Switch to Maven NOW
Il giorno 17/ago/05, alle 14:48, Carsten Ziegeler ha scritto: So please cast your votes for switching to Maven2 NOW as outlined/discussed in the proposal thread. +1 -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: svn commit: r231266 - in /cocoon/branches/BRANCH_2_1_X: ./ src/java/org/apache/cocoon/generation/ src/java/org/apache/cocoon/util/jxpath/ src/java/org/apache/cocoon/xml/ src/test/org/apache/cocoon
Il giorno 15/ago/05, alle 20:21, Sylvain Wallez ha scritto: Fixed! Please cross-check! Looks good! Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: svn commit: r231266 - in /cocoon/branches/BRANCH_2_1_X: ./ src/java/org/apache/cocoon/generation/ src/java/org/apache/cocoon/util/jxpath/ src/java/org/apache/cocoon/xml/ src/test/org/apache/cocoon
This patch seems to have broken some of the JX templates I was using.
In particular, I had templates where the jx namespace prefix was
declared in a single jx:forEach element (most of the content is
static and I just need to interate a collection to display a table):
jx:forEach items=${channels} var=channel xmlns:jx=http://
apache.org/cocoon/templates/jx/1.0
...
/jx;forEach
Now these templates throw the following exception:
java.lang.IllegalStateException: Misbalanced enter and leaving of scope.
at org.apache.cocoon.xml.NamespacesTable.leaveScope
(NamespacesTable.java:228)
at org.apache.cocoon.xml.RedundantNamespacesFilter.endElement
(RedundantNamespacesFilter.java:72)
at org.apache.cocoon.generation.JXTemplateGenerator.execute
(JXTemplateGenerator.java:2632)
at
org.apache.cocoon.generation.JXTemplateGenerator.performGeneration
(JXTemplateGenerator.java:2497)
at org.apache.cocoon.generation.JXTemplateGenerator.generate
(JXTemplateGenerator.java:2491)
A simple workaround consists in putting the namespace declaration in
the root element of the template, but this is not nice to people who
have lots of templates to change. Is this a bug or a feature?
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Wine Food Blog: http://www.divinocibo.it/
Re: svn commit: r231266 - in /cocoon/branches/BRANCH_2_1_X: ./ src/java/org/apache/cocoon/generation/ src/java/org/apache/cocoon/util/jxpath/ src/java/org/apache/cocoon/xml/ src/test/org/apache/cocoon
On Aug 14, 2005, at 2:43 PM, Sylvain Wallez wrote:
This is clearly a bug, either in NamespacesTable or in JXTemplate.
I'll take care of this ASAP.
Thanks a lot.
Just a precision though: what's are the direct children of the
jx:forEach? Text, elements, mixed content?
Elements (and whitespace):
jx:forEach items=${channels} var=channel
xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
tr
tda href=${channel.link} target=_blank$
{channel.title}/a/td
tda href=${channel.url} target=_blank$
{channel.url}/a/td
td${channel.lastUpdate}/td
td${channel.description}/td
tda href=refreshChannel.do?id=$
{channel.id}Refresh/a/td
/tr
/jx:forEach
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Wine Food Blog: http://www.divinocibo.it/
Re: Bug# 34696 - Website update
Il giorno 11/ago/05, alle 17:15, hepabolu ha scritto: Now that I've got my commit rights working I will try to focus on the documentation. However, I've already found out that updating the website is not a simple thing to do, so it might get down to me patching the content and bugging others to do the actual update, in which case it means that you need to be patient some more. Rest assured I greatly appreciate every help, big or small, with the documentation. I haven't been following all the recent threads on reworking the documentation, so I'm feeling a bit confused. In particular, I've recently added one small new feature to CForms and I want to document it before it slips off my mind. Should I update the usual website docs or am I supposed to do the update somewhere else? Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
[Forms] Bug in Ajax when changing widget state?
Hi people, still trying to push CForms to its limits ;) I found what might be a bug in the Ajax implementations. I have an event handler that switches the state of a widget from ACTIVE to INVISIBLE and vice-versa. When not using Ajax, everything works fine, but when ajax=true the widget appears and disappears as expected, but its label stays forever hidden! Two points to note here: 1. the widget state is initially INVISIBLE 2. the widget is laid out in a group using fi:styling type=colums/ Can anyone else confirm this? Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [cforms] fi:validation-errors in AJAX mode (was: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl)
Il giorno 01/ago/05, alle 22:37, Jason Johnston ha scritto: We create a new template element, ft:validation-errors /. When this element is encountered by FormsTemplateTransformer (or the jx macros), the widget tree is walked and each widget is checked for a validation error. If one is present it is added to the transformer output, for example: fi:validation-errors id=forms-validation-errors-0 fi:validation-error widget-id=streetValidation error for street widget/fi:validation-error fi:validation-error widget-id=companyInfo.companyNameValidation error for company name widget/fi:validation-error !-- etc. for each validation error in the form -- /fi:validation-errors The @id in that output is autogenerated, and the number on the end is an index so that we can allow the template element to appear multiple times in the document and avoid duplicate ids (if necessary, just a thought.) In terms of XSLT styling, if there are no errors present then it would be presented like fi:placeholder (create an element with the matching @id so the AJAX code knows where to insert its replacement). If there are errors present then it would be presented much like the current fi:validation-errors. Looks good to me. AFAIK, Ajax support works only with the template macros, so it might not make sense to add this feature to the transformer also. What is the orientation of the community towards the transformer/macros ambiguity? I'd like to have just one recommended implementation of this, so if macros are the way to go, what about deprecating the forms transformer? * How, if at all, would be retain compatibility with the old fi:validation-errors styling element? One approach might be to check for the presence of the @id attribute in the XSLT and if it isn't there use the old xsl:template. Anoother possibility would be using a totally different name for the element you are proposing here. But I think I like your idea more. We can put a comment before the old template stating that it is there for backward compatibility reasons only, and in one of the next releases modify it to output a deprecation warning message. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [CForms] Creating an intermediate object in binding
Il giorno 29/lug/05, alle 16:34, Sylvain Wallez ha scritto: The solution would be to allow each JXPath binding to have its own factory class. This can be easily implented by adding support for a factory attribute in JXPathBindingBuilderBase. I just committed (BRANCH_2_1_X only ATM) a fix that allows you to add a factory attribute to fb:context elements. We could probably do the same for fb:value elements but since intermediate objects are usually meant to be containers for other objects (the typical address case), having to group them within an fb:context is probably good practice anyway and not too much of a requirement. Anyway, I just wanted to ask someone to cross-check my implementation, since I'm not familiar enough with the binding framework to spot obvious deficiencies. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [CForms] Creating an intermediate object in binding
Il giorno 31/lug/05, alle 14:01, Leszek Gawron ha scritto: I have defined a custom type and convertor for that. The convertor is actually managed by Spring and populated with a DAO and the convertor's factory returns the Spring-managed instance instead of creating a new one. The convertor itself is spring manager or just the dao it holds? Both. Do I get it right that you need to implement a separate: - dao - convertor - convertor builder for every domain object in your model? Not really. I do it only for those types that are reused across many forms and therefore warrant defining a datatype and convertor. At the moment, we have developed datatypes for a bunch of geographical objects like Town, Province, Country, that are used in all the forms where you have to input an address. And we have a single GeoDAO class for all entities of this kind. In general, I would do this for every datatype that is implemented as a look-up-table (key = value) in the database and is reused in more than a couple of forms, or across more than one different project. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
Il giorno 01/ago/05, alle 15:24, Sylvain Wallez ha scritto: Tags with an @id is an essential piece of the Ajax stuff, which is based on partial updates of page areas found by their id. Your update removes the @id on the enclosing tag, and removes the placeholder that is necessary when no error exist to later replace it by something visible if error appear. If I'm not mistaken, that instruction copied the id attribute of the fi:validation-errors element, but I've never put an id attribute there. Is it necessary to set an id to every fi:validation-errors element in order for it to appear when ajax=true? If this is the case, now I know why my fi:validation-errors blocks don't render anymore when ajax=true :-/ Also, if this is the case, the div element should be output regardless of whether there are validation errors or not, right? Not that putting it back is a problem, I am just trying to understand. The only real issue I had was with the div not having a class attribute, but while I was at it, I tried to optimize away a useless element and an empty attribute. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl
Il giorno 01/ago/05, alle 15:57, Sylvain Wallez ha scritto: If I'm not mistaken, that instruction copied the id attribute of the fi:validation-errors element, but I've never put an id attribute there. Is it necessary to set an id to every fi:validation-errors element in order for it to appear when ajax=true? If this is the case, now I know why my fi:validation-errors blocks don't render anymore when ajax=true :-/ Actually, I'm a bit lost here: what template instruction or widget produces this fi:validation-errors element? I'm not sure where I lost you ;-). Weren't we talking about the template in forms-field-styling.xsl that I modified: xsl:template match=fi:validation-errors ? The fi:validation-errors element is described here: http://cocoon.apache.org/2.1/userdocs/forms/xslt.html#fi%3Avalidation- errors Otherwise, it's me who's lost. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
