Re: CONTRIBUTION: repeater-widget (insert row): InsertRowsActionDefinition
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,
---BeginMessage---
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
[FYI] How IE handles PDFs
FYI...
How to use FOP in a Servlet
Here's what we did in cocoon:
-
map:pipeline
map:parameter name=expires value=access plus 20 seconds/
map:match pattern=PDFstaticcontent/*/*/*.pdf
!--DocDir/ObjName/FileName--
map:read mime-type=application/pdf
src=context://{global:appPath}/content/{1}/{2}/{3}.pdf/
/map:match
/map:pipeline
-
http://xml.apache.org/fop/servlets.html#ie
Notes on Microsoft Internet Explorer
Some versions of Internet Explorer will not automatically show the PDF or
call
the servlet multiple times. These are well-known limitations of Internet
Explorer and are not a problem of the servlet. However, Internet Explorer
can
still be used to download the PDF so that it can be viewed later. Here are
some suggestions in this context:
Use an URL ending in .pdf, like http://myserver/servlet/stuff.pdf. Yes, the
servlet can be configured to handle this. If the URL has to contain
parameters, try to have both the base URL as well as the last parameter end
in
.pdf, if necessary append a dummy parameter, like
http://myserver/servlet/stuff.pdf?par1=apar2=bd=.pdf. The effect may
depend
on IEx version.
Give IEx the opportunity to cache. In particular, ensure the server does not
set any headers causing IEx not to cache the content. This may be a real
problem if the document is sent over HTTPS, because most IEx installations
will by default not cache any content retrieved over HTTPS. Setting the
Expires header entry may help in this case:
response.setDateHeader(Expires, System.currentTimeMillis() +
cacheExpiringDuration * 1000);
Consult your server manual and the relevant RFCs for further details on HTTP
headers and caching.
Cache in the server. It may help to include a parameter in the URL which has
a
timestamp as the value min order to decide whether a request is repeated.
IEx
is reported to retrieve a document up to three times, but never more often.
Depending on the versions, IE sends 2 or 3 requests for a single PDF
file. That sucks badly, especially with non-cachable pipelines!
http://www.mail-archive.com/user@struts.apache.org/msg23445.html
Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research Technology Director
RE: CONTRIBUTION: forms-calendar-styling defect when widget disabled
Pardon me, but I appreciate all of your discussion about this... I simply
ask that you place
TWO LINES OF CODE in forms-calendar-styling.xsl to support hidden and
disabled widgets associated with calendars.
As an extra convenience to me and other users, I'd also appreciate it if you
also include the passthru readonly test - no direct widget support needed;
security concerns not relevant - just keeping simple users from getting
confused, not trying to protect from hackers. Impact of adding support for
readonly=NONE.
David
Just do it - Nike
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:ifAll that I added was the surrounding xsl:if block. It works
great!!
So, to sum it up: readonly as attribute is supported in
the current
version of the styling XSL files, but there will be no
widget support
for this due to security issues. If treatment of the readonly
attribute should differ from the current situation, it is up to the
user to modify the styling XSL files.
Exactly. Very good summary!
Furthermore, the choice between readonly/disabled is IMO really a
presentation concern, and not an application concern. That's why I
consider that distinguishing them at the widget level by
introducing an additional state would be useless.
So there is one action left: where do we put this information to inform
the original requester and to avoid a recycle of this discussion?
Bye, Helma
RE: Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled WAS repeater-widget (insert row): InsertRowsActionDefinition
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}"
img src="" border="0" alt="Calendar"/
/a
/xsl:ifAll 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??
Re: CONTRIBUTION: repeater-widget (insert row): InsertRowsActionDefinition
David's notes: see
below
Sylvain WallezThu, 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
forinclusion..
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
notclear the selectionsand 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 somevery 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 havetheir 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 toinclude 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 capabilityis that multiple-selection enables
one to rapidly insert multiple rowsthrough exponentially increasing
iterations of inserts. (check 1, check 2, check4, check 8...) Just
to clarify, "my code's" behavior is that a _single_ rowis 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:ifAll 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??
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
RE: Re: CONTRIBUTION: repeater-widget (insert row): InsertRowsActionDefinition
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
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 }
Re: CONTRIBUTION: repeater-widget (insert row): InsertRowsActionDefinition
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 }
CONTRIBUTION: repeater-widget (insert row): InsertRowsActionDefinition
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?!?
I am now prototyping and testing the code and will provide it to the project
when I find someone (Sylvain Wallez??) who is willing to take responsibility
for it. How can I get it into the distribution so our next download of the
cocoon snapshot a few weeks from now will include it??
Best Regards,
David
RE: Defect: booleanfield (checkbox) submit-on-change does not work
The booleanfield (checkbox) fi:styling submit-on-change=true/ fails to submit the page when the checkbox value is changed (checked/unchecked) and yeilds an error when the page is submitted with the field unchecked. The incorrect behavior may be observed by adding to ~blocks/forms/forms/form2_template.xml fi:styling submit-on-change=true/ for the choose widget; the entire code segment (with surrounding context) in that file would be: tr td valign=topft:widget-label id=number//td td valign=topft:widget id=number//td /tr tr td/ td valign=topft:widget id=choose fi:styling submit-on-change=true/ /ft:widget ft:widget-label id=choose//td /tr tr td valign=topft:widget-label id=sex//td td valign=topft:widget id=sex//td /tr Then simply access: http://yourserver/cocoon/samples/blocks/forms/form2xml.flow and verify that changing the value of the checkbox does not submit the form. Thanks for putting this on the bug list... (and fixing it :)) David
Internet Explorer 6.0 cocoon reader PDF defect?
I am unable to get MS IE 6.0 to display a PDF file that
comes from a reader. It works fine when using the fo2pdf
serializer, but I need to use the reader to read a file.
The following sitemap excerpt behaves nicely with Mozilla
and MS IE 5.5; BUT NOT MS IE 6.0.
map:match pattern=PDFdebug/*.pdf
map:read mime-type=application/pdf src={1}.pdf/
/map:match
Using cocoon 2.1.4 release.
Help!! What's the problem??
David
Cocoon/woody windows-only platform defect
Defect:
The following defect is limited to the MS windows platform,
it does not occur
on the linux platform. Both platforms were setup with tomcat
4.1.29,
and cocoon 2.1.4.
On the windows platorm, a woody form will lose it's data
when
the enctype=multipart/form-data is specified in the form
template,
for example:
wt:form-template action=#{$continuation/id}.kont
method=POST enctype=multipart/form-data
This enctype is required for proper operation of the upload
widget.
In the test case, (very similar to the XML Binding demo), a
flowscript
which uses the showForm() function does not exit.
It is believed that the showForm() call in the flowscript
never exits because
validation always fails because we have a required field
(which is filled
in with valid data by the user) and that field is null
because the
widget is not being updated with the request data because of
this defect
when enctype=multipart/form-data.
Again, this problem only occurs on the MS Windows platform
and works
fine on a linux platform. The problem does not appear to be
browser
dependent.
To see the problem for yourself, simply add
enctype=multipart/form-data
to the form-template in the XML Binding sample.
Windows only defect using form tag with enctype set
Defect:
The following defect occurs ONLY on the MS windows platform,
it does NOT occur on the linux platform.
Both platforms were setup with tomcat 4.1.29, and cocoon 2.1.4.
On the windows platorm, a woody form will lose it's data when
the enctype=multipart/form-data is specified in the form
template, for example:
wt:form-template action=#{$continuation/id}.kont
method=POST enctype=multipart/form-data
This enctype is required for proper operation of the upload
widget.
To see the problem for yourself, on a windows based server, simply add
enctype=multipart/form-data
to the form tag (see above) in
~/cocoon/samples/woody/forms/form2_template.xml
and then run the XML Binding sample.
In the test case, (very similar to the XML Binding demo), a
flowscript which uses the showForm() function does not exit.
It is believed that the showForm() call in the flowscript
never exits because validation always fails because we have a required field
(which is filled in with valid data by the user) and that field is null
because the widget is not being updated with the request data because of
this defect when enctype=multipart/form-data.
Again, this problem only occurs on the MS Windows platform
and works fine on a linux platform. The problem does not appear to be
browser dependent.
Cocoon/woody windows-only platform defect
Defect:
The following defect is limited to the MS windows platform,
it does not occur
on the linux platform. Both platforms were setup with tomcat
4.1.29,
and cocoon 2.1.4.
On the windows platorm, a woody form will lose it's data
when
the enctype=multipart/form-data is specified in the form
template,
for example:
wt:form-template action=#{$continuation/id}.kont
method=POST enctype=multipart/form-data
This enctype is required for proper operation of the upload
widget.
In the test case, (very similar to the XML Binding demo), a
flowscript
which uses the showForm() function does not exit.
It is believed that the showForm() call in the flowscript
never exits because
validation always fails because we have a required field
(which is filled
in with valid data by the user) and that field is null
because the
widget is not being updated with the request data because of
this defect
when enctype=multipart/form-data.
Again, this problem only occurs on the MS Windows platform
and works
fine on a linux platform. The problem does not appear to be
browser
dependent.
To see the problem for yourself, simply add
enctype=multipart/form-data
to the form-template in the XML Binding sample.
Woody multivaluefield widget xml binding support
First, is there a better place for CocoonForms (Woody) discussions? Second, any idea when the Woody multivaluefield widget will be supported by the xml binding (bugzilla 25884)? I am using 2.1.4 and it still doesn't work for me. Seems like lot's of folks would need that... we certainly do.. What I'm looking for is something bound to path=filenames/filename where each item selected in the multivaluefield will produce something like: filenames filenamefile1/filename filenamefile2/filename filenames When will we have it? David
