Re: svn commit: r398882 -/cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/transf ormation/EncodeURLTransformer.java
Do you mean in general or this specific one? I try to in general. This one is there under 2.1.9 as fixes-bug=COCOON-1742. Speaking of which, now that this is also on trunk I can close it. Ralph Carsten Ziegeler wrote: Ralph Goers wrote Thanks for doing this. Did you also delete ElementAttributeMatching from the util directory? Done now, thanks for the hint. Btw, could you please add an entry to status.xml in 2.1.x for your changes? Thanks Carsten
Re: [RT] Simplifying setup
I understand that you guys are frustrated that you can't use trunk in production or even try to migrate your existing apps. I (and I think Daniel too) feel frustrated because whenever we make some progress and tell the list about it, somebody is complaining about this or that (look at the subject of this thread!!!). Of course, it's everybody's right to express his thoughts and feelings, but this kind of reaction is not what we expect. As being said several times Daniel and I know what's to do and we work continiously on it. That might be too slow for some of us (including Daniel and me!), but that's the best thing we can offer. Additionally I want to point out (again), that our work on the OSGi integration is completly _orthogonal_ to the thing that we call Cocoon and you don't have to dig into stuff you don't understand just to get something done in trunk. A couple of weeks I wrote a Maven plugin that extracts blocks into a Cocoon webapp, which was a first step into the direction to get trunk working again. Reinhard Ralph Goers wrote: Thanks, Upayavira. Your response is better than what I would have written myself. In addition, I have quite a bit of frustration that it doesn't seem (from my perspective) that it is all that important to those who do have the time to try to get a release of trunk out. It would make it far easier for me to recommend moving to 2.2, and this be given the time at work, if a release was in sight. As it is I expect there to be several milestone releases before a 2.2.0 is released. I pushed hard for a 2.1.9 release primarily because my project at work is on a deadline and I needed all the latest portal patches. I am currently adding enhancements to the 2.1.9 base even though I know Carsten has already added similar functionality in trunk. Believe me, I'd much rather just use those, but given the way things are I really don't have a choice. Ralph Upayavira said: Reinhard Poetz wrote: Ralph Goers wrote: I also get paid to do real work. OSGi doesn't fit in those plans. A lot of other stuff in trunk does but I can't have it because a release of trunk isn't going to happen in 2006. My employer won't pay me to work on stuff that they won't see in the next few months. And there is enough stuff in 2.1 that needs fixing to keep me busy for a long time. What exactly is stopping you from working on trunk to make the release happen? People differ in terms of their freedom to work. Some people are fortunate in that they have free time that they can contribute to projects they believe in. Others aren't. I myself have a young family, with another on the way, which pretty effectively fills my non-work time. So, the only way I can get to work on projects is to persuade my boss that it is a good idea, and do it on work time. And of course bosses tend not to favour their employees working on speculative projects that _may_ give results, unless that is directly related to the nature of their business. I personally have had the opportunity to introduce Cocoon into my current workplace, but, due to the additional complexity it would have brought to play, have not been able to justify it. Thus, I have not been in a position to contribute to Cocoon in terms of code for quite some time. Personally, I am grateful that you and Daniel are free to do the work that you are doing. If you get a sense of frustration from Ralph, perhaps you can read that as the frustration that he himself doesn't have the kind of free time to give to it that you do. For Ralph to be able to contribute, he needs to be able to justify it. If you could help him justify it, he may help sooner. Otherwise, he'll just carry on waiting. Either, in the end, is just going to have to be fine. But then, surely all of the above is obvious, no? ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: svn commit: r398882 -/cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/transf ormation/EncodeURLTransformer.java
Ralph Goers schrieb: Do you mean in general or this specific one? I try to in general. This one is there under 2.1.9 as fixes-bug=COCOON-1742. Speaking of which, now that this is also on trunk I can close it. I meant this specific one. As far as I followed this, there was a bug in the 2.1.9 release and you fixed this recently. So it might be worth adding this, so people upgrading to 2.1.10 will now that this one is fixed. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Subscription: COCOON-open-with-patch
Issue Subscription
Filter: COCOON-open-with-patch (92 issues)
Subscriber: cocoon
Key Summary
COCOON-1840 [PATCH] XMLFileModule file-specific configuration ignored
http://issues.apache.org/jira/browse/COCOON-1840
COCOON-1839 exception2html.xslt script / causes IE display problem
http://issues.apache.org/jira/browse/COCOON-1839
COCOON-1838 Always use 3-digit version number
http://issues.apache.org/jira/browse/COCOON-1838
COCOON-1825 Ajax errror when an active state widget become invisible state
widget
http://issues.apache.org/jira/browse/COCOON-1825
COCOON-1811 [PATCH] Flow Script: Allow dynamic loading of JavaScript objects
even when scope is locked
http://issues.apache.org/jira/browse/COCOON-1811
COCOON-1810 [PATCH] JMSEventMessageListener does not work
http://issues.apache.org/jira/browse/COCOON-1810
COCOON-1801 [PATCH] Repeater events
http://issues.apache.org/jira/browse/COCOON-1801
COCOON-1794 [PATCH] Propagation of namespaces to a repeaters child bindings and
implementation of a move-node binding
http://issues.apache.org/jira/browse/COCOON-1794
COCOON-1782 [PATCH] Support for CSS classes in cocoon forms XSL
http://issues.apache.org/jira/browse/COCOON-1782
COCOON-1781 Processing phase listener cannot be configured from form definitio
http://issues.apache.org/jira/browse/COCOON-1781
COCOON-1776 [PATCH]Reload Bookmarks on bookmark file validity
http://issues.apache.org/jira/browse/COCOON-1776
COCOON-1774 Fine Tuning Ajax Handling in CForms
http://issues.apache.org/jira/browse/COCOON-1774
COCOON-1744 NullPointerException in template block
http://issues.apache.org/jira/browse/COCOON-1744
COCOON-1741 [PATCH] Output widget does not initialize from fd:initial-value
http://issues.apache.org/jira/browse/COCOON-1741
COCOON-1738 double-listbox problem in repeaters
http://issues.apache.org/jira/browse/COCOON-1738
COCOON-1732 Ajax and IE empty textarea bugfix
http://issues.apache.org/jira/browse/COCOON-1732
COCOON-1726 Implementation of Source that supports conditional GETs
http://issues.apache.org/jira/browse/COCOON-1726
COCOON-1717 Use custom cache keys for caching uri coplets using input modules.
http://issues.apache.org/jira/browse/COCOON-1717
COCOON-1706 Allow TeeTransformer to run a system command for debugging purposes
http://issues.apache.org/jira/browse/COCOON-1706
COCOON-1703 A patch for caching fonts (fixes GDI issues), vertical text
orientation, color code fix, prefered unit for margins and measure unit
converter
http://issues.apache.org/jira/browse/COCOON-1703
COCOON-1697 Allow request parameters to be used in for (var k in h) kind of
Javascript Loops
http://issues.apache.org/jira/browse/COCOON-1697
COCOON-1692 [PATCH] Tree widget not handling on-selection-change events
correctly.
http://issues.apache.org/jira/browse/COCOON-1692
COCOON-1686 [PATCH] COCOON-1671 Form not binding when prefix in binding
definition is unequal to that in the instance data for the same namespace.
http://issues.apache.org/jira/browse/COCOON-1686
COCOON-1648 I18nTransformer add support for ISO8601
http://issues.apache.org/jira/browse/COCOON-1648
COCOON-1622 [PATCH] SendMailTransformer and HTML body
http://issues.apache.org/jira/browse/COCOON-1622
COCOON-1618 [PATCH] SoapGenerator/Serializer for Axis Block
http://issues.apache.org/jira/browse/COCOON-1618
COCOON-1611 [PATCH] Add additonal constructor to FormInstance.java to be able
to pass a locale
http://issues.apache.org/jira/browse/COCOON-1611
COCOON-1606 [BUG+PATCH] FormattingDecimalConvertor.java does not parse in
BigDecimal mode
http://issues.apache.org/jira/browse/COCOON-1606
COCOON-1603 [PATCH] handling of alternatives in MailTransformer
http://issues.apache.org/jira/browse/COCOON-1603
COCOON-1587 [PATCH] Simple i18n support for selectionLists
http://issues.apache.org/jira/browse/COCOON-1587
COCOON-1573 Improvement SetAttributeJXPathBinding and Contribution
SetNodeValueJXPathBinding
http://issues.apache.org/jira/browse/COCOON-1573
COCOON-1557 [PATCH] Change access to AbstractContinuable.getContext to protected
http://issues.apache.org/jira/browse/COCOON-1557
COCOON-1556 [PATCH] Add a JXPathConvertor for conversion betwean beans and
Strings
http://issues.apache.org/jira/browse/COCOON-1556
COCOON-1535 [PATCH] enhancement to {global:} input module: return all sitemap
globals
http://issues.apache.org/jira/browse/COCOON-1535
COCOON-1527 [PATCH] Cache control logic sheets for XSP to override getKey and
getValidity
http://issues.apache.org/jira/browse/COCOON-1527
COCOON-1526 [PATCH] processToDOM returns a read-only DOM
[jira] Closed: (COCOON-1511) [Patch] User-Agent is PARAMETER, not HEADER in Command-line interface
[ http://issues.apache.org/jira/browse/COCOON-1511?page=all ] Carsten Ziegeler closed COCOON-1511: Fix Version: 2.2-dev (Current SVN) 2.1.10-dev (current SVN) Resolution: Fixed [Patch] User-Agent is PARAMETER, not HEADER in Command-line interface - Key: COCOON-1511 URL: http://issues.apache.org/jira/browse/COCOON-1511 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Environment: Operating System: All Platform: All Reporter: James Bates Assignee: Carsten Ziegeler Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) Attachments: cli-user-agent-header.patch, user-agent.patch The Cocoon command line interface provides a switch for simulating the Cocoon User-Agent header that would be sent by a browser. The idea being that it could be used by e.g. the browser selector to detect that a request is coming from the CLI. When investigating however, I noticed that the Cocoon bean (the class that implements the CLI) does not place the User-Agent into a HEDAER, but into a request PARAMETER instead (occurs on line 407 of CocoonWrapper.java, in method processURI() in BRANCH_2_1_X; line 421 of the same file in 2.2 trunk). -- 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-1685) Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent
[ http://issues.apache.org/jira/browse/COCOON-1685?page=comments#action_12377578 ] Antonio Gallardo commented on COCOON-1685: -- You should close this issue if you already committed the fix. Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent - Key: COCOON-1685 URL: http://issues.apache.org/jira/browse/COCOON-1685 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8 Reporter: Simone Gianni Attachments: process_initialize.diff In the Form.process() method, there is a listener.phaseEnded on line 296 which sends a LOAD_MODEL_VALUE the first time the form is executed, and a READ_FROM_REQUEST_VALUE all the other times. If a ProcessingPhaseListener is registered it will receive a READ_FROM_REQUEST_VALUE before the request has been processed, and another one after. IMMO there are the following possible solutions : - remove this event broadcast. - send this event only if phase is LOAD_MODEL_VALUE, so that this event takes his chance to get broadcasted, while the spurious one doesn't. - add a PROCESS_INITIALIZED phase event and send this one at this point. I can produce the patch if needed, but don't know which solution is the best one. -- 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: [jira] Commented: (COCOON-1685) Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent
Hi Antonio, you are defitively right, sorry, but since I've not yet been granted jira rights i didn't noticed i could close that one :) Could someone grant me jira rights? Simone Antonio Gallardo (JIRA) wrote: [ http://issues.apache.org/jira/browse/COCOON-1685?page=comments#action_12377578 ] Antonio Gallardo commented on COCOON-1685: -- You should close this issue if you already committed the fix. Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent - Key: COCOON-1685 URL: http://issues.apache.org/jira/browse/COCOON-1685 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8 Reporter: Simone Gianni Attachments: process_initialize.diff In the Form.process() method, there is a listener.phaseEnded on line 296 which sends a LOAD_MODEL_VALUE the first time the form is executed, and a READ_FROM_REQUEST_VALUE all the other times. If a ProcessingPhaseListener is registered it will receive a READ_FROM_REQUEST_VALUE before the request has been processed, and another one after. IMMO there are the following possible solutions : - remove this event broadcast. - send this event only if phase is LOAD_MODEL_VALUE, so that this event takes his chance to get broadcasted, while the spurious one doesn't. - add a PROCESS_INITIALIZED phase event and send this one at this point. I can produce the patch if needed, but don't know which solution is the best one. -- Simone Gianni
[jira] Closed: (COCOON-1685) Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent
[ http://issues.apache.org/jira/browse/COCOON-1685?page=all ] Simone Gianni closed COCOON-1685: - Resolution: Fixed Committed fix Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent - Key: COCOON-1685 URL: http://issues.apache.org/jira/browse/COCOON-1685 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8 Reporter: Simone Gianni Attachments: process_initialize.diff In the Form.process() method, there is a listener.phaseEnded on line 296 which sends a LOAD_MODEL_VALUE the first time the form is executed, and a READ_FROM_REQUEST_VALUE all the other times. If a ProcessingPhaseListener is registered it will receive a READ_FROM_REQUEST_VALUE before the request has been processed, and another one after. IMMO there are the following possible solutions : - remove this event broadcast. - send this event only if phase is LOAD_MODEL_VALUE, so that this event takes his chance to get broadcasted, while the spurious one doesn't. - add a PROCESS_INITIALIZED phase event and send this one at this point. I can produce the patch if needed, but don't know which solution is the best one. -- 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: [jira] Commented: (COCOON-1685) Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent
Pier ping! :-) Best Regards, Antonio Gallardo. Simone Gianni escribió: Hi Antonio, you are defitively right, sorry, but since I've not yet been granted jira rights i didn't noticed i could close that one :) Could someone grant me jira rights? Simone Antonio Gallardo (JIRA) wrote: [ http://issues.apache.org/jira/browse/COCOON-1685?page=comments#action_12377578 ] Antonio Gallardo commented on COCOON-1685: -- You should close this issue if you already committed the fix. Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent - Key: COCOON-1685 URL: http://issues.apache.org/jira/browse/COCOON-1685 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8 Reporter: Simone Gianni Attachments: process_initialize.diff In the Form.process() method, there is a listener.phaseEnded on line 296 which sends a LOAD_MODEL_VALUE the first time the form is executed, and a READ_FROM_REQUEST_VALUE all the other times. If a ProcessingPhaseListener is registered it will receive a READ_FROM_REQUEST_VALUE before the request has been processed, and another one after. IMMO there are the following possible solutions : - remove this event broadcast. - send this event only if phase is LOAD_MODEL_VALUE, so that this event takes his chance to get broadcasted, while the spurious one doesn't. - add a PROCESS_INITIALIZED phase event and send this one at this point. I can produce the patch if needed, but don't know which solution is the best one.
[jira] Closed: (COCOON-1781) Processing phase listener cannot be configured from form definitio
[ http://issues.apache.org/jira/browse/COCOON-1781?page=all ]
Simone Gianni closed COCOON-1781:
-
Resolution: Fixed
Committed the patch
Processing phase listener cannot be configured from form definitio
--
Key: COCOON-1781
URL: http://issues.apache.org/jira/browse/COCOON-1781
Project: Cocoon
Type: Improvement
Components: Blocks: Forms
Reporter: Simone Gianni
Attachments: phase_listener.diff
It's not currently possible to specify a ProcessingPhaseListener from the
form definition.
The patch makes it possible to specify a fd:on-processing-phase and specify
a listener in it. Also patched the javascript listener to support this kind
of events, so that fd:javascript can be used. For example :
fd:form
fd:on-processing-phase
fd:javascript
Packages.java.lang.System.out.println('Processing phase : ' +
event.getPhase());
/fd:javascript
/fd:on-processing-phase
fd:widgets
--
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-1801) [PATCH] Repeater events
[ http://issues.apache.org/jira/browse/COCOON-1801?page=all ] Simone Gianni closed COCOON-1801: - Resolution: Fixed Committed the patch. [PATCH] Repeater events --- Key: COCOON-1801 URL: http://issues.apache.org/jira/browse/COCOON-1801 Project: Cocoon Type: New Feature Components: Blocks: Forms Versions: 2.1.9 Reporter: Simone Gianni Attachments: repeaterlistener-sample.diff, repeaterlistener.diff Since I felt the need and there are many comments in the code about it, i've implemented a RepeaterListener. The listener is triggered on row addition, deletion, reordering and clear. The event also brings informations about the row index and the actual action that took place. I've adapted the javascript listener to support this new listener, and in the meanwhile also noticed that lines 59 to 70 of it are useless, since i believe that code has been moved inside the JavaScriptHelper methods and those lines were left there. I've added a sample in form1, in the contact repeater. It's better to use the flow version of the sample, since in the no-flow sample the repeater is always recreated, an all events are broadcasted again. The usage is simply : fd:repeater fd:on-repeater-modified fd:javascript/fd:javascript fd:other-listener.../fd:other-listener /fd:on-repeater-modified /fd:repeater I took care to call the event after the row has been initalized and to provide two events (deleting and deleted) for row deletion, so that accessing the new or about to be deleted row inside the listener should not be a problem. The forms1.xml listener has an example on how to do this. The only place where i'm not sure this will always work correctly is inside the initialize method, maybe the event broadcast should be moved to somewhere else, or at least after the super.initialize() call, just to make sure that when the listener gets the event everything is properly set up. Please note that the patch includes modifications on the javascript listener (o.a.c.forms.events.impl.JavaScript*) which i already modified in COCOON-1781. Regarding this file this patch will conflict with the other one (since both contains the same modifications) and in part superseedes the other one (due to the lines i've removed). So please apply the COCOON-1781 first, then this one, and if having problems applying this one revert the o.a.c.forms.event.impl.JavaScript* classes and then retry. -- 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
[Fwd: CForms and Uploads?!?!]
---BeginMessage--- I am beyond frustrated with trying to adapt the CForms upload feature to our application. I have about two hours left for today, and I'd like to get it working, but if I can't I will resort to the traditional method of forms and actions. Please, if you have bandwidth to spare, contact me on MS Messenger: [EMAIL PROTECTED] I'm experiencing strange things. Once the initial form is displayed and sent to the server, whether everything is OK or not, it goes to the success scenario. Worse, the success scenario is a cocoon stack trace with a SAXException saying No Cocoon Form found. Nothing I can see in my sitemap or flowscript suggests that that should happen, and yet here I am. ---End Message---
Re: svn commit: r398882 -/cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/transf ormation/EncodeURLTransformer.java
Right. Thanks for reminding me as I had forgotten about it. Ralph Carsten Ziegeler wrote: Ralph Goers schrieb: Do you mean in general or this specific one? I try to in general. This one is there under 2.1.9 as fixes-bug=COCOON-1742. Speaking of which, now that this is also on trunk I can close it. I meant this specific one. As far as I followed this, there was a bug in the 2.1.9 release and you fixed this recently. So it might be worth adding this, so people upgrading to 2.1.10 will now that this one is fixed. Carsten
[RT] Resources Accessible Via Subsitemaps To Enable Better Re-Use
Hello All, I have hit a stumbling block with Cocoon. Basically, I have discovered on past mailing list discussions, that resources in a sitemap are not accessible by their mounted children sitemaps. This presents a major obstacle for me. I understand that I can use the file generator with a call to cocoon://, and even access an internal pipeline to keep things somewhat more secure and separate concerns. However, the fragments I am re-using do not contain a generator or a serializer. Let me explain... Basically, I frequently make a call to the SQL transformer to fetch some information. The result set is in an Apache SQL namespace, which is not what I want. I then apply a generic stylesheet to the result set from the SQL transformer, to change the namespace to an internal namespace which reflects what this result embodies (there is more to it than just that, I'm not just changing the namespace, but the semantics of the result set too). This helps me not make mistakes, because I can say to myself AHA! This is such and such a result set, and so doesn't make sense here... I also have other resources that will be added as time goes on, and I can think of uses for them :-) I have put this into a resource, so that with a few parameters I can perform the query (based off whatever XML is in the pipeline, and with a parameter specifying which datasource to use... e.g. test database or production)... another parameter specifies the namespace of the document. To my dismay, I cannot globally access the resources from the sub sitemaps. This severely limits my usage of Cocoon... I either have to find a way to make it work or come up with a creative solution. However, I have frequently felt restricted in working with cocoon lately... I'm not putting down Cocoon in any way, just learning the Cocoon way takes some time :-) What is the official design reason for resources not being accessible by child site maps ? Any suggestions would be greatly appreciated! AJ
Re: [jira] Commented: (COCOON-1685) Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent
Antonio Gallardo wrote: Pier ping! :-) There are other people here who can do that. Simone, i found that you have two Jira usernames s.gianni and [EMAIL PROTECTED] The latter only had one issue, so i moved it to the other user. However, i could not delete the [EMAIL PROTECTED] user because it has a stack of filters. Anyway, i added them both to the cocoon-developers group. -David Simone Gianni escribi??: Hi Antonio, you are defitively right, sorry, but since I've not yet been granted jira rights i didn't noticed i could close that one :) Could someone grant me jira rights? Simone Antonio Gallardo (JIRA) wrote: Antonio Gallardo commented on COCOON-1685: -- You should close this issue if you already committed the fix.
