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.
"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.xslI 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 }
