Re: [RT] Resources Accessible Via Subsitemaps To Enable Better Re-Use
Adrien Guillon wrote: >What is the official design reason for resources not being accessible by > child site maps ? > I guess originally this has just been forgotten to be implemented. >Any suggestions would be greatly appreciated! > With 2.2 we will have a different solution, the virtual sitemap components which can be compared to resources and which are inherited to sub sitemaps. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
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.
[jira] Updated: (COCOON-1493) eclipse-project target not working
[ http://issues.apache.org/jira/browse/COCOON-1493?page=all ] David Crossley updated COCOON-1493: --- Bugzilla Id: (was: 34392) Reporter: Simone Gianni (was: Simone Gianni) > eclipse-project target not working > -- > > Key: COCOON-1493 > URL: http://issues.apache.org/jira/browse/COCOON-1493 > Project: Cocoon > Type: Bug > Components: * Cocoon Core > Versions: 2.1.7 > Environment: Operating System: All > Platform: All > Reporter: Simone Gianni > Assignee: Cocoon Developers Team > Priority: Trivial > > The eclipse-project target is not working properly. If I download cocoon, > unpack > it in the workspace and then create the .project with the given ant target, i > cannot import/restore the project inside eclipse. This is caused by the bug > 76417 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=76417 ) in eclipse, > simply > the project name must match the folder name. > It could seem a stupid problem, but reconfiguring the cocoon eclipse project > by > hand is something really frustrating and time consuming, and the eclipse error > message is confusing and unclear. > I suggest that the generated .project file uses the directory name as project > name, instead of "Cocoon 2.1.7". A dirname ant task could solve the problem, > I'll check it out. -- 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
[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: 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
[Fwd: CForms and Uploads?!?!]
--- Begin Message --- 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 ---
[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 : > > > > ... > > > 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
[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 and specify
> a listener in it. Also patched the javascript listener to support this kind
> of events, so that can be used. For example :
>
>
>
> Packages.java.lang.System.out.println('Processing phase : ' +
> event.getPhase());
>
>
> 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-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
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] 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
[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] 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 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
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
http://issues.apache.org/jira/brows
