Return-Path: 
 <dev-return-71480-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 38922 invoked from network); 18 Feb 2005 18:55:27 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 18 Feb 2005 18:55:27 -0000
Received: (qmail 39576 invoked by uid 500); 18 Feb 2005 18:55:19 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 39518 invoked by uid 500); 18 Feb 2005 18:55:19 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 39500 invoked by uid 99); 18 Feb 2005 18:55:19 -0000
X-ASF-Spam-Status: No, hits=0.1 required=10.0
	tests=FORGED_RCVD_HELO
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Received: from adsl-216-102-153-220.dsl.lsan03.pacbell.net (HELO m1o.mxsi.com)
 (216.102.153.220)
  by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 18 Feb 2005 10:55:17 -0800
Received: from ITC9 (itc9.mxsi.com [169.254.131.136])
	by m1o.mxsi.com (8.11.7/8.11.7) with SMTP id j1IItF924102;
	Fri, 18 Feb 2005 10:55:15 -0800
From: "depub2" <depub2@mxsi.com>
To: "CocoonDev" <dev@cocoon.apache.org>, <sylvain@apache.org>
Cc: <andrew@luminas.co.uk>
Subject: RE: Re: CONTRIBUTION: repeater-widget (insert row):
 InsertRowsActionDefinition
Date: Fri, 18 Feb 2005 10:55:54 -0800
Message-ID: <NABBLBOLGDFMDCEDLJGAKEMJEDAA.depub2@mxsi.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <NABBLBOLGDFMDCEDLJGAMEKOEDAA.depub2@mxsi.com>
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

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:styling[@disabled='disabled'] or
fi:styling[@readonly='readonly'] or fi:styling[@type='hidden'])">
around the calendar HTML anchor.

The modified code segment in that file now reads:
    <!-- calendar popup -->
    <xsl:if test="not(fi:styling[@disabled='disabled'] or
fi:styling[@readonly='readonly'] or fi:styling[@type='hidden'])">
    <a href="#" name="{$id}" id="{$id}"
       onClick="forms_calendar.select(forms_getForm(this)['{@id}'],'{$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:depub2@mxsi.com]
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 }