You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "F. Da Costa" <da...@xs4all.nl> on 2004/02/21 17:17:38 UTC
Form woes, can there be too many elements?
Hi,
I've been trying to find a solution to a (IMHO) very straight forward issue.
It concerns useing a form, a hidden field and 400 form elements (could
easily become a couple of 1000).
I noticed (in a small form test) that the setHiddenField gets called
*prior* to dealing with the rest of the fields. Thus making it the ideal
point to do some intermittent processing before allowing the form to
continue being put back on the screen. This is a correct assumption, i hope?
In the real thing i'm working on, the process does *not* stop at the
setHiddenField point (whilst debugging). Restarted 3M7 several times but to
no avail.
The only difference with the testForm is the fact that there is a .script
involved with a <body> and <initialization> bit. Should i expect this to
have any influence at all *and* when in the chain of events is it handled
(the code in the .script)? The script span is at the very end of the .html.
Here is a small snip of the code for the hiddenField.
public String getHiddenField() {
return _hiddenField;
}
public void setHiddenField(String value) {
_hiddenField = "dynamic";
_refreshPage =false;
_dynamicallyExpandPage = true;
}
If anybody has a suggestion that would be great, this has kept me occupied
now for approx 4 (long) days. :-((
TIA
Fermin DCG
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Form woes, can there be too many elements???
Posted by "F. Da Costa" <da...@xs4all.nl>.
F. Da Costa wrote:
> Hi,
>
> I've been trying to find a solution to a (IMHO) very straight forward
> issue.
>
> It concerns useing a form, a hidden field and 400 form elements (could
> easily become a couple of 1000).
> I noticed (in a small form test) that the setHiddenField gets called
> *prior* to dealing with the rest of the fields. Thus making it the ideal
> point to do some intermittent processing before allowing the form to
> continue being put back on the screen. This is a correct assumption, i
> hope?
>
> In the real thing i'm working on, the process does *not* stop at the
> setHiddenField point (whilst debugging). Restarted 3M7 several times but
> to no avail.
> The only difference with the testForm is the fact that there is a
> .script involved with a <body> and <initialization> bit. Should i expect
> this to have any influence at all *and* when in the chain of events is
> it handled (the code in the .script)? The script span is at the very end
> of the .html.
>
The script is *not* an issue either. Just expanded the testForm to include
the exact same bahaviour and things work just fine.
I hope i'm wrong here but it almost feels like a no of elements (?) issue.
2b continued, help still appreciated
> Here is a small snip of the code for the hiddenField.
>
> public String getHiddenField() {
> return _hiddenField;
> }
>
> public void setHiddenField(String value) {
> _hiddenField = "dynamic";
> _refreshPage =false;
> _dynamicallyExpandPage = true;
> }
>
> If anybody has a suggestion that would be great, this has kept me
> occupied now for approx 4 (long) days. :-((
>
> TIA
> Fermin DCG
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Form woes, can there be too many elements? (SOLVED)
Posted by "F. Da Costa" <da...@xs4all.nl>.
Hi,
Problem area:
Having a <button> (which AFAIK is *not* a form element) in another form
than the one being submitted stuffs up the cycle *of* the form being submitted.
Situation sketch:
Form-A contains info that needs to be submitted as well as a hidden field.
NO submission controls on or in Form-A.
Form-B contains controls as well as fields required to submit Form-A to the
server.
Expected behaviour:
Using <button> via js to submit Form-A i would expect that *only* Form-A
gets processed. It does BUT for one reason or the other it also does
something with Form-B which causes the last page loaded to reload. This
means disregarding Form-A and causing a totally unpredictable sitiuation to
take place. I noticed this because setting a breakpoint on the setter of
the hidden field of Form-A did not stop the page from displaying (whilst
the render had not even started yet).
Taking the <button> *outside* of Form-B solves the problem of Form-B being
submitted/ processed in some way prior to Form-A.
Whether this is usefull info for the list i'm not sure because this might
have more to do with HTML than with Tapestry. However, it kept me running
around in circles for a full 7 days & despite the reply from Howard it
seemed to have passed completely unnoticed. Maybe signifying total
insignificance of the subject (which is fine, i guess).
In short:
When submitting via js make sure to embed the js carrying widget either IN
the form to be submitted but NEVER in another form.
Fermin DCG
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Form woes, can there be too many elements? (forgot)
Posted by "F. Da Costa" <da...@xs4all.nl>.
>
> The only issue remaining is submitting data and letting the form come
> back with the reduced paga version. The setHiddenField method is entered
> but at that time the whole page has already been send back to the
> client. Figures that out by putting a breakpoint in the setter for the
> hiddenField.
>
Sorry, forgot to mention that after the shoot through of the render i got
the following error report in the Eclipse console:
Feb 23, 2004 8:05:17 PM org.apache.tapestry.engine.AbstractEngine
reportException
WARNING: Exception during post-request cleanup.
EOFException(java.net.SocketException: Software caused connection abort:
socket write error)
at org.mortbay.http.BufferedOutputStream.flush(BufferedOutputStream.java:195)
at org.mortbay.http.ChunkingOutputStream.flush(ChunkingOutputStream.java:67)
at org.mortbay.http.HttpOutputStream.flush(HttpOutputStream.java:482)
at org.mortbay.jetty.servlet.ServletOut.flush(ServletOut.java:49)
at
org.apache.tapestry.request.ResponseOutputStream.forceFlush(ResponseOutputStream.java:190)
at org.apache.tapestry.engine.AbstractEngine.service(AbstractEngine.java:969)
at
org.apache.tapestry.ApplicationServlet.doService(ApplicationServlet.java:238)
at org.apache.tapestry.ApplicationServlet.doPost(ApplicationServlet.java:367)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:356)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1723)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:514)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1673)
at org.mortbay.http.HttpServer.service(HttpServer.java:879)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:783)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:945)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:800)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:201)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:454)
**********************************************************
Exception during post-request cleanup.
Session id: null
Client address: 127.0.0.1
Exceptions:
org.mortbay.http.EOFException
java.net.SocketException: Software caused connection abort: socket write error
java.net.SocketOutputStream.socketWrite0(Native Method)
java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
java.net.SocketOutputStream.write(SocketOutputStream.java:136)
org.mortbay.http.NullableOutputStream.write(NullableOutputStream.java:119)
org.mortbay.util.ByteBufferOutputStream.writeTo(ByteBufferOutputStream.java:158)
org.mortbay.http.BufferedOutputStream.flush(BufferedOutputStream.java:191)
org.mortbay.http.ChunkingOutputStream.flush(ChunkingOutputStream.java:67)
org.mortbay.http.HttpOutputStream.flush(HttpOutputStream.java:482)
org.mortbay.jetty.servlet.ServletOut.flush(ServletOut.java:49)
org.apache.tapestry.request.ResponseOutputStream.forceFlush(ResponseOutputStream.java:190)
org.apache.tapestry.engine.AbstractEngine.service(AbstractEngine.java:969)
org.apache.tapestry.ApplicationServlet.doService(ApplicationServlet.java:238)
org.apache.tapestry.ApplicationServlet.doPost(ApplicationServlet.java:367)
javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:356)
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558)
org.mortbay.http.HttpContext.handle(HttpContext.java:1723)
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:514)
org.mortbay.http.HttpContext.handle(HttpContext.java:1673)
org.mortbay.http.HttpServer.service(HttpServer.java:879)
org.mortbay.http.HttpConnection.service(HttpConnection.java:783)
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:945)
org.mortbay.http.HttpConnection.handle(HttpConnection.java:800)
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:201)
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:454)
**********************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Form woes, can there be too many elements?
Posted by "F. Da Costa" <da...@xs4all.nl>.
Bit late on the reaction but had to take the mrs out to a castle and do
some indoor skiing (which went better than my current Tap issue ;) )
Howard M. Lewis Ship wrote:
> There are no upper limits I'm aware of. What's this setHiddenField() stuff? Could you elaborate on
> the structure of your form? I'm guessing you have a Foreach or ListEdit generating rows, and a
> Hidden for each row?
>
Starting with the last: Noop, there is only 1 hiddenField on the form not
in the table which is indeed filled with a Foreach (you assumed correctly)
but that all goes fine (for now, whilst in testing).
Its not an ordinary table however but a treetable.
The structure i'm using can potentially be quite large so i build in a
mechanism to load additional data incrementally as requested by the user.
I had a very elegant solution that allowed an absolute minumum of traffic &
processing but due to the way the form works i can't use it (but maybe
that's something for the future). Unfortunately i had to modify it to be
able to work with the form and the way it is currently handled.
Basically i need an indicator to tell me how to render the rows (3
flavours). This is where the hiddenField comes into play.
Once the form has been initialized (read the page has been rendered once) i
can re-render the page with a lot less data (because that is already on the
client).
Refreshing & adding data to the structure dynamically (sub-optimally
though) works fine.
The only issue remaining is submitting data and letting the form come back
with the reduced paga version. The setHiddenField method is entered but at
that time the whole page has already been send back to the client. Figures
that out by putting a breakpoint in the setter for the hiddenField.
In short:
How do i make sure that on submission of the form i know that i have to use
a reduced page version. I need to know *before* the render-process starts
(as the conditions hava to be set properly and are depended on a parameter
that has to set to true when the form arrives at the server).
I hope this is clear enough now to form an opinion.
If not, i'll retry (i'm not going anywhere fast on this).
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Tapestry: Java Web Components
> http://howardlewisship.com
>
>
>
>>-----Original Message-----
>>From: news [mailto:news@sea.gmane.org] On Behalf Of F. Da Costa
>>Sent: Saturday, February 21, 2004 11:18 AM
>>To: tapestry-user@jakarta.apache.org
>>Subject: Form woes, can there be too many elements?
>>
>>
>>Hi,
>>
>>I've been trying to find a solution to a (IMHO) very straight
>>forward issue.
>>
>>It concerns useing a form, a hidden field and 400 form
>>elements (could
>>easily become a couple of 1000).
>>I noticed (in a small form test) that the setHiddenField gets called
>>*prior* to dealing with the rest of the fields. Thus making
>>it the ideal
>>point to do some intermittent processing before allowing the form to
>>continue being put back on the screen. This is a correct
>>assumption, i hope?
>>
>>In the real thing i'm working on, the process does *not* stop at the
>>setHiddenField point (whilst debugging). Restarted 3M7
>>several times but to
>>no avail.
>>The only difference with the testForm is the fact that there
>>is a .script
>>involved with a <body> and <initialization> bit. Should i
>>expect this to
>>have any influence at all *and* when in the chain of events
>>is it handled
>>(the code in the .script)? The script span is at the very end
>>of the .html.
>>
>>Here is a small snip of the code for the hiddenField.
>>
>> public String getHiddenField() {
>> return _hiddenField;
>> }
>>
>> public void setHiddenField(String value) {
>> _hiddenField = "dynamic";
>> _refreshPage =false;
>> _dynamicallyExpandPage = true;
>> }
>>
The refreshpage and dynamicallyExpandPage are the two parameters i use to
determine which part of the page needs to be rendered from the .html as
well as from the .script.
There can be a significant difference between the intitial and subsequent
renders.
TIA
Fermin DCG
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Form woes, can there be too many elements?
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
There are no upper limits I'm aware of. What's this setHiddenField() stuff? Could you elaborate on
the structure of your form? I'm guessing you have a Foreach or ListEdit generating rows, and a
Hidden for each row?
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components
http://howardlewisship.com
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of F. Da Costa
> Sent: Saturday, February 21, 2004 11:18 AM
> To: tapestry-user@jakarta.apache.org
> Subject: Form woes, can there be too many elements?
>
>
> Hi,
>
> I've been trying to find a solution to a (IMHO) very straight
> forward issue.
>
> It concerns useing a form, a hidden field and 400 form
> elements (could
> easily become a couple of 1000).
> I noticed (in a small form test) that the setHiddenField gets called
> *prior* to dealing with the rest of the fields. Thus making
> it the ideal
> point to do some intermittent processing before allowing the form to
> continue being put back on the screen. This is a correct
> assumption, i hope?
>
> In the real thing i'm working on, the process does *not* stop at the
> setHiddenField point (whilst debugging). Restarted 3M7
> several times but to
> no avail.
> The only difference with the testForm is the fact that there
> is a .script
> involved with a <body> and <initialization> bit. Should i
> expect this to
> have any influence at all *and* when in the chain of events
> is it handled
> (the code in the .script)? The script span is at the very end
> of the .html.
>
> Here is a small snip of the code for the hiddenField.
>
> public String getHiddenField() {
> return _hiddenField;
> }
>
> public void setHiddenField(String value) {
> _hiddenField = "dynamic";
> _refreshPage =false;
> _dynamicallyExpandPage = true;
> }
>
> If anybody has a suggestion that would be great, this has
> kept me occupied
> now for approx 4 (long) days. :-((
>
> TIA
> Fermin DCG
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org