Re: [2.2] Missing files for Ajax and CForms
Kamal wrote: Hi, I was trying to use Cocoon, but I had the following files come up as missing: http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/i18n/manifest.js http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/i18n.js http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/dojo/__package__.js Now, some of these files do exist in the cocoon-ajax-impl jar file, but no pipeline exists to access them (for example, the manifest.js files). Any thoughts as to why the pipelines don't exist? Cheers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Nevermind. My bad. I didn't have i18n enabled. Though, I am surprised that it would affect the application in this way. Cheers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[2.2] CForms - div around group and other Cforms issues
Hi,
I have been struggling with CForms, trying to work out what I did wrong.
I think I found a couple of bugs in CForms.
I have a form that dynamically reveal sets of fields based on whether a
tick box has been checked. Because I was using a very old version of
CForms (2.1.7), I couldn't use the group method, so I had to reveal/hide
each field separately. I found out that this approach is not compatible
with CForms + Ajax because the labels are not updated. Also, the Cocoon
website says to put a div around all fields in a ft:group for Ajax. I
did this, but it kept failing. I had a look at the code and I found this:
xsl:template match=fi:[EMAIL PROTECTED] and count(*) = 1 and not(fi:*)]
xsl:apply-templates mode=copy-parent-id/
/xsl:template
xsl:template match=fi:group
xsl:apply-templates/
/xsl:template
xsl:template match=fi:group mode=copy-parent-id
xsl:copy
xsl:attribute name=idxsl:value-of
select=../@id//xsl:attribute
xsl:copy-of select=@*/
xsl:apply-templates/
/xsl:copy
/xsl:template
I changed it to this:
!--+
| fi:group - has no visual representation by default
| If the fi:group contains an id and has only one child that is
not in the fi: namespace,
| then copy the id to the child. This is needed for ajax when
grouping is just used to group
| widgets.
+--
xsl:template match=fi:[EMAIL PROTECTED] and count(*) = 1 and not(fi:*)]
xsl:apply-templates mode=copy-parent-id/
/xsl:template
xsl:template match=fi:group
xsl:apply-templates/
/xsl:template
*xsl:template match=* mode=copy-parent-id *
xsl:copy
xsl:attribute name=idxsl:value-of
select=../@id//xsl:attribute
xsl:copy-of select=@*/
xsl:apply-templates/
/xsl:copy
/xsl:template
and it all works. Is my fix correct? If so, should I create a patch
and/or Jira ticket?'
Also, the booleanfield no longer works the way it used to in 2.1.
Namely, I used to be able to do this:
if (widget.value == 'false')
{
// Do something.
}
Now, it is returning a Boolean object (maybe it always did, I don't
know) and I now have to do this:
if (widget.value.toString().equals('false'))
Any thoughts? Is it a good idea to return a string instead?
Finally, my previous post (BTW, sorry for all the emails) mentioned
javascript files that are missing/in the wrong spot. I had a look at the
logs and these files are still being requested, but they are not
impacting on the rendering of the page. However, for the life of me, I
cannot find the references to these files on my page.
Also, I know we have an ongoing issue with tabs and validation errors
not working. I was wondering about the rationale for not using
bu:replace on the appropriate divs to fix these issues?
Thanks.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2.2] CForms - div around group and other Cforms issues
Kamal pisze:
Hi,
I have been struggling with CForms, trying to work out what I did wrong.
I think I found a couple of bugs in CForms.
I have a form that dynamically reveal sets of fields based on whether a
tick box has been checked. Because I was using a very old version of
CForms (2.1.7), I couldn't use the group method, so I had to reveal/hide
each field separately. I found out that this approach is not compatible
with CForms + Ajax because the labels are not updated. Also, the Cocoon
website says to put a div around all fields in a ft:group for Ajax. I
did this, but it kept failing. I had a look at the code and I found this:
xsl:template match=fi:[EMAIL PROTECTED] and count(*) = 1 and not(fi:*)]
xsl:apply-templates mode=copy-parent-id/
/xsl:template
xsl:template match=fi:group
xsl:apply-templates/
/xsl:template
xsl:template match=fi:group mode=copy-parent-id xsl:copy
xsl:attribute name=idxsl:value-of
select=../@id//xsl:attribute
xsl:copy-of select=@*/
xsl:apply-templates/
/xsl:copy
/xsl:template
I changed it to this:
!--+
| fi:group - has no visual representation by default
| If the fi:group contains an id and has only one child that is not
in the fi: namespace,
| then copy the id to the child. This is needed for ajax when
grouping is just used to group
| widgets.
+--
xsl:template match=fi:[EMAIL PROTECTED] and count(*) = 1 and not(fi:*)]
xsl:apply-templates mode=copy-parent-id/
/xsl:template
xsl:template match=fi:group
xsl:apply-templates/
/xsl:template
*xsl:template match=* mode=copy-parent-id *xsl:copy
xsl:attribute name=idxsl:value-of
select=../@id//xsl:attribute
xsl:copy-of select=@*/
xsl:apply-templates/
/xsl:copy
/xsl:template
and it all works. Is my fix correct? If so, should I create a patch
and/or Jira ticket?'
Yep, creating issue in JIRA is the best option. If you attach a patch, could you please provide a
more detailed explanation why you need match=* here? I'm not sure if I understand your problem
correctly.
Also, the booleanfield no longer works the way it used to in 2.1.
Namely, I used to be able to do this:
if (widget.value == 'false')
{
// Do something.
}
Now, it is returning a Boolean object (maybe it always did, I don't
know) and I now have to do this:
if (widget.value.toString().equals('false'))
Any thoughts? Is it a good idea to return a string instead?
Returning a String is not a good idea for several reasons (e.g. API change). I guess that the
changed behavior may come from the upgraded Rhino version.
Have you tried:
if (widget.value == false)
?
Finally, my previous post (BTW, sorry for all the emails) mentioned
javascript files that are missing/in the wrong spot. I had a look at the
logs and these files are still being requested, but they are not
impacting on the rendering of the page. However, for the life of me, I
cannot find the references to these files on my page.
Are you sure that request for these files are coming from browser and not from
a block?
Also, I know we have an ongoing issue with tabs and validation errors
not working. I was wondering about the rationale for not using
bu:replace on the appropriate divs to fix these issues?
Can you elaborate here?
--
Grzegorz Kossakowski
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2.2] Missing files for Ajax and CForms
Kamal pisze: Kamal wrote: Hi, I was trying to use Cocoon, but I had the following files come up as missing: http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/i18n/manifest.js http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/i18n.js http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/dojo/__package__.js Now, some of these files do exist in the cocoon-ajax-impl jar file, but no pipeline exists to access them (for example, the manifest.js files). Any thoughts as to why the pipelines don't exist? Cheers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Nevermind. My bad. I didn't have i18n enabled. Though, I am surprised that it would affect the application in this way. What do you mean by I didn't have i18n enabled? -- Grzegorz Kossakowski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2.2] CForms - div around group and other Cforms issues
xsl:template match=fi:[EMAIL PROTECTED] and count(*) = 1 and not(fi:*)] xsl:apply-templates mode=copy-parent-id/ /xsl:template xsl:template match=fi:group xsl:apply-templates/ /xsl:template xsl:template match=fi:group mode=copy-parent-id xsl:copy xsl:attribute name=idxsl:value-of select=../@id//xsl:attribute xsl:copy-of select=@*/ xsl:apply-templates/ /xsl:copy /xsl:template I changed it to this: !--+ | fi:group - has no visual representation by default | If the fi:group contains an id and has only one child that is not in the fi: namespace, | then copy the id to the child. This is needed for ajax when grouping is just used to group | widgets. +-- xsl:template match=fi:[EMAIL PROTECTED] and count(*) = 1 and not(fi:*)] xsl:apply-templates mode=copy-parent-id/ /xsl:template xsl:template match=fi:group xsl:apply-templates/ /xsl:template *xsl:template match=* mode=copy-parent-id *xsl:copy xsl:attribute name=idxsl:value-of select=../@id//xsl:attribute xsl:copy-of select=@*/ xsl:apply-templates/ /xsl:copy /xsl:template and it all works. Is my fix correct? If so, should I create a patch and/or Jira ticket?' Yep, creating issue in JIRA is the best option. If you attach a patch, could you please provide a more detailed explanation why you need match=* here? I'm not sure if I understand your problem correctly. I put the patch in: https://issues.apache.org/jira/browse/COCOON-2204, However, as I mention in the issue, this has been registered previously, and probably one of our issues should be closed (considering the advice given above, I am thinking the other issue needs to be closed). Now, because of the nature of the bug and the previous JIRA issue, I am not certain if I have correctly diagnosed the problem. Now the JIRA issue is up, hopefully, someone can confirm. Returning a String is not a good idea for several reasons (e.g. API change). You are probably right. Have you tried: if (widget.value == false) Hmmm... Thanks, that worked. Trust me to choose the most convoluted solution first :) I guess the question is this a Rhino bug? My inclination is yes, because in the browser if (widget.value == 'false') should work, right? Are you sure that request for these files are coming from browser and not from a block? Yes, because firebug tells me they are (or aren't). Actually, after I put the i18n transformer in (that is what I meant by enabling i18n), they have changed: http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/fi/manifest.js http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/fi.js http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/dojo/__package__.js Now, as you may know, I am not following the rules regarding blocks (ie I am using mounts, see previous posts), so I am more than willing to accept responsibility for this. FYI, I cannot see any discernable functional issue with them not being there. Also, I know we have an ongoing issue with tabs and validation errors not working. I was wondering about the rationale for not using bu:replace on the appropriate divs to fix these issues? Can you elaborate here? In non-ajax mode, if you have a validation error on a particular tab, the tab will have a little icon indicating a validation error. This icon does not appear in ajax mode because (from my understanding) it is not wrapped in an appropriate bu:replace tag. Similarly for validation-errors. I have discussed this previously[1] (as have others [2]), and the issue remains unresolved [3]. I might add, that in [1] I came up with a really dodgy hack to get around this problem, but I am assuming that hack would have been univerally frowned upon (basically, I turned off ajax for submisson). I guess a less dodgy solution (hack?) is to put bu:replace tags into those divs, but I no one seems to have done this, so I am assuming it is frowned upon. I want clarification as why. [1] http://www.nabble.com/Tabs-and-CForms-td13222772.html [2] http://marc.info/?l=xml-cocoon-devm=117269621604981w=2 [3] https://issues.apache.org/jira/browse/COCOON-1570 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2.2] Dynamically generating XML tags in JXTemplates
Grzegorz Kossakowski wrote: Kamal pisze: Hi, I was wondering if there were any way (aside from jx:out) to generate XML tags dynamically in JXTemplates? Basically, I want to the element name to be dynamically generated. I know that there is a jx:attribute, but there doesn't seem to be a jx:element. Is there any (easy) way of making JXTemplates work in this way? I remember that there was some (good) reason to not have this feature in JX template but I fail to find an e-mail in archives right now. Do you remember if those reasons related to JXTemplates architecture or a was there a case of stopping the user from doing this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2.2] Dynamically generating XML tags in JXTemplates
Kamal pisze: I remember that there was some (good) reason to not have this feature in JX template but I fail to find an e-mail in archives right now. Do you remember if those reasons related to JXTemplates architecture or a was there a case of stopping the user from doing this? I remember reading something about problems with SAX nature of JXTemplates but I remember it was an old discussion so it may not be relevant anymore. -- Grzegorz Kossakowski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Processing dynamically-created forms
Derek Hohls pisze: Can anyone help with this?! - I am sure its a simple syntax issue... On 2008/04/21 at 12:40, in message [EMAIL PROTECTED], Derek Hohls [EMAIL PROTECTED] wrote: Gregorz Unfortunately, when I try: var it = model.children; it has an undefined (null) result, not an iterator. I also tried: var it = myform.getChildren(); but without success. Any ideas how to get this to work? I have tried this in different flowscripts for different forms; all have the same problem. Hi Derek, Thanks for reminding me. I'm just developing some Forms so I'll try my suggestion and see why it's not working. Stay tuned. -- Best regards, Grzegorz Kossakowski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2.2] CForms - div around group and other Cforms issues
Grzegorz Kossakowski wrote: Kamal pisze: I put the patch in: https://issues.apache.org/jira/browse/COCOON-2204, However, as I mention in the issue, this has been registered previously, and probably one of our issues should be closed (considering the advice given above, I am thinking the other issue needs to be closed). Now, because of the nature of the bug and the previous JIRA issue, I am not certain if I have correctly diagnosed the problem. Now the JIRA issue is up, hopefully, someone can confirm. I'll try to have a look. if (widget.value == false) Hmmm... Thanks, that worked. Trust me to choose the most convoluted solution first :) I guess the question is this a Rhino bug? My inclination is yes, because in the browser if (widget.value == 'false') should work, right? I'm not a Javascript expert but I guess you are right that it may be a Rhino bug. Reporting this to Rhino folks wouldn't hurt. Yes, because firebug tells me they are (or aren't). Actually, after I put the i18n transformer in (that is what I meant by enabling i18n), they have changed: http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/fi/manifest.js http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/fi.js http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/dojo/__package__.js Now, as you may know, I am not following the rules regarding blocks (ie I am using mounts, see previous posts), so I am more than willing to accept responsibility for this. FYI, I cannot see any discernable functional issue with them not being there. Before we start to dig into issue I would like to ask you if you have followed this instructions: http://cocoon.apache.org/2.2/blocks/forms/1.0/1351_1_1.html Actually, there is one thing at the end of that that I may not have done (the servletLinkWriter transformer). When I am less tired. I will have a look. Thanks. Also, I know we have an ongoing issue with tabs and validation errors not working. I was wondering about the rationale for not using bu:replace on the appropriate divs to fix these issues? Can you elaborate here? In non-ajax mode, if you have a validation error on a particular tab, the tab will have a little icon indicating a validation error. This icon does not appear in ajax mode because (from my understanding) it is not wrapped in an appropriate bu:replace tag. Similarly for validation-errors. I have discussed this previously[1] (as have others [2]), and the issue remains unresolved [3]. I might add, that in [1] I came up with a really dodgy hack to get around this problem, but I am assuming that hack would have been univerally frowned upon (basically, I turned off ajax for submisson). I guess a less dodgy solution (hack?) is to put bu:replace tags into those divs, but I no one seems to have done this, so I am assuming it is frowned upon. I want clarification as why. Ah, I see. The problem in its core is that bu:replace tags are being generated by JX macros for Forms and fi:validation-errors are handled by XSLs. If you are in AJAX mode, everything that is outside bu:replace tags is being stripped of so XSLs won't handle them. The same goes for validation errors on particular tab. I'm not sure what should be the best solution but since I'll be playing with Forms quite heavily these days I'll think about this problem too. Right now, for the validation-errors, I am hard coding the bu:replace. Also, what generates the bu:replace tags for all the widgets? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2.2] CForms - div around group and other Cforms issues
Kamal wrote: Grzegorz Kossakowski wrote: Kamal pisze: I put the patch in: https://issues.apache.org/jira/browse/COCOON-2204, However, as I mention in the issue, this has been registered previously, and probably one of our issues should be closed (considering the advice given above, I am thinking the other issue needs to be closed). Now, because of the nature of the bug and the previous JIRA issue, I am not certain if I have correctly diagnosed the problem. Now the JIRA issue is up, hopefully, someone can confirm. I'll try to have a look. if (widget.value == false) Hmmm... Thanks, that worked. Trust me to choose the most convoluted solution first :) I guess the question is this a Rhino bug? My inclination is yes, because in the browser if (widget.value == 'false') should work, right? I'm not a Javascript expert but I guess you are right that it may be a Rhino bug. Reporting this to Rhino folks wouldn't hurt. Yes, because firebug tells me they are (or aren't). Actually, after I put the i18n transformer in (that is what I meant by enabling i18n), they have changed: http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/fi/manifest.js http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/fi.js http://localhost/apps/ccn/cocoon-ajax-impl/resource/external/dojo/__package__.js Now, as you may know, I am not following the rules regarding blocks (ie I am using mounts, see previous posts), so I am more than willing to accept responsibility for this. FYI, I cannot see any discernable functional issue with them not being there. Before we start to dig into issue I would like to ask you if you have followed this instructions: http://cocoon.apache.org/2.2/blocks/forms/1.0/1351_1_1.html Actually, there is one thing at the end of that that I may not have done (the servletLinkWriter transformer). When I am less tired. I will have a look. Thanks. OK, I tried this. The issue still persist. Also, I might add, there seems to be small contradiction the page you mention and this page: http://cocoon.apache.org/2.2/blocks/forms/1.0/750_1_1.html . Namely, there is no mention of the servletLinkRewriter or the far more complex serialisation step. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Avoiding OutOfMemory Errors by limiting data in pipeline
On 24.04.2008 16:08, Bruce Atherton wrote: Thanks for the response. About setting the buffer size, this looks like it could be what I am looking for. A few questions: 1. Do I have to set the buffer size on each transformer and the serializer as well as the generator? What about setting it on the pipeline? It is on the pipeline and only there. You can set it on the map:pipe element in the map:components section, so that it is applied to each pipeline of that type. Or on any individual map:pipeline element in the map:pipelines section. 2. Does the full amount of the buffer automatically get allocated for each request, or does it grow gradually based on the xml stream size? I have a lot of steps in the pipeline, so I am worried about the impact of creating too many buffers even if they are relatively small. A 1 Meg buffer might be too much if it is created for every element of every pipeline for every request. That's a very good question - with a negative answer: A buffer of that particular size is created initially. That's why I want to bring this issue up on dev again: With my changes for COCOON-2168 [1] it's now not only a problem for applications with over-sized downloads but potentially for everyone relying on Cocoon's default configuration. One idea would be to change our BufferedOutputStream implementation to take 2 parameters: one for the initial buffer size and one for the flush size. The flush treshold would be the configurable outputBufferSize, the initial buffer size does not need to be configurable I think. What do other think? On an unrelated note, is there some way to configure caching so that nothing is cached that is larger than a certain size? I'm worried that this might be a caching issue rather than a buffer issue. Not that I'm aware of. Why do you think it's caching? Caching is at least configurable in terms of number of cache entries and I also think in terms of max cache size. But beyond a certain cache size the cache entries are written to disk anyway so it's unlikely resulting in a memory issue. How do you read the object graph from the heap dump? To tell you the truth, I'm not sure. This is the hierarchy generated by the Heap Analyzer tool from IBM, and is from a heap dump on an AIX box running the IBM JRE. My guess as to the Object referencing the ComponentsSelector is that the ArrayList is not generified, so the analyzer doesn't know the actual type of the Object being referenced. What the object actually is would depend on what CachingProcessorPipeline put into the ArrayList. That is just a guess, though. And I have no explanation for the link between FOM_Cocoon$CallContext and ConcreteCallProcessor. Perhaps things were different in the 2.1.9 release? No serious changes since 2.1.9 which is rev 392241 [2]. Joerg [1] https://issues.apache.org/jira/browse/COCOON-2168 [2] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_Cocoon.java?view=log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem after trunk update
On 25.04.2008 07:33, Robin Rigby wrote: Updated trunk. Rebuild OK. Then mvn jetty:run gives this first ERROR [main] (ContextLoader.java:214) - Context initialization failed org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from ServletContext resource [/WEB-INF/applicationContext.xml]; nested exception is java.lang.VerifyError: (class: org/apache/cocoon/generation/ServerPagesGenerator, method: generate signature: ()V) Incompatible object argument for function call Just a guess: Something in the ServerPagesGenerator has changed and it is not binary compatible. The hierarchy is now inconsistent if not everything has been recompiled. Does mvn clean install fix this? Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HELP] SitemapEvenListener
On 23.04.2008 05:48, Patrick Heiden wrote: Still no ideas/solutions to share (Jörg?). I can't hide, can I? ;) A have read [1] and assume that one of your aforementioned colleagues is Jörg Heinicke ( maybe you have a solution meanwhile, Jörg? Especially: How are you able to use declarative transaction demarciation within this jungle? ;) ) Declarative transaction demarcation indeed used to work nicely for me. But I have never tried it in the context of Cocoon. And it's now a year ago that I worked with that stuff the last time. You need at least to elaborate a bit more. Maybe I'm still able to help you :) Joerg [1] http://forum.springframework.org/showthread.php?t=32270page=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2.1]change response http status
On 16.04.2008 07:24, nanomonk wrote: Hmm.. no, I need to set status code according to some events during executing my own serializer, for example: if all ok done - status code 1, some error - 2, another error - 3... so, can I to access to Response object from serializer(exactly via response.setStatus(1) in a code)? if not - maybe another true-way is exist? Isn't the serializer rather late for such logic? Can you determine this value beforehands, e.g. in an Action? Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
