Re: reworking CForms Repeater
Hi Jeremy,
I'll try to give some feedback from my side. I am a heavy CForms user with
50+ forms mainly handling hibernate objects.
Jeremy Quinn wrote:
>
>
> The Dojo DnD libraries have more capabilities than are currently
> supported in CForms. I am trying to work out which are realistic to
> implement here.
>
> 1. move more than one row at the same time within a single Repeater
> 2. clone row(s) within a single Repeater
> 3. move row(s) from one Repeater to another
> 4. clone row(s) from one Repeater to another
>
>
>
>
In general the cloning option would be really a nice feature where I can
think of some usecases in our apps. We are using repeaters quite often and
it would indeed be nice to be able to clone an existing row. [Allthough I am
pretty sure you can do it with a custom CForms Action on the serverside by
creating a new Row and adding the content by hand.]
Jeremy Quinn wrote:
>
>
> The immediate problem I am facing is twofold :
>
> 1. We are adding rows, so the User's 'add-row' handler should probably
> get the opportunity to run. It currently does not, so in the example
> (based on: samples/blocks/forms/do-dojoRepeater.flow) the cloned
> row(s) do not get a new unique ID.
>
> How do I ensure User handlers get executed?
>
> 2. All of the samples of 'add-row' handlers I see make the assumption
> that the row that has just been added, has been added at the end of
> the Repeater, eg.
>
> repeater.getRow(repeater.getSize() - 1).getChild("ID").setValue(count);
>
> Now we are using DnD, this assumption is no longer true, there may be
> more than one new row and they may not be at the end.
>
> Should or do we have a way to find out what was added, from within a
> User handler?
>
> Will this type of cloning cause problems further down the line, when
> for instance it is used to edit a Repeater that represents a
> Collection of Beans persisted via ORM (etc.)?
>
> ...
>
>
As you already stated it is absolutely necessary that in case of ORM binds
being binded that new rows get a NULL identifier. That means that the widget
which is declared in the section of the corresponging binding-xml
file does not get the value of the repeater-row, from where it was copied.
In hibernate for instance these rows (with null identifier-widgets) would be
then saved as new objects to the database (if binding was done right).
In general I would prefer a solution which supports the old behavior and
events if possible.
Regards,
Gabriel
--
View this message in context:
http://www.nabble.com/reworking-CForms-Repeater-tp17489343p17552351.html
Sent from the Cocoon - Dev mailing list archive at Nabble.com.
[jira] Commented: (COCOON-2207) Validatiion errors not working in ajax
[ https://issues.apache.org/jira/browse/COCOON-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600950#action_12600950 ] Kamal Bhatt commented on COCOON-2207: - Sorry, never submitted on a widget (I used the submit). I did this a long time ago, and maybe someone put a patch through that changed the functionality. What I recommend is that you turn of Ajax, work out what the save widget calls, then replicate it. That is how I worked out how to turn off ajax. I suspect it isn't going to be forms_onsubmit(). Be aware that whatever you do here is not going to work if you upgrade to 2.1.11 as they have changed how Cocoon submits. I have a sneaking suspicion that (intentionally or otherwise) someone has made this sort of hack near impossible using the standard dojo set. Also, you should probably continue this discussion on the mailing list as it this conversation doesn't belong on an issue. > Validatiion errors not working in ajax > -- > > Key: COCOON-2207 > URL: https://issues.apache.org/jira/browse/COCOON-2207 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.10 >Reporter: Mohammed Aashik > > Hi, > Im using Cocoon 2.1.10. I've implemented ajax in my form. > My form has plenty of widgets. So,i need to have a general area to show all > the validation error messages. > When im using ajax , is NOT working but when i make > ajax="false" > is working fine. > And one more thing if i make ajax="false" a validation error Message > (Exclamation mark) is shown near the tab, > but if i make ajax="true" validation error Message (Exclamation mark) is NOT > shown near the tab. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Little announcement and ask for a help
Grzegorz Kossakowski pisze: Hi guys, I've been rather inactive these days mainly busy with personal affairs but also with Cocoon 2.2 demo application coding. The thing is hosted on github, project called cocoon-blog[1]. The project status should be considered as highly unstable. There is quite a lot of interesting functionality already implemented like DAOs in JS, jDBI (2.0.x) integration, configuration of HSQL, dirtylicious theme, etc. but all these pieces are not integrated with each other yet. At the moment, I'm facing some annoying problem that effectively stops me from developing further given my (very) limited resources these days. The problem is with debugging blocks in Eclipse. I'm using run-jetty-run plugin[2] for running blocks inside Eclipse. In the past this technique worked very well together with eclipse:eclipse plug-in that allowed me to import block into Eclipse's workspace. Normally, following steps should work: (assuming run-jetty-run is installed): 1. Go to block (e.g. dirtylicious-theme) 2. Run mvn clean cocoon:prepare 2. Run mvn eclipse:eclipse 3. Import block into workspace 4. Create Debug configuration of "Jetty Webapp" type. As webapp dir property value set "target/rcl/webapp". 5. Run debugging of block. As I said, this worked very well in the past but for some unknown reason I'm facing lots of classpath issues. The latest is: Caused by: java.lang.NoClassDefFoundError: org/apache/excalibur/source/SourceValidity I've checked dirtylicious-theme block imported to Eclipse and there is no sourceresolve dependency created by eclipse:eclipse but dependency:list shows it. I would like to ask other folks for a help with confirming if it's a common problem and maybe finding some solution to this problem. Of course, I could figure out all missing dependencies and add them by hand but we use Maven for some reason, do we? So go to http://github.com/gkossakowski/cocoon-blog/tree/master, click on Download button and test my steps please. I will be very grateful for any feedback. I forgot to add that in order to compile cocoon-blog you need to have a build of up-to-date Cocoon trunk. See this README for more details: http://github.com/gkossakowski/cocoon-blog/tree/master/README -- Best regards, Grzegorz Kossakowski
Re: [VOTE] Drop JDK1.3 support for Cocoon 2.1.11 and newer versions
Jeroen Reijn pisze: Hi all, I recently ran across problems while trying to upload cocoon 2.1.11 jars to the maven1 repository[1]. Building Cocoon with JDK 1.3 failed due to multiple errors. Therefor I would like to suggest setting the minimum JDK to 1.4 for cocoon 2.1.11 and newer versions. A bit more then a year ago we had the same vote for 2.1.10. See [2] for more info. We decided then that we should release 2.1.10 as soon as possible and move on to Cocoon 2.2 where we already had a higher JDK version as a minimum. I think it's a good idea to do a revote, since there might even be a 2.1.12. Please cast your votes! +1 -- Grzegorz Kossakowski
Re: [VOTE] Drop JDK1.3 support for Cocoon 2.1.11 and newer versions
On Wed, 2008-05-28 at 09:03 +0200, Jeroen Reijn wrote: > Please cast your votes! +1 Cheers, Alfred.
[jira] Commented: (COCOON-2207) Validatiion errors not working in ajax
[
https://issues.apache.org/jira/browse/COCOON-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600758#action_12600758
]
Mohammed Aashik commented on COCOON-2207:
-
Hi,
First of all ,Thanks for your reply.
I've some ajax based repeaters in my form.
As u said ,i've added below code in forms-styling.xsl
function turnOffAjax()
{
var frm = document.getElementById("form1");
frm.setAttribute("onsubmit", "forms_onsubmit();");
frm.setAttribute("ajax", "false");
cocoon.forms.ajax = false;
}
My Form Template is look this
After including the above script ,we found that the existing Repeater
functionality throwed an error,which is shown below
java.lang.IllegalStateException: Submit widget already set to Submit
Thanks in Advance.
Regards,
Mohammed Aashik.
> Validatiion errors not working in ajax
> --
>
> Key: COCOON-2207
> URL: https://issues.apache.org/jira/browse/COCOON-2207
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
>Affects Versions: 2.1.10
>Reporter: Mohammed Aashik
>
> Hi,
> Im using Cocoon 2.1.10. I've implemented ajax in my form.
> My form has plenty of widgets. So,i need to have a general area to show all
> the validation error messages.
> When im using ajax , is NOT working but when i make
> ajax="false"
> is working fine.
> And one more thing if i make ajax="false" a validation error Message
> (Exclamation mark) is shown near the tab,
> but if i make ajax="true" validation error Message (Exclamation mark) is NOT
> shown near the tab.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2075) BrowserUpdateTransformer corrupts content from template using a default namespace
[ https://issues.apache.org/jira/browse/COCOON-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Savory closed COCOON-2075. - Resolution: Fixed Closed after discussion with Ellis. May need to be re-opened if others hit this... > BrowserUpdateTransformer corrupts content from template using a default > namespace > - > > Key: COCOON-2075 > URL: https://issues.apache.org/jira/browse/COCOON-2075 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Ajax >Affects Versions: 2.1.10, 2.1.11, 2.2 >Reporter: Ellis Pritchard > Attachments: browser-update.xsl > > > The org.apache.cocoon.ajax.BrowseUpdateTransformer does not pass on > startPrefixMapping()/endPrefixMapping() in an ajaxRequest when not in a > bu:replace; however this may mean that a namespace declared on an ancestor > element of a bu:replace never gets declared in the output despite its use > inside the bu:replace, and results in weird output behaviour after further > processing, e.g. missing element names. > This problem seems to manifest itself only when using elements declared in > the default namespace, e.g. if I wrap the whole form in a div with a default > namespace declaration for xhtml: > http://www.w3.org/1999/xhtml/"; > xmlns:ft="http://apache.org/cocoon/forms/1.0#template"; > xmlns:fi="http://apache.org/cocoon/forms/1.0#instance"; > xmlns:jx="http://apache.org/cocoon/templates/jx/1.0";> > > > > > The div and span elements will not be output correctly after further > processing (empty element name) e.g.: > < > > < class="x"> > You need to insert at least an identity XSL transform after the > browser-update transformer to see this; a cocoon-view label doing a serialize > to XML on the transformer itself does not seem to be enough; presumably it is > the XSL processor that's going wrong when processing the corrupt output of > the transformer, not the browser-update transformer itself. > The NamespacesTable used by the transformer declares the empty namespace > (prefix="",ns="") itself, so html markup with no-namespace declaration (as in > the forms-styling XSL) will work, but correct use an element in a default > namespace will not work. > Adding default namespace declarations on the XHTML or the ft: elements > themselves does not work (not being passed through somehow: jx/jx-macro > problem?), however declaring a prefix for those elements does work, despite > the mappings not being declared, which I presume is some kind of XML-legacy > side-effect, outputting the effected tags with their prefix and local-name > intact, although this might still produce problems. > In summary, elements declared in a default (uri but no-prefix) namespace are > mangled by the transformer/pipeline because the namespace prefix is not > declared. The lack of declaration may also be a general problem, depending on > how your template file is marked up. > The fix is to remove the conditional from the startPrefixMapping() and > endPrefixMapping() methods of BrowserUpdateTransformer, to allow all prefix > declarations to reach the NamespaceTable, and allow it to do the > optimization/de-duping work. I can't see that this could have any bad > effects, since the NamespaceTable/RedundantNamespacesFilter is designed to > handle all the namespace issues, which is why it is there in the first place. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1985) AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline
[ https://issues.apache.org/jira/browse/COCOON-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Savory closed COCOON-1985. - Resolution: Fixed Closed after discussion with Ellis. > AbstractCachingProcessingPipeline locking with IncludeTransformer may hang > pipeline > --- > > Key: COCOON-1985 > URL: https://issues.apache.org/jira/browse/COCOON-1985 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.9, 2.1.10, 2.1.11, 2.2 >Reporter: Ellis Pritchard >Priority: Critical > Fix For: 2.1.12-dev (Current SVN), 2.2 > > Attachments: caching-trials.patch, includer.xsl, patch.txt, > reproduceMultipleThreads.tar.gz, sitemap.xmap > > > Cocoon 2.1.9 introduced the concept of a lock in > AbstractCachingProcessingPipeline, an optimization to prevent two concurrent > requests from generating the same cached content. The first request adds the > pipeline key to the transient cache to 'lock' the cache entry for that > pipeline, subsequent concurrent requests wait for the first request to cache > the content (by Object.lock()ing the pipeline key entry) before proceeding, > and can then use the newly cached content. > However, this has introduced an incompatibility with the IncludeTransformer: > if the inclusions access the same yet-to-be-cached content as the root > pipeline, the whole assembly hangs, since a lock will be made on a lock > already held by the same thread, and which cannot be satisfied. > e.g. > i) Root pipeline generates using sub-pipeline cocoon:/foo.xml > ii) the cocoon:/foo.xml sub-pipeline adds it's pipeline key to the transient > store as a lock. > iii) subsequently in the root pipeline, the IncludeTransformer is run. > iv) one of the inclusions also generates with cocoon:/foo.xml, this > sub-pipeline locks in AbstractProcessingPipeline.waitForLock() because the > sub-pipeline key is already present. > v) deadlock. > I've found a (partial, see below) solution for this: instead of a plain > Object being added to the transient store as the lock object, the > Thread.currentThread() is added; when waitForLock() is called, if the lock > object exists, it checks that it is not the same thread before attempting to > lock it; if it is the same thread, then waitForLock() returns success, which > allows generation to proceed. You loose the efficiency of generating the > cache only once in this case, but at least it doesn't hang! With JDK1.5 this > can be made neater by using Thread#holdsLock() instead of adding the thread > object itself to the transient store. > See patch file. > However, even with this fix, parallel includes (when enabled) may still hang, > because they pass the not-the-same-thread test, but fail because the root > pipeline, which holds the initial lock, cannot complete (and therefore > statisfy the lock condition for the parallel threads), before the threads > themselves have completed, which then results in a deadlock again. > The complete solution is probably to avoid locking if the lock is held by the > same top-level Request, but that requires more knowledge of Cocoon's > processing than I (currently) have! > IMHO unless a complete solution is found to this, then this optimization > should be removed completely, or else made optional by configuration, since > it renders the IncludeTransformer dangerous. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1884) [Link] Encyclopedia of Life Sciences (Wiley InterScience)
[ https://issues.apache.org/jira/browse/COCOON-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Savory closed COCOON-1884. - Resolution: Fixed Added to Daisy. > [Link] Encyclopedia of Life Sciences (Wiley InterScience) > - > > Key: COCOON-1884 > URL: https://issues.apache.org/jira/browse/COCOON-1884 > Project: Cocoon > Issue Type: Improvement > Components: - Documentation >Affects Versions: 2.1.8 >Reporter: Ellis Pritchard > > URL of the website: http://www.mrw.interscience.wiley.com/emrw/047001590X/home > Title of the website: Encyclopedia of Life Sciences - Wiley InterScience > Cocoon version used: 2.1.8 (with AJAX module and some patches from 2.1.9) > Short summary: Major Reference work in Wiley InterScience, first of many to > be published using Cocoon-based architecture. > How can we verify this site is actually built with Cocoon? Check out the > X-Cocoon-Version header... > - How much time did it take to build the site from design to publication? > Original IA Specification in October 2005, specs for source XML took > approximately 2 months, actual build 3 months; 3 Cocoon-based engineers, 1 > focusing on search, 1 on XHTML/CSS, and one on the rest of the site. We also > had some hard-working Content people working on pre-rendering of XML blobs > and MathML images, and a whole bunch of people in India marking up the XML > content documents. > - How much traffic does the site handle? > 2 hits on launch day (24 July 2006). > - What made you choose Cocoon to build the site? > 6 month review of available technologies, Cocoon stood out on handling of > XML, Caching, Component re-use and the Sitemap. We also love Views and the > concept of Flows. > - What other information do you want to disclose (e.g. how does it work, how > did > you build it, what parts of Cocoon did you use)? > We've actually got some other parts of the site already implemented using > Cocoon, namely ForwardLinking (Citation-Tracking link on Journal Abstract > pages: Crossref web-service based), Author Services (production process > tracking for authors: uses web-services and FlowScript), plus our (yet to be > launched) RSS and OPML feeds, and will be moving forward with the rest of > InterScience along-side a back-end re-architecture. > We've been able to re-use a number of components from the other Cocoon > projects already, and the bulk of Cocoon work for this site has been XSL and > Sitemap wrangling, rather than application-specific Java code. > We wrote our own Generators and Transformers for DB access and Search > integration (we use back-end CORBA repositories and custom DOA for DB access, > and a legacy Verity engine for search), plus some generic transformers for > SAX manipulation, e.g. pulling single nodes for our AJAX based topic-tree out > of a huge source document. However, the bulk of the functionality is XSLT > based, using a file-system store (i.e. exactly the kind of thing Cocoon was > designed for), preferring Inclusion to Aggregation in most cases. > Access control is not implemented using Cocoon simply due to an existing > available web-server plugin, although we use a Cocoon-based 'Action' for > access control in other parts of the site. > Cocoon has vastly improved our abilty to deliver feature-rich sites on-time > and on-cost, plus, its fun! > - Can you provide a contact email address if people want further information? > [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JIRA karma
Hi Kamal, 2008/5/29 Kamal <[EMAIL PROTECTED]>: > I don't think the laws of Karma apply to JIRA (at least not last time I > looked). Not too sure if this is the mailing list for such metaphysical > discussions. "Karma" is ASF-speak for being granted permission to do something. > What do you qualify as "useful stuff"? Have you got a JIRA login? In this case, useful stuff is being able to edit or close issues. Thanks Carsten for fixing it. Andrew. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] http://www.andrewsavory.com/
Re: JIRA karma
This should work now. Carsten Andrew Savory wrote: Hi, I don't appear to have sufficient karma to do useful stuff on Cocoon's JIRA. Could someone point me in the direction of how to add myself, and/or add me? Thanks, Andrew, thwarted at the first step of a bug squashing session. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] http://www.andrewsavory.com/ -- Carsten Ziegeler [EMAIL PROTECTED]
Re: JIRA karma
I don't think the laws of Karma apply to JIRA (at least not last time I looked). Not too sure if this is the mailing list for such metaphysical discussions. What do you qualify as "useful stuff"? Have you got a JIRA login? Hi, I don't appear to have sufficient karma to do useful stuff on Cocoon's JIRA. Could someone point me in the direction of how to add myself, and/or add me? Thanks, Andrew, thwarted at the first step of a bug squashing session. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] http://www.andrewsavory.com/
JIRA karma
Hi, I don't appear to have sufficient karma to do useful stuff on Cocoon's JIRA. Could someone point me in the direction of how to add myself, and/or add me? Thanks, Andrew, thwarted at the first step of a bug squashing session. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] http://www.andrewsavory.com/
[jira] Commented: (COCOON-2207) Validatiion errors not working in ajax
[ https://issues.apache.org/jira/browse/COCOON-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600720#action_12600720 ] Kamal Bhatt commented on COCOON-2207: - Bad news, fi:validation-errors is busted in a non-ajax environment. See this issue: https://issues.apache.org/jira/browse/COCOON-1570 Don't expect anyone to fix this problem any time soon. Good news, you are using Cocoon 2.1.10 so it is easy enough to turn off validation on submission. See this post: http://java2.5341.com/msg/228810.html This ticket should probably closed as it is a duplicate. > Validatiion errors not working in ajax > -- > > Key: COCOON-2207 > URL: https://issues.apache.org/jira/browse/COCOON-2207 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.10 >Reporter: Mohammed Aashik > > Hi, > Im using Cocoon 2.1.10. I've implemented ajax in my form. > My form has plenty of widgets. So,i need to have a general area to show all > the validation error messages. > When im using ajax , is NOT working but when i make > ajax="false" > is working fine. > And one more thing if i make ajax="false" a validation error Message > (Exclamation mark) is shown near the tab, > but if i make ajax="true" validation error Message (Exclamation mark) is NOT > shown near the tab. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Drop JDK1.3 support for Cocoon 2.1.11 and newer versions
Felix Knecht wrote: Please cast your votes! +1 Felix +1 -- Kamal Bhatt
[jira] Created: (COCOON-2207) Validatiion errors not working in ajax
Validatiion errors not working in ajax -- Key: COCOON-2207 URL: https://issues.apache.org/jira/browse/COCOON-2207 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.10 Reporter: Mohammed Aashik Hi, Im using Cocoon 2.1.10. I've implemented ajax in my form. My form has plenty of widgets. So,i need to have a general area to show all the validation error messages. When im using ajax , is NOT working but when i make ajax="false" is working fine. And one more thing if i make ajax="false" a validation error Message (Exclamation mark) is shown near the tab, but if i make ajax="true" validation error Message (Exclamation mark) is NOT shown near the tab. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
