bla

Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <247940612.1141821460802.JavaMail.jira@ajax>
Date: Wed, 8 Mar 2006 12:37:40 +0000 (GMT)
From: "Max Pfingsthorn (JIRA)" <jira@apache.org>
To: dev@cocoon.apache.org
Subject: [jira] Commented: (COCOON-1794) [PATCH] Propagation of namespaces
 to a repeaters child bindings and implementation of a move-node binding
In-Reply-To: <591369629.1141731878807.JavaMail.jira@ajax>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/COCOON-1794?page=comments#action_12369434 ] 

Max Pfingsthorn commented on COCOON-1794:
-----------------------------------------

Okay, fine. They only thing I would like to accomplish, and which is important to VNU and Hippo as well, is that this repeater would work without an enclosing element for the rows. This is currently not the case, and this is also not fixed by your patch. Actually, your patch will make it worse as you assume that the parent element will only have the repeater's rows as children. If you just move a row element after the ith element of the parent, bad things can happen (in terms of document validity).

Our concern is to have a schema validateable output from cforms. This includes namespaces and element ordering, especially with repeaters without their own parent element. Imagine something like this:

<doc>
   <meta>
     <title>bla</title>
    </meta>
    <content>
       <p>some paragraph</p>
    </content>
    <content>
       <p>some other paragraph</p>
    </content>
    <link></link>
    <link></link>
</doc>

For the content and link elements, we want to use a repeater and not have contents after links in the output, which does happen now. I've been thinking about it myself, and your patch just seemed like a good idea to discuss a little.

Actually, now, the only thing that we have to do to fix this is to make an InsertAfterNodeJXPathBinding, and in the loop where new rows get inserted, use that one which takes the previous row's node and inserts a node after that one. This way, we will keep everything neatly aligned and no moving is necessary, right?

> [PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding
> ---------------------------------------------------------------------------------------------------------
>
>          Key: COCOON-1794
>          URL: http://issues.apache.org/jira/browse/COCOON-1794
>      Project: Cocoon
>         Type: Bug
>   Components: Blocks: Forms
>     Versions: 2.1.8, 2.1.9-dev (current SVN)
>     Reporter: Suzan Foster
>  Attachments: repeater-binding-patch.txt
>
> This patch corrects the following issues:
> - Namespaced back-end XML model not correctly binding to the repeaters child widgets.
> - Nodes bound to row widgets not being reordered according to row position on save.
> Files affected:
> - JXPathBindingBase:
>   - member applyLeniency changed from private to protected.
>   - member applyNSDeclarations changed from private to protected.
> - RepeaterJXPathBinding:
>   - constructor changed for passing a binding for moveRow.
>   - applyLeniency and applyNSDeclarations applied to created relative contexts.
>   - member moveRowBinding added.
>   - method getMoveRowBinding added.
>   - doSave changed to incorporate the use of moveRowBinding.
> - RepeaterJXPathBindingBuilder:
>   - buildBinding changed to incorporate the construction of moveRowBinding.
> Files added:
> - MoveNodeJXPathBinding.
> - MoveNodeJXPathBindingBuilder.

-- 
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