Hi Sylvain,

I just downloaded a snapshot of CVS  a few days ago (post 2.1.7 release) and
noticed that the InsertRows functionality you had added from my contributed
code is missing in that release... Is there a way to get this permanently
added to the cocoon distribution?

Best Regards,

David Epperly






depub2 wrote:

> David's notes: see below
>
> Sylvain Wallez
> Thu, 24 Feb 2005 09:07:07 -0800
>

> Added. When including your patch, I had a quick look at Excel and
> found that the row insertion command adds rows _before_ the selected
> rows as you initially suggested. So I added it that way. I made a
> small change though by clearing the selection after executing the action.
>
> If you'd like your name to be included for fame and posterity in
> Cocoon's release notes, please give us your full name as "David" is a
> bit unprecise.
>
> I think it would be better to not clear the selections and here's why:
> if there is a need to insert, say 32 empty rows, it is much easier if
> the ones that are already checked remain checked; so the use case
> looks like, check 1, insert; check the new one (old one still
> checked), insert; check 2, insert; check 4, insert; check 8 (old 8
> still checked), insert; done! It is very easy to have some very short
> client-side javascript/buttons that "uncheck-all" or "check-all" (we
> have it in our application), so the need to auto-uncheck is not really
> needed - and in fact for the above use-case, hindering.


Ok, it makes sense. I changed it and the selection is now left untouched.


Best Regards,

--- Begin Message ---
Sylvain, Andrew,

Thanks for your assistance.. It's a lot of work for me to submit this as a
patch.. so attached are the source code files (one is new, one has a very
small change) that should be placed in the directory:
/usr/local/cocoon-2.1.6.cvs0106/src/blocks/forms/java/org/apache/cocoon/form
s/formmodel/

Note that the file that was changed was taken from the 1/6/2005 cvs
snapshot. Please confirm that you've received this message.

Thanks,

David



Hi David,
On 25 Jan 2005, at 01:36, depub2 wrote:
I would like to make a small contribution to the cocoon repeater-widget
(insert row) and would like someone (Sylvain Wallez?) to accept my code; so
I'll be a "ghostwriter" as it does not make sense for me to maintain this
small piece of code.

The best way to contribute this is to submit it as a patch via bugzilla,
then as soon as someone (perhaps Sylvain!) gets a chance, they will be able
to review it and add it to Cocoon.

Information on creating diffs can be found here:
http://cocoon.apache.org/community/ contrib.html#How+to+Generate+Differences


Bugzilla can be found here:
http://issues.apache.org/bugzilla/


Thanks,


Andrew.


--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658  Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/
/*
 * Copyright 1999-2004 The Apache Software Foundation.
 * 
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 * 
 *      http://www.apache.org/licenses/LICENSE-2.0
 * 
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
package org.apache.cocoon.forms.formmodel;

import org.apache.cocoon.forms.event.ActionEvent;
import org.apache.cocoon.forms.event.ActionListener;

/**
 * The definition for a repeater action that inserts rows before the selected 
rows of a sibling repeater.
 * 
 * @author <a href="http://www.apache.org/~sylvain/";>Epp ghostwriter for 
Sylvain Wallez</a>
 * @version CVS $Id: InsertRowsActionDefinition.java,v 1.1 2005/01/25 21:49:23 
depp Exp $
 */
public class InsertRowsActionDefinition extends RepeaterActionDefinition {
    
    private String selectName;
    
    public InsertRowsActionDefinition(String repeaterName, String selectName) {
        super(repeaterName);
        this.selectName = selectName;
        
        this.addActionListener(new ActionListener() {
            public void actionPerformed(ActionEvent event) {
                Repeater repeater = 
((RepeaterAction)event.getSource()).getRepeater();
                for (int i = repeater.getSize() - 1; i >= 0; i--) {
                    Repeater.RepeaterRow row = repeater.getRow(i);
                    if 
(Boolean.TRUE.equals(row.getChild(InsertRowsActionDefinition.this.selectName).getValue()))
 {
                        repeater.addRow(i);
                    }
                }
            }
        });
    }
}
/*
 * Copyright 1999-2004 The Apache Software Foundation.
 * 
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 * 
 *      http://www.apache.org/licenses/LICENSE-2.0
 * 
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
package org.apache.cocoon.forms.formmodel;

import java.util.Iterator;

import org.apache.cocoon.forms.event.ActionListener;
import org.apache.cocoon.forms.util.DomHelper;
import org.w3c.dom.Element;

/**
 * Builds a <code>&lt;wd:repeater-action/></code>
 * <p>
 * Three actions are defined :
 * <ul>
 * <li><code>&lt;wd:repeater-action id="add" action-command="add-row" 
repeater="repeater-id"/></code> :
 *   when activated, adds a row to the sibling repeater named "repeater-id".
 * </li>
 * <li><code>&lt;wd:repeater-action id="insert" action-command="insert-rows" 
repeater="repeater-id"
 *   select="select-id"/></code> : inserts rows before the selected rows from 
the sibling repeater named "repeater-id".
 *   The selected rows are identified by the boolean field "select-id" present 
in each row.
 * </ul>
 * <li><code>&lt;wd:repeater-action id="rm" action-command="delete-rows" 
repeater="repeater-id"
 *   select="select-id"/></code> : removes the selected rows from the sibling 
repeater named "repeater-id".
 *   The selected rows are identified by the boolean field "select-id" present 
in each row.
 * </ul>
 * 
 * @author <a href="http://www.apache.org/~sylvain/";>Sylvain Wallez</a>
 * @version CVS $Id: RepeaterActionDefinitionBuilder.java,v 1.1 2005/01/25 
21:49:23 depp Exp $
 */
public class RepeaterActionDefinitionBuilder extends 
AbstractWidgetDefinitionBuilder {
    
    
    public WidgetDefinition buildWidgetDefinition(Element widgetElement) throws 
Exception {
        String actionCommand = DomHelper.getAttribute(widgetElement, 
"action-command");
        RepeaterActionDefinition definition = createDefinition(widgetElement, 
actionCommand);
        setLocation(widgetElement, definition);
        setId(widgetElement, definition);
        setDisplayData(widgetElement, definition);
        setValidators(widgetElement, definition);

        definition.setActionCommand(actionCommand);

        Iterator iter = buildEventListeners(widgetElement, "on-activate", 
ActionListener.class).iterator();
        while (iter.hasNext()) {
            definition.addActionListener((ActionListener)iter.next());
        }

        return definition;
    }
    
    protected RepeaterActionDefinition createDefinition(Element element, String 
actionCommand) throws Exception {
        
        if ("delete-rows".equals(actionCommand)) {
            String repeater = DomHelper.getAttribute(element, "repeater");
            String select = DomHelper.getAttribute(element, "select");
            return new DeleteRowsActionDefinition(repeater, select);
 
        }else if ("insert-rows".equals(actionCommand)) {
            String repeater = DomHelper.getAttribute(element, "repeater");
            String select = DomHelper.getAttribute(element, "select");
            return new InsertRowsActionDefinition(repeater, select);
 
        } else if ("add-row".equals(actionCommand)) {
            String repeater = DomHelper.getAttribute(element, "repeater");
            return new AddRowActionDefinition(repeater);
            
        } else {
            throw new Exception("Unknown repeater action '" + actionCommand + 
"' at " + DomHelper.getLineLocation(element));
        }
    }
}

--- End Message ---
--- Begin Message ---
Well, what do you guys think? Does 7 days of silence amount to agreement??
I'll be happy to make any mods you suggest and resubmit source to you for
inclusion...


#define SUBJECT_DRIFT_ON
Also, I have a "2 line" minor tweak to the forms-calendar-styling.xsl that
disables the "calendar icon/popup" when a datetype="date" widget is set to
readonly, disabled, or hidden (in these cases, we don't want an icon or
popup - ESPECIALLY when the widget is supposed to be "hidden").

The change was simple, in
cocoon/samples/blocks/forms/resources/forms-calendar-styling.xsl

I added:
<xsl:if test="not(fi:[EMAIL PROTECTED]'disabled'] or
fi:[EMAIL PROTECTED]'readonly'] or fi:[EMAIL PROTECTED]'hidden'])">
around the calendar HTML anchor.

The modified code segment in that file now reads:
    <!-- calendar popup -->
    <xsl:if test="not(fi:[EMAIL PROTECTED]'disabled'] or
fi:[EMAIL PROTECTED]'readonly'] or fi:[EMAIL PROTECTED]'hidden'])">
    <a href="#" name="{$id}" id="{$id}"
       onClick="forms_calendar.select(forms_getForm(this)['[EMAIL 
PROTECTED]'],'{$id}','
{$format}'); return false;">
      <img src="{$resources-uri}/cal.gif" border="0" alt="Calendar"/>
    </a>
    </xsl:if>

All that I added was the surrounding <xsl:if> block. It works great!!

Should I move this to a separate CONTRIBUTION thread or is this simple
enough that you would just get it into the cvs archive??

Thanks again - I hope these contributions are seen more helpful than the
pain they are to include them in the distribution... (And IMHO, how can you
get a better deal than a free ghost-writer?? ;-)

David



-----Original Message-----
From: depub2 [mailto:[EMAIL PROTECTED]
Sent: Friday, February 11, 2005 2:32 PM
To: CocoonDev
Subject: Re: CONTRIBUTION: repeater-widget (insert row):
InsertRowsActionDefinition


Can we get a few quick yay/nays??

Sylvain is considering incorporation of the changes noted below... Could we
hear a few words of encouragement (or discouragement) from a couple of
people so this item can be closed and completed.

Thanks to all! David


> Sylvain wrote:

depub2 wrote:

>Hello Folks,
>
>I would like to make a small contribution to the cocoon repeater-widget
>(insert row) and would like someone (Sylvain Wallez?) to accept my code; so
>I'll be a "ghostwriter" as it does not make sense for me to maintain this
>small piece of code.
>
>Specifically, I would like to add something like:
>  package org.apache.cocoon.forms.formmodel;
>  public class InsertRowsActionDefinition extends RepeaterActionDefinition
>{}
>
>It will act like DeleteRowsActionDefinition; but instead will insert a
>single row in front of each of the selected rows. This sure seems like a
>natural need for the repeater! Yes?!?
>
>

Sorry, it doesn't seem natural to me, and I never saw such behaviour,
particularily inserting several rows at once and inserting them before
the selected row.

Now I understand that the set of available repeater-actions is currently
limited, and that "add-row" that inserts a new row at the end of the
repeater may not be the most convenient when you want to insert a row at
an arbitrary place in the repeater (although you have the "add-after"
row-action).

So IMO the behaviour of an "add-rows" action should be to add rows
_after_ the selected rows. This kind of interaction usually involves a
single selection, but we could find it acceptable that it is generalized
to inserting a row after all selected rows.

What do people think?

Sylvain


> Hi Sylvain,
> As you mention it, I think "add-rows" would be as-good or better than
"insert-rows".
> Since the change is fairly trivial to the tested "insert-rows" code you
> now have from me, it might even be worthwhile to have both "insert-rows"
and
> "add-rows" and allow the user / GUI designer to select their choice.
> Perhaps the repeater samples code could be modified to only demonstrate
> "add-rows" to "steer" a GUI designer in that more favorable direction.
>
> One nice side-effect of multiple-checked insert-rows/add-rows capability
is
> that multiple-selection enables one to rapidly insert multiple rows
through
> exponentially increasing iterations of inserts. (check 1, check 2, check
4,
> check 8...) Just to clarify, "my code's" behavior is that a _single_ row
is
> inserted above (below is fine too) every selected row. Adding 32 new/blank
> rows is simply a 5x "add-rows" operation. Perhaps it would be helpful to
> "pre-select" the rows that were added so that this multiple exponential
> insert is even easier on the user, so they don't have to check the boxes.
> Woe unto them that later perform "delete-rows" without deselecting first.
>
> As it turns out, multiple-select insertion was easier to implement than
> single-selection, based on copying the delete-rows code and minor tweak.
>
> If you find it difficult to modify the samples code, I could probably
> do it and email it to you.
> Best, David Epperly -depub2


--
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


--- End Message ---
--- Begin Message ---

David's notes: see below

Sylvain Wallez
Thu, 24 Feb 2005 09:07:07 -0800

depub2 wrote:

Well, what do you guys think? Does 7 days of silence amount to agreement??
I'll be happy to make any mods you suggest and resubmit source to you for
inclusion..



Added. When including your patch, I had a quick look at Excel and found that the row insertion command adds rows _before_ the selected rows as you initially suggested. So I added it that way. I made a small change though by clearing the selection after executing the action.
 
If you'd like your name to be included for fame and posterity in Cocoon's release notes, please give us your full name as "David" is a bit unprecise.
 
I think it would be better to not clear the selections and here's why: if there is a need to insert, say 32 empty rows, it is much easier if the ones that are already checked remain checked; so the use case looks like, check 1, insert; check the new one (old one still checked), insert; check 2, insert; check 4, insert; check 8 (old 8 still checked), insert; done! It is very easy to have some very short client-side _javascript_/buttons that "uncheck-all" or "check-all" (we have it in our application), so the need to auto-uncheck is not really needed - and in fact for the above use-case, hindering.
 
Also, we liked your suggestion that, for our GUI, we use "add-rows" rather than "insert-rows" - so, when I get a chance, I'll submit that code to you for inclusion so the designer of future GUI's can have their choice depending upon their needs. We also thought that, if nothing is checked, add-rows automatically adds one row at the end - perhaps it would be good if "insert-rows" did this also. We really like the way that "feels".
 
If you like to include my name, it is David Epperly, but I don't need kudos - it's a pleasure to just be working with you. I'm including some notes from an earlier email in case they help...
 
Again, after I hear back from you, I'll send some updated code to you...  (sorry for the delay, I don't check the threads so often lately).
 
> As you mention it, I think "add-rows" would be as-good or better than
"insert-rows".
> Since the change is fairly trivial to the tested "insert-rows" code you
> now have from me, it might even be worthwhile to have both "insert-rows"
and
> "add-rows" and allow the user / GUI designer to select their choice.
> Perhaps the repeater samples code could be modified to only demonstrate
> "add-rows" to "steer" a GUI designer in that more favorable direction.
>
> One nice side-effect of multiple-checked insert-rows/add-rows capability
is
> that multiple-selection enables one to rapidly insert multiple rows
through
> exponentially increasing iterations of inserts. (check 1, check 2, check
4,
> check 8...) Just to clarify, "my code's" behavior is that a _single_ row
is
> inserted above (below is fine too) every selected row. Adding 32 new/blank
> rows is simply a 5x "add-rows" operation. Perhaps it would be helpful to
> "pre-select" the rows that were added so that this multiple exponential
> insert is even easier on the user, so they don't have to check the boxes.
> Woe unto them that later perform "delete-rows" without deselecting first.
 
 
 
#define SUBJECT_DRIFT_ON
Also, I have a "2 line" minor tweak to the forms-calendar-styling.xsl that
disables the "calendar icon/popup" when a datetype="date" widget is set to
readonly, disabled, or hidden (in these cases, we don't want an icon or
popup - ESPECIALLY when the widget is supposed to be "hidden").

The change was simple, in
cocoon/samples/blocks/forms/resources/forms-calendar-styling.xsl

I added:
<xsl:if test="not(fi:{at-symbol}disabled='disabled'] or
fi:{at-symbol}readonly='readonly'] or fi:{at-symbol}hidden='hidden'])">
around the calendar HTML anchor.

The modified code segment in that file now reads:
   <!-- calendar popup -->
   <xsl:if test="not(fi:{at-symbol}disabled='disabled'] or
fi:{at-symbol}readonly=readonly'] or fi:{at-symbol}hidden='hidden'])">
   <a href="" name="{$id}" id="{$id}"
      >
     <img src="" border="0" alt="Calendar"/>
   </a>
   </xsl:if>

All that I added was the surrounding <xsl:if> block. It works great!!

Should I move this to a separate CONTRIBUTION thread or is this simple
enough that you would just get it into the cvs archive??



Sorry, but there's no "readonly" attribute on fi:styling (you should use the "disabled" state instead) and type="hidden" is handled globally for the whole field and not only for the calendar image.


But I'm wondering if you're looking at the right source when you say "cvs archive". Cocoon has moved from CVS to Subversion for a while now and you may have looked at an old version of the XSLs.
 
Well actually, the readonly="readonly" works! Try it!!! And there are some cases where disabled="disabled" is problematic (binding/saving) and I think something else I can't remember right now (pulldown selections? calendar selections? - can't remember).  (note {at-symbol} above must be translated to @ - seems that symbol is not allowed on the archives.)
 
Again, we found it annoying to allow a disabled (or readonly) widget actually get changed by the calendar popup. This code fixes that defect.
 
When I say cvs archive, I mean the nightly snapshot archive from http://cvs.apache.org/snapshots/cocoon-2.1/


Sylvain

--
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


--- End Message ---

Reply via email to