Re: CONTRIBUTION: repeater-widget (insert row): InsertRowsActionDefinition

[depub2 <de...@mxsi.com>]

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}"
      onClick="forms_calendar.select(forms_getForm(this)['{at-symbol}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??




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 }

Re: CONTRIBUTION: repeater-widget (insert row): InsertRowsActionDefinition

[Sylvain Wallez <sy...@apache.org>]

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.
 

<snip/>

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


Sorry, but I really don't know what you're talking about. Is this 
'readonly' in the binding? If so, what's the relation with the styling 
XSLs??

Sylvain

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

Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled

[Joerg Heinicke <jo...@gmx.de>]

On 15.03.2005 23:33, Sylvain Wallez wrote:

> Again and again, there is no such "readonly" attribute. You can set the 
> state of a widget to "disabled" which leads to something similar to what 
> you describe: the input is readonly, and the calendar icon is still 
> visible but disabled.

There is, but it's pure HTML. It has nothing to do with CForms. Unknown
attributes on fi:styling are just copied to the output, e.g. @class and
also @readonly.

I did not have a look at CForms since the adding of the states, so I 
don't know how much in the meantime is handled automatically and no 
longer in the template.

Joerg

Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled

[Sylvain Wallez <sy...@apache.org>]

depub2 wrote:

>
> 
>
>     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.) 
>
>
>
> Sorry, but I really don't know what you're talking about. Is this 
> 'readonly' in the binding? If so, what's the relation with the styling 
> XSLs??
>  
> It is in the template file, <fi:styling> tag. I believe that 
> readonly="readonly" simply gets passed along as an attribute to the 
> "input" tag and is valid xhtml which the browser then interprets to be 
> like disabled="disabled", but slightly different. Here's an example usage:
>  
> <ft:widget id="StatusMessage">
>   <fi:styling readonly="readonly" type="textarea" rows="4" cols="75" 
> wrap="hard"
>  class="DocOrdersStatusMessage"/>
> </ft:widget>


Again, I can't find it. If the forms/samples directory:
$ find . -type f | xargs grep readonly
./forms/binding/01value-bind.xml:  <fb:value id="readonly"  
./forms/binding/01value-def.xml:    <fd:field id="readonly" >

The only "readonly" in the whole CForms samples (which include the XSLs) 
is the name of a widget.

Can you please give me the URL of the relevant file under 
http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/blocks/forms/
 

> Anyway, inserting that small code segment in the source (see below) 
> and then playing with the samples to disable the calendar widget will 
> show you what I mean - and try readonly as a styling attribute to see 
> that at work too. Then try disabling the calendar without my 
> modifications and you'll notice that the date can be changed, even 
> though the widget is disabled.


Again and again, there is no such "readonly" attribute. You can set the 
state of a widget to "disabled" which leads to something similar to what 
you describe: the input is readonly, and the calendar icon is still 
visible but disabled.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director

RE: Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled WAS repeater-widget (insert row): InsertRowsActionDefinition

[depub2 <de...@mxsi.com>]

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

Sorry, but I really don't know what you're talking about. Is this 'readonly'
in the binding? If so, what's the relation with the styling XSLs??

It is in the template file, <fi:styling> tag. I believe that
readonly="readonly" simply gets passed along as an attribute to the "input"
tag and is valid xhtml which the browser then interprets to be like
disabled="disabled", but slightly different. Here's an example usage:

<ft:widget id="StatusMessage">
  <fi:styling readonly="readonly" type="textarea" rows="4" cols="75"
wrap="hard"
 class="DocOrdersStatusMessage"/>
</ft:widget>

Anyway, inserting that small code segment in the source (see below) and then
playing with the samples to disable the calendar widget will show you what I
mean - and try readonly as a styling attribute to see that at work too. Then
try disabling the calendar without my modifications and you'll notice that
the date can be changed, even though the widget is disabled.



Sylvain

--
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }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}"
      onClick="forms_calendar.select(forms_getForm(this)['{at-symbol}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
simpleenough that you would just get it into the cvs archive??