You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Norbert Sándor <pr...@hotmail.com> on 2004/04/22 09:45:44 UTC
Re: DirectLink's too long URLs freeze app + page lifecycle
I have a suggestion for this: a new link component (hopefully a modified
DirectLink) would store its parameters in hidden fields. It would render
like (only pseudo code):
somewhere in the page to prevent nested forms:
<form id="Direct0Params">
<input name="params" type="hidden" value="serialized parameters of
Direct0" />
...
</form>
the link would look like:
<a
href="javascript:document.getElementById('Direct0Params').submit();">link</a
>
This would solve the "encoded URL is too long" problem. Of course it could
be enhanced, for example DirectLink would check if the generated URL is too
long and use simple link if not, but use the method above if it is.
I think that combining this with my previous idea about (optionally) storing
hidden field values in a stack in the session would solve many current
problems!
Let's wait what the developers of Tapestry think about these 2 suggestions.
Norbi
----- Original Message -----
From: "Norbert Sándor" <pr...@hotmail.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Thursday, April 22, 2004 9:03 AM
Subject: Re: DirectLink's too long URLs freeze app
> This is a very bad behaviour. DirectLink parameters should contain only
> primitive types or very small serialized objects.
> I had the same problem when I used ONE java.util.Calendar as DirectLink
> parameter. I had to change it to Calendar.getTime().getTime() which is a
> long.
>
> This can be very uncomfortable and can be solved only by good component
> design.
>
> Norbi
>
> ----- Original Message -----
> From: "Vjeran Marcinko" <vj...@tis.hr>
> To: <ta...@jakarta.apache.org>
> Sent: Thursday, April 22, 2004 8:44 AM
> Subject: DirectLink's too long URLs freeze app
>
>
> > Hi again, and again ...
> >
> > My application using contrib:Tree got stuck because generated node's
links
> > are too long, and IE doesn't respond on the click.
> > I can see that url parameters come from getNodeContext() method inside
> > TreeNodeView.java, and there is some ComponentAddress that wrapps
> > TreeSourceModel.. I guess the explanation is in there but I cannot
figure
> > out what it doesn internally ?
> > I can also see that tree nodes gets serialized during rendering
> DirectLink.
> > Is this serialization always necessary (maybe because of this
> > ComponentAddress) ?
> >
> > HELP!! Any suggestions ? (BTW. My whole TreeModel is placed inside
Visit)
> >
> > Here is example of how long URL is :
> > <a
> >
>
href="/mgw-console/app?service=direct/1/Node/$Border.treeNodeView.direct&
> >
>
;sp=OH4sIAAAAAAAAAO1YXWwUVRS-s7stbSn0B2LDj0AAiRTZv8puKyZYWhKbLLTSRklL0tydudM
> >
>
dmJ0Z7r3b3SXB6IPB-GB4ENGgQX2QmJBoYqKGF8UHEl-MT6gPPhsl-Ioxxnjundnd2TLTn4DCQ-d
> >
>
hdn6-c-453z3nu7P32h3UwijadArP40qclQ1rLs4pIfEpOE1gXnj2u-gX_NXDV6NIyaEOB1NicfG
> >
>
coy05aZSQRglhlKgZHaw47Ax6GSH37MAI3QIcL3HDjL9IVG7Tny-dm3nl4KdKFEXHUI-KHawavDp
> >
>
mqZQUYYwx1ElMeTVilyw-g9Z6t6OYY442zMjREyaGscfzp8AlDIrcI1KiNUBcAOIe4ML3J650s71
> >
>
mBCGJ7eCox8RM5jNiFx3bAv8Q694CjXODxYtz5bhqW8w2iUvKiG1xapsjACP0mK2R0bPXb7HzZIv
> >
>
wSNHuMLvhPOMUq1yY3P5o2_a3bn99K4KiORSzcJFw1OtLZpJT4PNgDrW6ZHO0J1egCfCbAL8Jz6_
> >
>
Lt98vWKxlhI8UDFMTdqjLdSooT0wSQQ9H670MdrgpiInpa0xMzrBOE-15zAqA_8n8cfriL_3b3NR
> >
>
6Gijv_fXR1y6-_dWXT0cFmeVOoLP70HMu_WwRKiYw5RahTIR845mO6_3vd91wh9gXZnLE4lAZInJ
> >
>
sWC7vSrHv9V__uHo3giLTqKuA2WFCrCMVB1sa0XKoU_VYmKo6RJTguoo4d3LUVhtf3HfLc29T8Ao
> >
>
Ev3PxSEQA35x75_fylr8-j6CWewOYRr0GGzZNW3RGbUKCooJJJtKl6CZvkstMMxPu04Q7Hsxsj1H
> >
>
Ec-Q4YXaJqrLFmrKKgqG47AtIKCqfbeaoZd405uW4WwNgqIIUjlopmSMVURabPA5EOHE3HC_9T94
> >
>
8-efljzfejKA102j97CwkD92jkRFsqpDk7Cw5U8ImE7fNle11IcgI5lDk-RInjKMnghIfphRXx_X
> >
>
hGk4Ut0aYSg2HG7blkRc9TareZTslJhavwGP_Ih7dFI57YHAb4_UScaRQ7QpIfGE45j93Tn02rnw
> >
>
APbwUBcL17hnUXk-Zo-0zgQHWcxWBgIJJ2L2h1GEHrmbvTvSd_7CmZpsh-K2LWfz2xt_z7-154Vo
> >
>
EtS4r6qU4b1CXg-LCZqnBI0hNN-iSMS9pPlYq5gnl3hogFdlVOY5iQ3DIctwvrdZgDTqEsUAw8gE
> > 7MataaoHall0C9Jq8DV2
> >
>
KQfZinJaID9iRNyxtXKYQ6DQyddyH7tKwYVanwG9pruCUQH1jpi1gStKHWg8cMNyk3MMAOWrYmaV
> >
>
VAhoSgweBOowNDFNuhHCj9u0PoPeIq6MhsQY2e93vRGQR2HcwjKw6wC7JGgDgF4i5PQy_PUUQwdu
> >
>
IrLdceV4TAvMfsdgNpPPJFMZNYkHMwcITiaHNDI4kE4PpdUUIdjnCpZLxsrBfu5hMebYFEKKGmJ9
> >
>
bYqozaGGTaUkBzhqPWbTIvRIA7_WU8xJ4yypO8z4U2SEzhsqWSRFkhwg2XqKqTRJ63mczOskmdUH
> >
>
_WN5rsT6sWSDtLtrRWh5eu_DK5MvMXfdDcAEAdK0sLJp4KaMIvQELjohHsth1aUkHQHbIRTCI6Fx
> >
>
VVvg2myHWPth0V5sjRNPd8p3u5D7kfokqK343Sc11BfN8gRsEI6HKmDoEZav-pSsKtj9KVgQkU0i
> >
>
FhvIJB-iVXpmN6RtPTPh3LpPWsOqSSNNZTeFXHGjr2rk_HxP2lmoTFWNFx_k_5Qg9Vuh7tby85Ga
> >
>
vCdX_CtZDE_160UisQraFMJqWCTvmSzKpqKj2k6bqmZ1OrolUXLaVtoWhVFKUhXkFytOGBikuLDn
> >
>
P_wD-YtkDTSW4lCiIrZZVTbg_TVjAYfifsRX1XGft70CTGgw82l2FHhe94dHeuKqIzlJuMor6w_Y
> >
>
ij0Iz4TnibuTK7dQLJw6dfOrbHy6LDSHh-jEoew_l7feG7nrCpwVMmSpBFcc7KhWJbKnvqou7NrF
> > vLi7kqW8F2K0N7L9HZCC4dhgAAA..&sp=ANode%2F%24Border.treeView"
> > style="text-decoration: none">
> > <img
> >
>
src="/mgw-console/app?service=asset&sp=S%2Forg%2Fapache%2Ftapestry%2Fcon
> > trib%2Ftree%2Fcomponents%2Fminus.gif" border="0"/>
> > </a>
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: DirectLink's too long URLs freeze app + page lifecycle
Posted by Norbert Sándor <pr...@hotmail.com>.
That's why I'd like to put the form to a "safe" place, for example the Body
component would render these forms before any other component output.
Norbi
----- Original Message -----
From: "Erik Hatcher" <er...@ehatchersolutions.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Thursday, April 22, 2004 12:04 PM
Subject: Re: DirectLink's too long URLs freeze app + page lifecycle
With the caveat that you wouldn't nest this type of link within a
<form> itself, right? Nested forms is sort of a no-no, IIRC. With the
default DirectLink, it is safe to embed in forms.
Erik
On Apr 22, 2004, at 4:09 AM, Mindbridge wrote:
> In 3.0 it is easy to make another implementation of ILinkRenderer that
> stores the parameters as fields in a form, and the link then simply
> submits
> that form via JavaScript. This makes no difference in terms of the
> request
> management (all other code in Tapestry and the app remains the same).
> It
> just replaces the GET request with a POST and hence there is no
> limitation
> in terms of the parameter size anymore, since the POST is pretty much
> unlimited in that respect, unlike the GET.
>
> We do something similar in some cases at work, and it seems to work so
> far.
> In 3.0 only two changes to your code will be necessary:
> - the new renderer must be passed to the DirectLink component in
> question (there is a parameter for that)
> - the client must have JavaScript enabled, otherwise nothing
> happens
> (this is the problematic part)
>
> That new additional implementation of ILinkRenderer is relatively
> simple, it
> should be added to the standard Tapestry 3.1 distribution perhaps.
>
> ----- Original Message -----
> From: "Norbert Sándor" <pr...@hotmail.com>
> To: "Tapestry users" <ta...@jakarta.apache.org>
> Sent: Thursday, April 22, 2004 10:45 AM
> Subject: Re: DirectLink's too long URLs freeze app + page lifecycle
>
>
>> I have a suggestion for this: a new link component (hopefully a
>> modified
>> DirectLink) would store its parameters in hidden fields. It would
>> render
>> like (only pseudo code):
>>
>> somewhere in the page to prevent nested forms:
>> <form id="Direct0Params">
>> <input name="params" type="hidden" value="serialized
>> parameters of
>> Direct0" />
>> ...
>> </form>
>>
>> the link would look like:
>> <a
>>
> href="javascript:
> document.getElementById('Direct0Params').submit();">link</a
>>>
>>
>> This would solve the "encoded URL is too long" problem. Of course it
>> could
>> be enhanced, for example DirectLink would check if the generated URL
>> is
> too
>> long and use simple link if not, but use the method above if it is.
>>
>> I think that combining this with my previous idea about (optionally)
> storing
>> hidden field values in a stack in the session would solve many current
>> problems!
>>
>> Let's wait what the developers of Tapestry think about these 2
> suggestions.
>>
>> Norbi
>>
>> ----- Original Message -----
>> From: "Norbert Sándor" <pr...@hotmail.com>
>> To: "Tapestry users" <ta...@jakarta.apache.org>
>> Sent: Thursday, April 22, 2004 9:03 AM
>> Subject: Re: DirectLink's too long URLs freeze app
>>
>>
>>> This is a very bad behaviour. DirectLink parameters should contain
>>> only
>>> primitive types or very small serialized objects.
>>> I had the same problem when I used ONE java.util.Calendar as
>>> DirectLink
>>> parameter. I had to change it to Calendar.getTime().getTime() which
>>> is a
>>> long.
>>>
>>> This can be very uncomfortable and can be solved only by good
>>> component
>>> design.
>>>
>>> Norbi
>>>
>>> ----- Original Message -----
>>> From: "Vjeran Marcinko" <vj...@tis.hr>
>>> To: <ta...@jakarta.apache.org>
>>> Sent: Thursday, April 22, 2004 8:44 AM
>>> Subject: DirectLink's too long URLs freeze app
>>>
>>>
>>>> Hi again, and again ...
>>>>
>>>> My application using contrib:Tree got stuck because generated node's
>> links
>>>> are too long, and IE doesn't respond on the click.
>>>> I can see that url parameters come from getNodeContext() method
>>>> inside
>>>> TreeNodeView.java, and there is some ComponentAddress that wrapps
>>>> TreeSourceModel.. I guess the explanation is in there but I cannot
>> figure
>>>> out what it doesn internally ?
>>>> I can also see that tree nodes gets serialized during rendering
>>> DirectLink.
>>>> Is this serialization always necessary (maybe because of this
>>>> ComponentAddress) ?
>>>>
>>>> HELP!! Any suggestions ? (BTW. My whole TreeModel is placed inside
>> Visit)
>>>>
>>>> Here is example of how long URL is :
>>>> <a
>>>>
>>>
>>
> href="/mgw-console/app?service=direct/1/Node/
> $Border.treeNodeView.direct&
>>>>
>>>
>>
> ;sp=OH4sIAAAAAAAAAO1YXWwUVRS-
> s7stbSn0B2LDj0AAiRTZv8puKyZYWhKbLLTSRklL0tydudM
>>>>
>>>
>>
> dmJ0Z7r3b3SXB6IPB-GB4ENGgQX2QmJBoYqKGF8UHEl-MT6gPPhsl-
> Ioxxnjundnd2TLTn4DCQ-d
>>>>
>>>
>>
> hdn6-c-453z3nu7P32h3UwijadArP40qclQ1rLs4pIfEpOE1gXnj2u-
> gX_NXDV6NIyaEOB1NicfG
>>>>
>>>
>>
> coy05aZSQRglhlKgZHaw47Ax6GSH37MAI3QIcL3HDjL9IVG7Tny-dm3nl4KdKFEXHUI-
> KHawavDp
>>>>
>>>
>>
> mqZQUYYwx1ElMeTVilyw-
> g9Z6t6OYY442zMjREyaGscfzp8AlDIrcI1KiNUBcAOIe4ML3J650s71
>>>>
>>>
>>
> mBCGJ7eCox8RM5jNiFx3bAv8Q694CjXODxYtz5bhqW8w2iUvKiG1xapsjACP0mK2R0bPXb7
> HzZIv
>>>>
>>>
>>
> wSNHuMLvhPOMUq1yY3P5o2_a3bn99K4KiORSzcJFw1OtLZpJT4PNgDrW6ZHO0J1egCfCbAL
> 8Jz6_
>>>>
>>>
>>
> Lt98vWKxlhI8UDFMTdqjLdSooT0wSQQ9H670MdrgpiInpa0xMzrBOE
> -15zAqA_8n8cfriL_3b3NR
>>>>
>>>
>>
> 6Gijv_fXR1y6-
> _dWXT0cFmeVOoLP70HMu_WwRKiYw5RahTIR845mO6_3vd91wh9gXZnLE4lAZInJ
>>>>
>>>
>>
> sWC7vSrHv9V__uHo3giLTqKuA2WFCrCMVB1sa0XKoU_VYmKo6RJTguoo4d3LUVhtf3HfLc2
> 9T8Ao
>>>>
>>>
>>
> Ev3PxSEQA35x75_fylr8-
> j6CWewOYRr0GGzZNW3RGbUKCooJJJtKl6CZvkstMMxPu04Q7Hsxsj1H
>>>>
>>>
>>
> Ec-
> Q4YXaJqrLFmrKKgqG47AtIKCqfbeaoZd405uW4WwNgqIIUjlopmSMVURabPA5EOHE3HC_9T
> 94
>>>>
>>>
>>
> 8-efljzfejKA102j97CwkD92jkRFsqpDk7Cw5U8ImE7fNle11IcgI5lDk-
> RInjKMnghIfphRXx_X
>>>>
>>>
>>
> hGk4Ut0aYSg2HG7blkRc9TareZTslJhavwGP_Ih7dFI57YHAb4_UScaRQ7QpIfGE45j93Tn
> 02rnw
>>>>
>>>
>>
> APbwUBcL17hnUXk-Zo-0zgQHWcxWBgIJJ2L2h1GEHrmbvTvSd_7CmZpsh-
> K2LWfz2xt_z7-154Vo
>>>>
>>>
>>
> EtS4r6qU4b1CXg-LCZqnBI0hNN-
> iSMS9pPlYq5gnl3hogFdlVOY5iQ3DIctwvrdZgDTqEsUAw8gE
>>>> 7MataaoHall0C9Jq8DV2
>>>>
>>>
>>
> KQfZinJaID9iRNyxtXKYQ6DQyddyH7tKwYVanwG9pruCUQH1jpi1gStKHWg8cMNyk3MMAOW
> rYmaV
>>>>
>>>
>>
> VAhoSgweBOowNDFNuhHCj9u0PoPeIq6MhsQY2e93vRGQR2HcwjKw6wC7JGgDgF4i5PQy_PU
> UQwdu
>>>>
>>>
>>
> IrLdceV4TAvMfsdgNpPPJFMZNYkHMwcITiaHNDI4kE4PpdUUIdjnCpZLxsrBfu5hMebYFEK
> KGmJ9
>>>>
>>>
>>
> bYqozaGGTaUkBzhqPWbTIvRIA7_WU8xJ4yypO8z4U2SEzhsqWSRFkhwg2XqKqTRJ63mczOs
> kmdUH
>>>>
>>>
>>
> _WN5rsT6sWSDtLtrRWh5eu_DK5MvMXfdDcAEAdK0sLJp4KaMIvQELjohHsth1aUkHQHbIRT
> CI6Fx
>>>>
>>>
>>
> VVvg2myHWPth0V5sjRNPd8p3u5D7kfokqK343Sc11BfN8gRsEI6HKmDoEZav-
> pSsKtj9KVgQkU0i
>>>>
>>>
>>
> FhvIJB-
> iVXpmN6RtPTPh3LpPWsOqSSNNZTeFXHGjr2rk_HxP2lmoTFWNFx_k_5Qg9Vuh7tby85Ga
>>>>
>>>
>>
> vCdX_CtZDE_160UisQraFMJqWCTvmSzKpqKj2k6bqmZ1OrolUXLaVtoWhVFKUhXkFytOGBi
> kuLDn
>>>>
>>>
>>
> P_wD-
> YtkDTSW4lCiIrZZVTbg_TVjAYfifsRX1XGft70CTGgw82l2FHhe94dHeuKqIzlJuMor6w_Y
>>>>
>>>
>>
> ij0Iz4TnibuTK7dQLJw6dfOrbHy6LDSHh-
> jEoew_l7feG7nrCpwVMmSpBFcc7KhWJbKnvqou7NrF
>>>> vLi7kqW8F2K0N7L9HZCC4dhgAAA..&sp=ANode%2F%24Border.treeView"
>>>> style="text-decoration: none">
>>>> <img
>>>>
>>>
>>
> src="/mgw-console/app?service=asset&
> sp=S%2Forg%2Fapache%2Ftapestry%2Fcon
>>>> trib%2Ftree%2Fcomponents%2Fminus.gif" border="0"/>
>>>> </a>
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
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: DirectLink's too long URLs freeze app + page lifecycle
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Yeah, but it is a bit ambiguous isn't it? Should an outer form submit
the values of inner form fields?
Just did a quick Google and found this:
http://www.htmlhelp.com/reference/wilbur/block/form.html
It may be "legal", but it still seems awkward to me. Is there any
definitive explanation of how nested forms should behave?
Erik
On Apr 22, 2004, at 8:47 AM, Mind Bridge wrote:
> Hi,
>
> You can put a form in a form actually, as long as you use the div tag
> :)
>
> The following passes even the strictest tests on w3.org, if I remember
> correctly:
>
> <form action="POST">
> ...
> <div>
> <form action="/app">
> ...
> </form>
> </div>
> ...
> </form>
>
>
> We use the following at work, mostly to ensure that the form does not
> affect
> the page layout, but it also will make sure the HTML is valid:
>
> <div style="position: absolute">
> <form action="/app" method="POST" name="...">
> ...
> </form>
> </div>
>
> -mb
>
> -----Original Message-----
> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> Sent: Thursday, April 22, 2004 1:05 PM
> To: Tapestry users
> Subject: Re: DirectLink's too long URLs freeze app + page lifecycle
>
>
> With the caveat that you wouldn't nest this type of link within a
> <form> itself, right? Nested forms is sort of a no-no, IIRC. With the
> default DirectLink, it is safe to embed in forms.
>
> Erik
>
> On Apr 22, 2004, at 4:09 AM, Mindbridge wrote:
>
>> In 3.0 it is easy to make another implementation of ILinkRenderer that
>> stores the parameters as fields in a form, and the link then simply
>> submits
>> that form via JavaScript. This makes no difference in terms of the
>> request
>> management (all other code in Tapestry and the app remains the same).
>> It
>> just replaces the GET request with a POST and hence there is no
>> limitation
>> in terms of the parameter size anymore, since the POST is pretty much
>> unlimited in that respect, unlike the GET.
>>
>> We do something similar in some cases at work, and it seems to work so
>> far.
>> In 3.0 only two changes to your code will be necessary:
>> - the new renderer must be passed to the DirectLink component in
>> question (there is a parameter for that)
>> - the client must have JavaScript enabled, otherwise nothing
>> happens
>> (this is the problematic part)
>>
>> That new additional implementation of ILinkRenderer is relatively
>> simple, it
>> should be added to the standard Tapestry 3.1 distribution perhaps.
>>
>> ----- Original Message -----
>> From: "Norbert Sándor" <pr...@hotmail.com>
>> To: "Tapestry users" <ta...@jakarta.apache.org>
>> Sent: Thursday, April 22, 2004 10:45 AM
>> Subject: Re: DirectLink's too long URLs freeze app + page lifecycle
>>
>>
>>> I have a suggestion for this: a new link component (hopefully a
>>> modified
>>> DirectLink) would store its parameters in hidden fields. It would
>>> render
>>> like (only pseudo code):
>>>
>>> somewhere in the page to prevent nested forms:
>>> <form id="Direct0Params">
>>> <input name="params" type="hidden" value="serialized
>>> parameters of
>>> Direct0" />
>>> ...
>>> </form>
>>>
>>> the link would look like:
>>> <a
>>>
>> href="javascript:
>> document.getElementById('Direct0Params').submit();">link</a
>>>>
>>>
>>> This would solve the "encoded URL is too long" problem. Of course it
>>> could
>>> be enhanced, for example DirectLink would check if the generated URL
>>> is
>> too
>>> long and use simple link if not, but use the method above if it is.
>>>
>>> I think that combining this with my previous idea about (optionally)
>> storing
>>> hidden field values in a stack in the session would solve many
>>> current
>>> problems!
>>>
>>> Let's wait what the developers of Tapestry think about these 2
>> suggestions.
>>>
>>> Norbi
>>>
>>> ----- Original Message -----
>>> From: "Norbert Sándor" <pr...@hotmail.com>
>>> To: "Tapestry users" <ta...@jakarta.apache.org>
>>> Sent: Thursday, April 22, 2004 9:03 AM
>>> Subject: Re: DirectLink's too long URLs freeze app
>>>
>>>
>>>> This is a very bad behaviour. DirectLink parameters should contain
>>>> only
>>>> primitive types or very small serialized objects.
>>>> I had the same problem when I used ONE java.util.Calendar as
>>>> DirectLink
>>>> parameter. I had to change it to Calendar.getTime().getTime() which
>>>> is a
>>>> long.
>>>>
>>>> This can be very uncomfortable and can be solved only by good
>>>> component
>>>> design.
>>>>
>>>> Norbi
>>>>
>>>> ----- Original Message -----
>>>> From: "Vjeran Marcinko" <vj...@tis.hr>
>>>> To: <ta...@jakarta.apache.org>
>>>> Sent: Thursday, April 22, 2004 8:44 AM
>>>> Subject: DirectLink's too long URLs freeze app
>>>>
>>>>
>>>>> Hi again, and again ...
>>>>>
>>>>> My application using contrib:Tree got stuck because generated
>>>>> node's
>>> links
>>>>> are too long, and IE doesn't respond on the click.
>>>>> I can see that url parameters come from getNodeContext() method
>>>>> inside
>>>>> TreeNodeView.java, and there is some ComponentAddress that wrapps
>>>>> TreeSourceModel.. I guess the explanation is in there but I cannot
>>> figure
>>>>> out what it doesn internally ?
>>>>> I can also see that tree nodes gets serialized during rendering
>>>> DirectLink.
>>>>> Is this serialization always necessary (maybe because of this
>>>>> ComponentAddress) ?
>>>>>
>>>>> HELP!! Any suggestions ? (BTW. My whole TreeModel is placed inside
>>> Visit)
>>>>>
>>>>> Here is example of how long URL is :
>>>>> <a
>>>>>
>>>>
>>>
>> href="/mgw-console/app?service=direct/1/Node/
>> $Border.treeNodeView.direct&
>>>>>
>>>>
>>>
>> ;sp=OH4sIAAAAAAAAAO1YXWwUVRS-
>> s7stbSn0B2LDj0AAiRTZv8puKyZYWhKbLLTSRklL0tydudM
>>>>>
>>>>
>>>
>> dmJ0Z7r3b3SXB6IPB-GB4ENGgQX2QmJBoYqKGF8UHEl-MT6gPPhsl-
>> Ioxxnjundnd2TLTn4DCQ-d
>>>>>
>>>>
>>>
>> hdn6-c-453z3nu7P32h3UwijadArP40qclQ1rLs4pIfEpOE1gXnj2u-
>> gX_NXDV6NIyaEOB1NicfG
>>>>>
>>>>
>>>
>> coy05aZSQRglhlKgZHaw47Ax6GSH37MAI3QIcL3HDjL9IVG7Tny-dm3nl4KdKFEXHUI-
>> KHawavDp
>>>>>
>>>>
>>>
>> mqZQUYYwx1ElMeTVilyw-
>> g9Z6t6OYY442zMjREyaGscfzp8AlDIrcI1KiNUBcAOIe4ML3J650s71
>>>>>
>>>>
>>>
>> mBCGJ7eCox8RM5jNiFx3bAv8Q694CjXODxYtz5bhqW8w2iUvKiG1xapsjACP0mK2R0bPXb
>> 7
>> HzZIv
>>>>>
>>>>
>>>
>> wSNHuMLvhPOMUq1yY3P5o2_a3bn99K4KiORSzcJFw1OtLZpJT4PNgDrW6ZHO0J1egCfCbA
>> L
>> 8Jz6_
>>>>>
>>>>
>>>
>> Lt98vWKxlhI8UDFMTdqjLdSooT0wSQQ9H670MdrgpiInpa0xMzrBOE
>> -15zAqA_8n8cfriL_3b3NR
>>>>>
>>>>
>>>
>> 6Gijv_fXR1y6-
>> _dWXT0cFmeVOoLP70HMu_WwRKiYw5RahTIR845mO6_3vd91wh9gXZnLE4lAZInJ
>>>>>
>>>>
>>>
>> sWC7vSrHv9V__uHo3giLTqKuA2WFCrCMVB1sa0XKoU_VYmKo6RJTguoo4d3LUVhtf3HfLc
>> 2
>> 9T8Ao
>>>>>
>>>>
>>>
>> Ev3PxSEQA35x75_fylr8-
>> j6CWewOYRr0GGzZNW3RGbUKCooJJJtKl6CZvkstMMxPu04Q7Hsxsj1H
>>>>>
>>>>
>>>
>> Ec-
>> Q4YXaJqrLFmrKKgqG47AtIKCqfbeaoZd405uW4WwNgqIIUjlopmSMVURabPA5EOHE3HC_9
>> T
>> 94
>>>>>
>>>>
>>>
>> 8-efljzfejKA102j97CwkD92jkRFsqpDk7Cw5U8ImE7fNle11IcgI5lDk-
>> RInjKMnghIfphRXx_X
>>>>>
>>>>
>>>
>> hGk4Ut0aYSg2HG7blkRc9TareZTslJhavwGP_Ih7dFI57YHAb4_UScaRQ7QpIfGE45j93T
>> n
>> 02rnw
>>>>>
>>>>
>>>
>> APbwUBcL17hnUXk-Zo-0zgQHWcxWBgIJJ2L2h1GEHrmbvTvSd_7CmZpsh-
>> K2LWfz2xt_z7-154Vo
>>>>>
>>>>
>>>
>> EtS4r6qU4b1CXg-LCZqnBI0hNN-
>> iSMS9pPlYq5gnl3hogFdlVOY5iQ3DIctwvrdZgDTqEsUAw8gE
>>>>> 7MataaoHall0C9Jq8DV2
>>>>>
>>>>
>>>
>> KQfZinJaID9iRNyxtXKYQ6DQyddyH7tKwYVanwG9pruCUQH1jpi1gStKHWg8cMNyk3MMAO
>> W
>> rYmaV
>>>>>
>>>>
>>>
>> VAhoSgweBOowNDFNuhHCj9u0PoPeIq6MhsQY2e93vRGQR2HcwjKw6wC7JGgDgF4i5PQy_P
>> U
>> UQwdu
>>>>>
>>>>
>>>
>> IrLdceV4TAvMfsdgNpPPJFMZNYkHMwcITiaHNDI4kE4PpdUUIdjnCpZLxsrBfu5hMebYFE
>> K
>> KGmJ9
>>>>>
>>>>
>>>
>> bYqozaGGTaUkBzhqPWbTIvRIA7_WU8xJ4yypO8z4U2SEzhsqWSRFkhwg2XqKqTRJ63mczO
>> s
>> kmdUH
>>>>>
>>>>
>>>
>> _WN5rsT6sWSDtLtrRWh5eu_DK5MvMXfdDcAEAdK0sLJp4KaMIvQELjohHsth1aUkHQHbIR
>> T
>> CI6Fx
>>>>>
>>>>
>>>
>> VVvg2myHWPth0V5sjRNPd8p3u5D7kfokqK343Sc11BfN8gRsEI6HKmDoEZav-
>> pSsKtj9KVgQkU0i
>>>>>
>>>>
>>>
>> FhvIJB-
>> iVXpmN6RtPTPh3LpPWsOqSSNNZTeFXHGjr2rk_HxP2lmoTFWNFx_k_5Qg9Vuh7tby85Ga
>>>>>
>>>>
>>>
>> vCdX_CtZDE_160UisQraFMJqWCTvmSzKpqKj2k6bqmZ1OrolUXLaVtoWhVFKUhXkFytOGB
>> i
>> kuLDn
>>>>>
>>>>
>>>
>> P_wD-
>> YtkDTSW4lCiIrZZVTbg_TVjAYfifsRX1XGft70CTGgw82l2FHhe94dHeuKqIzlJuMor6w_
>> Y
>>>>>
>>>>
>>>
>> ij0Iz4TnibuTK7dQLJw6dfOrbHy6LDSHh-
>> jEoew_l7feG7nrCpwVMmSpBFcc7KhWJbKnvqou7NrF
>>>>> vLi7kqW8F2K0N7L9HZCC4dhgAAA..&sp=ANode%2F%24Border.treeView"
>>>>> style="text-decoration: none">
>>>>> <img
>>>>>
>>>>
>>>
>> src="/mgw-console/app?service=asset&
>> sp=S%2Forg%2Fapache%2Ftapestry%2Fcon
>>>>> trib%2Ftree%2Fcomponents%2Fminus.gif" border="0"/>
>>>>> </a>
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------
>>>>> -
>>>>> -
>>>>> 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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: DirectLink's too long URLs freeze app + page lifecycle
Posted by Norbert Sándor <pr...@hotmail.com>.
I didn't know.
(But this may broke the page layout because of browser CSS differences.)
Norbi
----- Original Message -----
From: "Mind Bridge" <mi...@yahoo.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Thursday, April 22, 2004 2:47 PM
Subject: RE: DirectLink's too long URLs freeze app + page lifecycle
> Hi,
>
> You can put a form in a form actually, as long as you use the div tag :)
>
> The following passes even the strictest tests on w3.org, if I remember
> correctly:
>
> <form action="POST">
> ...
> <div>
> <form action="/app">
> ...
> </form>
> </div>
> ...
> </form>
>
>
> We use the following at work, mostly to ensure that the form does not
affect
> the page layout, but it also will make sure the HTML is valid:
>
> <div style="position: absolute">
> <form action="/app" method="POST" name="...">
> ...
> </form>
> </div>
>
> -mb
>
> -----Original Message-----
> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> Sent: Thursday, April 22, 2004 1:05 PM
> To: Tapestry users
> Subject: Re: DirectLink's too long URLs freeze app + page lifecycle
>
>
> With the caveat that you wouldn't nest this type of link within a
> <form> itself, right? Nested forms is sort of a no-no, IIRC. With the
> default DirectLink, it is safe to embed in forms.
>
> Erik
>
> On Apr 22, 2004, at 4:09 AM, Mindbridge wrote:
>
> > In 3.0 it is easy to make another implementation of ILinkRenderer that
> > stores the parameters as fields in a form, and the link then simply
> > submits
> > that form via JavaScript. This makes no difference in terms of the
> > request
> > management (all other code in Tapestry and the app remains the same).
> > It
> > just replaces the GET request with a POST and hence there is no
> > limitation
> > in terms of the parameter size anymore, since the POST is pretty much
> > unlimited in that respect, unlike the GET.
> >
> > We do something similar in some cases at work, and it seems to work so
> > far.
> > In 3.0 only two changes to your code will be necessary:
> > - the new renderer must be passed to the DirectLink component in
> > question (there is a parameter for that)
> > - the client must have JavaScript enabled, otherwise nothing
> > happens
> > (this is the problematic part)
> >
> > That new additional implementation of ILinkRenderer is relatively
> > simple, it
> > should be added to the standard Tapestry 3.1 distribution perhaps.
> >
> > ----- Original Message -----
> > From: "Norbert Sándor" <pr...@hotmail.com>
> > To: "Tapestry users" <ta...@jakarta.apache.org>
> > Sent: Thursday, April 22, 2004 10:45 AM
> > Subject: Re: DirectLink's too long URLs freeze app + page lifecycle
> >
> >
> >> I have a suggestion for this: a new link component (hopefully a
> >> modified
> >> DirectLink) would store its parameters in hidden fields. It would
> >> render
> >> like (only pseudo code):
> >>
> >> somewhere in the page to prevent nested forms:
> >> <form id="Direct0Params">
> >> <input name="params" type="hidden" value="serialized
> >> parameters of
> >> Direct0" />
> >> ...
> >> </form>
> >>
> >> the link would look like:
> >> <a
> >>
> > href="javascript:
> > document.getElementById('Direct0Params').submit();">link</a
> >>>
> >>
> >> This would solve the "encoded URL is too long" problem. Of course it
> >> could
> >> be enhanced, for example DirectLink would check if the generated URL
> >> is
> > too
> >> long and use simple link if not, but use the method above if it is.
> >>
> >> I think that combining this with my previous idea about (optionally)
> > storing
> >> hidden field values in a stack in the session would solve many current
> >> problems!
> >>
> >> Let's wait what the developers of Tapestry think about these 2
> > suggestions.
> >>
> >> Norbi
> >>
> >> ----- Original Message -----
> >> From: "Norbert Sándor" <pr...@hotmail.com>
> >> To: "Tapestry users" <ta...@jakarta.apache.org>
> >> Sent: Thursday, April 22, 2004 9:03 AM
> >> Subject: Re: DirectLink's too long URLs freeze app
> >>
> >>
> >>> This is a very bad behaviour. DirectLink parameters should contain
> >>> only
> >>> primitive types or very small serialized objects.
> >>> I had the same problem when I used ONE java.util.Calendar as
> >>> DirectLink
> >>> parameter. I had to change it to Calendar.getTime().getTime() which
> >>> is a
> >>> long.
> >>>
> >>> This can be very uncomfortable and can be solved only by good
> >>> component
> >>> design.
> >>>
> >>> Norbi
> >>>
> >>> ----- Original Message -----
> >>> From: "Vjeran Marcinko" <vj...@tis.hr>
> >>> To: <ta...@jakarta.apache.org>
> >>> Sent: Thursday, April 22, 2004 8:44 AM
> >>> Subject: DirectLink's too long URLs freeze app
> >>>
> >>>
> >>>> Hi again, and again ...
> >>>>
> >>>> My application using contrib:Tree got stuck because generated node's
> >> links
> >>>> are too long, and IE doesn't respond on the click.
> >>>> I can see that url parameters come from getNodeContext() method
> >>>> inside
> >>>> TreeNodeView.java, and there is some ComponentAddress that wrapps
> >>>> TreeSourceModel.. I guess the explanation is in there but I cannot
> >> figure
> >>>> out what it doesn internally ?
> >>>> I can also see that tree nodes gets serialized during rendering
> >>> DirectLink.
> >>>> Is this serialization always necessary (maybe because of this
> >>>> ComponentAddress) ?
> >>>>
> >>>> HELP!! Any suggestions ? (BTW. My whole TreeModel is placed inside
> >> Visit)
> >>>>
> >>>> Here is example of how long URL is :
> >>>> <a
> >>>>
> >>>
> >>
> > href="/mgw-console/app?service=direct/1/Node/
> > $Border.treeNodeView.direct&
> >>>>
> >>>
> >>
> > ;sp=OH4sIAAAAAAAAAO1YXWwUVRS-
> > s7stbSn0B2LDj0AAiRTZv8puKyZYWhKbLLTSRklL0tydudM
> >>>>
> >>>
> >>
> > dmJ0Z7r3b3SXB6IPB-GB4ENGgQX2QmJBoYqKGF8UHEl-MT6gPPhsl-
> > Ioxxnjundnd2TLTn4DCQ-d
> >>>>
> >>>
> >>
> > hdn6-c-453z3nu7P32h3UwijadArP40qclQ1rLs4pIfEpOE1gXnj2u-
> > gX_NXDV6NIyaEOB1NicfG
> >>>>
> >>>
> >>
> > coy05aZSQRglhlKgZHaw47Ax6GSH37MAI3QIcL3HDjL9IVG7Tny-dm3nl4KdKFEXHUI-
> > KHawavDp
> >>>>
> >>>
> >>
> > mqZQUYYwx1ElMeTVilyw-
> > g9Z6t6OYY442zMjREyaGscfzp8AlDIrcI1KiNUBcAOIe4ML3J650s71
> >>>>
> >>>
> >>
> > mBCGJ7eCox8RM5jNiFx3bAv8Q694CjXODxYtz5bhqW8w2iUvKiG1xapsjACP0mK2R0bPXb7
> > HzZIv
> >>>>
> >>>
> >>
> > wSNHuMLvhPOMUq1yY3P5o2_a3bn99K4KiORSzcJFw1OtLZpJT4PNgDrW6ZHO0J1egCfCbAL
> > 8Jz6_
> >>>>
> >>>
> >>
> > Lt98vWKxlhI8UDFMTdqjLdSooT0wSQQ9H670MdrgpiInpa0xMzrBOE
> > -15zAqA_8n8cfriL_3b3NR
> >>>>
> >>>
> >>
> > 6Gijv_fXR1y6-
> > _dWXT0cFmeVOoLP70HMu_WwRKiYw5RahTIR845mO6_3vd91wh9gXZnLE4lAZInJ
> >>>>
> >>>
> >>
> > sWC7vSrHv9V__uHo3giLTqKuA2WFCrCMVB1sa0XKoU_VYmKo6RJTguoo4d3LUVhtf3HfLc2
> > 9T8Ao
> >>>>
> >>>
> >>
> > Ev3PxSEQA35x75_fylr8-
> > j6CWewOYRr0GGzZNW3RGbUKCooJJJtKl6CZvkstMMxPu04Q7Hsxsj1H
> >>>>
> >>>
> >>
> > Ec-
> > Q4YXaJqrLFmrKKgqG47AtIKCqfbeaoZd405uW4WwNgqIIUjlopmSMVURabPA5EOHE3HC_9T
> > 94
> >>>>
> >>>
> >>
> > 8-efljzfejKA102j97CwkD92jkRFsqpDk7Cw5U8ImE7fNle11IcgI5lDk-
> > RInjKMnghIfphRXx_X
> >>>>
> >>>
> >>
> > hGk4Ut0aYSg2HG7blkRc9TareZTslJhavwGP_Ih7dFI57YHAb4_UScaRQ7QpIfGE45j93Tn
> > 02rnw
> >>>>
> >>>
> >>
> > APbwUBcL17hnUXk-Zo-0zgQHWcxWBgIJJ2L2h1GEHrmbvTvSd_7CmZpsh-
> > K2LWfz2xt_z7-154Vo
> >>>>
> >>>
> >>
> > EtS4r6qU4b1CXg-LCZqnBI0hNN-
> > iSMS9pPlYq5gnl3hogFdlVOY5iQ3DIctwvrdZgDTqEsUAw8gE
> >>>> 7MataaoHall0C9Jq8DV2
> >>>>
> >>>
> >>
> > KQfZinJaID9iRNyxtXKYQ6DQyddyH7tKwYVanwG9pruCUQH1jpi1gStKHWg8cMNyk3MMAOW
> > rYmaV
> >>>>
> >>>
> >>
> > VAhoSgweBOowNDFNuhHCj9u0PoPeIq6MhsQY2e93vRGQR2HcwjKw6wC7JGgDgF4i5PQy_PU
> > UQwdu
> >>>>
> >>>
> >>
> > IrLdceV4TAvMfsdgNpPPJFMZNYkHMwcITiaHNDI4kE4PpdUUIdjnCpZLxsrBfu5hMebYFEK
> > KGmJ9
> >>>>
> >>>
> >>
> > bYqozaGGTaUkBzhqPWbTIvRIA7_WU8xJ4yypO8z4U2SEzhsqWSRFkhwg2XqKqTRJ63mczOs
> > kmdUH
> >>>>
> >>>
> >>
> > _WN5rsT6sWSDtLtrRWh5eu_DK5MvMXfdDcAEAdK0sLJp4KaMIvQELjohHsth1aUkHQHbIRT
> > CI6Fx
> >>>>
> >>>
> >>
> > VVvg2myHWPth0V5sjRNPd8p3u5D7kfokqK343Sc11BfN8gRsEI6HKmDoEZav-
> > pSsKtj9KVgQkU0i
> >>>>
> >>>
> >>
> > FhvIJB-
> > iVXpmN6RtPTPh3LpPWsOqSSNNZTeFXHGjr2rk_HxP2lmoTFWNFx_k_5Qg9Vuh7tby85Ga
> >>>>
> >>>
> >>
> > vCdX_CtZDE_160UisQraFMJqWCTvmSzKpqKj2k6bqmZ1OrolUXLaVtoWhVFKUhXkFytOGBi
> > kuLDn
> >>>>
> >>>
> >>
> > P_wD-
> > YtkDTSW4lCiIrZZVTbg_TVjAYfifsRX1XGft70CTGgw82l2FHhe94dHeuKqIzlJuMor6w_Y
> >>>>
> >>>
> >>
> > ij0Iz4TnibuTK7dQLJw6dfOrbHy6LDSHh-
> > jEoew_l7feG7nrCpwVMmSpBFcc7KhWJbKnvqou7NrF
> >>>> vLi7kqW8F2K0N7L9HZCC4dhgAAA..&sp=ANode%2F%24Border.treeView"
> >>>> style="text-decoration: none">
> >>>> <img
> >>>>
> >>>
> >>
> > src="/mgw-console/app?service=asset&
> > sp=S%2Forg%2Fapache%2Ftapestry%2Fcon
> >>>> trib%2Ftree%2Fcomponents%2Fminus.gif" border="0"/>
> >>>> </a>
> >>>>
> >>>>
> >>>> --------------------------------------------------------------------
> >>>> -
> >>>> 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
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: DirectLink's too long URLs freeze app + page lifecycle
Posted by Mind Bridge <mi...@yahoo.com>.
Hi,
You can put a form in a form actually, as long as you use the div tag :)
The following passes even the strictest tests on w3.org, if I remember
correctly:
<form action="POST">
...
<div>
<form action="/app">
...
</form>
</div>
...
</form>
We use the following at work, mostly to ensure that the form does not affect
the page layout, but it also will make sure the HTML is valid:
<div style="position: absolute">
<form action="/app" method="POST" name="...">
...
</form>
</div>
-mb
-----Original Message-----
From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
Sent: Thursday, April 22, 2004 1:05 PM
To: Tapestry users
Subject: Re: DirectLink's too long URLs freeze app + page lifecycle
With the caveat that you wouldn't nest this type of link within a
<form> itself, right? Nested forms is sort of a no-no, IIRC. With the
default DirectLink, it is safe to embed in forms.
Erik
On Apr 22, 2004, at 4:09 AM, Mindbridge wrote:
> In 3.0 it is easy to make another implementation of ILinkRenderer that
> stores the parameters as fields in a form, and the link then simply
> submits
> that form via JavaScript. This makes no difference in terms of the
> request
> management (all other code in Tapestry and the app remains the same).
> It
> just replaces the GET request with a POST and hence there is no
> limitation
> in terms of the parameter size anymore, since the POST is pretty much
> unlimited in that respect, unlike the GET.
>
> We do something similar in some cases at work, and it seems to work so
> far.
> In 3.0 only two changes to your code will be necessary:
> - the new renderer must be passed to the DirectLink component in
> question (there is a parameter for that)
> - the client must have JavaScript enabled, otherwise nothing
> happens
> (this is the problematic part)
>
> That new additional implementation of ILinkRenderer is relatively
> simple, it
> should be added to the standard Tapestry 3.1 distribution perhaps.
>
> ----- Original Message -----
> From: "Norbert Sándor" <pr...@hotmail.com>
> To: "Tapestry users" <ta...@jakarta.apache.org>
> Sent: Thursday, April 22, 2004 10:45 AM
> Subject: Re: DirectLink's too long URLs freeze app + page lifecycle
>
>
>> I have a suggestion for this: a new link component (hopefully a
>> modified
>> DirectLink) would store its parameters in hidden fields. It would
>> render
>> like (only pseudo code):
>>
>> somewhere in the page to prevent nested forms:
>> <form id="Direct0Params">
>> <input name="params" type="hidden" value="serialized
>> parameters of
>> Direct0" />
>> ...
>> </form>
>>
>> the link would look like:
>> <a
>>
> href="javascript:
> document.getElementById('Direct0Params').submit();">link</a
>>>
>>
>> This would solve the "encoded URL is too long" problem. Of course it
>> could
>> be enhanced, for example DirectLink would check if the generated URL
>> is
> too
>> long and use simple link if not, but use the method above if it is.
>>
>> I think that combining this with my previous idea about (optionally)
> storing
>> hidden field values in a stack in the session would solve many current
>> problems!
>>
>> Let's wait what the developers of Tapestry think about these 2
> suggestions.
>>
>> Norbi
>>
>> ----- Original Message -----
>> From: "Norbert Sándor" <pr...@hotmail.com>
>> To: "Tapestry users" <ta...@jakarta.apache.org>
>> Sent: Thursday, April 22, 2004 9:03 AM
>> Subject: Re: DirectLink's too long URLs freeze app
>>
>>
>>> This is a very bad behaviour. DirectLink parameters should contain
>>> only
>>> primitive types or very small serialized objects.
>>> I had the same problem when I used ONE java.util.Calendar as
>>> DirectLink
>>> parameter. I had to change it to Calendar.getTime().getTime() which
>>> is a
>>> long.
>>>
>>> This can be very uncomfortable and can be solved only by good
>>> component
>>> design.
>>>
>>> Norbi
>>>
>>> ----- Original Message -----
>>> From: "Vjeran Marcinko" <vj...@tis.hr>
>>> To: <ta...@jakarta.apache.org>
>>> Sent: Thursday, April 22, 2004 8:44 AM
>>> Subject: DirectLink's too long URLs freeze app
>>>
>>>
>>>> Hi again, and again ...
>>>>
>>>> My application using contrib:Tree got stuck because generated node's
>> links
>>>> are too long, and IE doesn't respond on the click.
>>>> I can see that url parameters come from getNodeContext() method
>>>> inside
>>>> TreeNodeView.java, and there is some ComponentAddress that wrapps
>>>> TreeSourceModel.. I guess the explanation is in there but I cannot
>> figure
>>>> out what it doesn internally ?
>>>> I can also see that tree nodes gets serialized during rendering
>>> DirectLink.
>>>> Is this serialization always necessary (maybe because of this
>>>> ComponentAddress) ?
>>>>
>>>> HELP!! Any suggestions ? (BTW. My whole TreeModel is placed inside
>> Visit)
>>>>
>>>> Here is example of how long URL is :
>>>> <a
>>>>
>>>
>>
> href="/mgw-console/app?service=direct/1/Node/
> $Border.treeNodeView.direct&
>>>>
>>>
>>
> ;sp=OH4sIAAAAAAAAAO1YXWwUVRS-
> s7stbSn0B2LDj0AAiRTZv8puKyZYWhKbLLTSRklL0tydudM
>>>>
>>>
>>
> dmJ0Z7r3b3SXB6IPB-GB4ENGgQX2QmJBoYqKGF8UHEl-MT6gPPhsl-
> Ioxxnjundnd2TLTn4DCQ-d
>>>>
>>>
>>
> hdn6-c-453z3nu7P32h3UwijadArP40qclQ1rLs4pIfEpOE1gXnj2u-
> gX_NXDV6NIyaEOB1NicfG
>>>>
>>>
>>
> coy05aZSQRglhlKgZHaw47Ax6GSH37MAI3QIcL3HDjL9IVG7Tny-dm3nl4KdKFEXHUI-
> KHawavDp
>>>>
>>>
>>
> mqZQUYYwx1ElMeTVilyw-
> g9Z6t6OYY442zMjREyaGscfzp8AlDIrcI1KiNUBcAOIe4ML3J650s71
>>>>
>>>
>>
> mBCGJ7eCox8RM5jNiFx3bAv8Q694CjXODxYtz5bhqW8w2iUvKiG1xapsjACP0mK2R0bPXb7
> HzZIv
>>>>
>>>
>>
> wSNHuMLvhPOMUq1yY3P5o2_a3bn99K4KiORSzcJFw1OtLZpJT4PNgDrW6ZHO0J1egCfCbAL
> 8Jz6_
>>>>
>>>
>>
> Lt98vWKxlhI8UDFMTdqjLdSooT0wSQQ9H670MdrgpiInpa0xMzrBOE
> -15zAqA_8n8cfriL_3b3NR
>>>>
>>>
>>
> 6Gijv_fXR1y6-
> _dWXT0cFmeVOoLP70HMu_WwRKiYw5RahTIR845mO6_3vd91wh9gXZnLE4lAZInJ
>>>>
>>>
>>
> sWC7vSrHv9V__uHo3giLTqKuA2WFCrCMVB1sa0XKoU_VYmKo6RJTguoo4d3LUVhtf3HfLc2
> 9T8Ao
>>>>
>>>
>>
> Ev3PxSEQA35x75_fylr8-
> j6CWewOYRr0GGzZNW3RGbUKCooJJJtKl6CZvkstMMxPu04Q7Hsxsj1H
>>>>
>>>
>>
> Ec-
> Q4YXaJqrLFmrKKgqG47AtIKCqfbeaoZd405uW4WwNgqIIUjlopmSMVURabPA5EOHE3HC_9T
> 94
>>>>
>>>
>>
> 8-efljzfejKA102j97CwkD92jkRFsqpDk7Cw5U8ImE7fNle11IcgI5lDk-
> RInjKMnghIfphRXx_X
>>>>
>>>
>>
> hGk4Ut0aYSg2HG7blkRc9TareZTslJhavwGP_Ih7dFI57YHAb4_UScaRQ7QpIfGE45j93Tn
> 02rnw
>>>>
>>>
>>
> APbwUBcL17hnUXk-Zo-0zgQHWcxWBgIJJ2L2h1GEHrmbvTvSd_7CmZpsh-
> K2LWfz2xt_z7-154Vo
>>>>
>>>
>>
> EtS4r6qU4b1CXg-LCZqnBI0hNN-
> iSMS9pPlYq5gnl3hogFdlVOY5iQ3DIctwvrdZgDTqEsUAw8gE
>>>> 7MataaoHall0C9Jq8DV2
>>>>
>>>
>>
> KQfZinJaID9iRNyxtXKYQ6DQyddyH7tKwYVanwG9pruCUQH1jpi1gStKHWg8cMNyk3MMAOW
> rYmaV
>>>>
>>>
>>
> VAhoSgweBOowNDFNuhHCj9u0PoPeIq6MhsQY2e93vRGQR2HcwjKw6wC7JGgDgF4i5PQy_PU
> UQwdu
>>>>
>>>
>>
> IrLdceV4TAvMfsdgNpPPJFMZNYkHMwcITiaHNDI4kE4PpdUUIdjnCpZLxsrBfu5hMebYFEK
> KGmJ9
>>>>
>>>
>>
> bYqozaGGTaUkBzhqPWbTIvRIA7_WU8xJ4yypO8z4U2SEzhsqWSRFkhwg2XqKqTRJ63mczOs
> kmdUH
>>>>
>>>
>>
> _WN5rsT6sWSDtLtrRWh5eu_DK5MvMXfdDcAEAdK0sLJp4KaMIvQELjohHsth1aUkHQHbIRT
> CI6Fx
>>>>
>>>
>>
> VVvg2myHWPth0V5sjRNPd8p3u5D7kfokqK343Sc11BfN8gRsEI6HKmDoEZav-
> pSsKtj9KVgQkU0i
>>>>
>>>
>>
> FhvIJB-
> iVXpmN6RtPTPh3LpPWsOqSSNNZTeFXHGjr2rk_HxP2lmoTFWNFx_k_5Qg9Vuh7tby85Ga
>>>>
>>>
>>
> vCdX_CtZDE_160UisQraFMJqWCTvmSzKpqKj2k6bqmZ1OrolUXLaVtoWhVFKUhXkFytOGBi
> kuLDn
>>>>
>>>
>>
> P_wD-
> YtkDTSW4lCiIrZZVTbg_TVjAYfifsRX1XGft70CTGgw82l2FHhe94dHeuKqIzlJuMor6w_Y
>>>>
>>>
>>
> ij0Iz4TnibuTK7dQLJw6dfOrbHy6LDSHh-
> jEoew_l7feG7nrCpwVMmSpBFcc7KhWJbKnvqou7NrF
>>>> vLi7kqW8F2K0N7L9HZCC4dhgAAA..&sp=ANode%2F%24Border.treeView"
>>>> style="text-decoration: none">
>>>> <img
>>>>
>>>
>>
> src="/mgw-console/app?service=asset&
> sp=S%2Forg%2Fapache%2Ftapestry%2Fcon
>>>> trib%2Ftree%2Fcomponents%2Fminus.gif" border="0"/>
>>>> </a>
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
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: DirectLink's too long URLs freeze app + page lifecycle
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
With the caveat that you wouldn't nest this type of link within a
<form> itself, right? Nested forms is sort of a no-no, IIRC. With the
default DirectLink, it is safe to embed in forms.
Erik
On Apr 22, 2004, at 4:09 AM, Mindbridge wrote:
> In 3.0 it is easy to make another implementation of ILinkRenderer that
> stores the parameters as fields in a form, and the link then simply
> submits
> that form via JavaScript. This makes no difference in terms of the
> request
> management (all other code in Tapestry and the app remains the same).
> It
> just replaces the GET request with a POST and hence there is no
> limitation
> in terms of the parameter size anymore, since the POST is pretty much
> unlimited in that respect, unlike the GET.
>
> We do something similar in some cases at work, and it seems to work so
> far.
> In 3.0 only two changes to your code will be necessary:
> - the new renderer must be passed to the DirectLink component in
> question (there is a parameter for that)
> - the client must have JavaScript enabled, otherwise nothing
> happens
> (this is the problematic part)
>
> That new additional implementation of ILinkRenderer is relatively
> simple, it
> should be added to the standard Tapestry 3.1 distribution perhaps.
>
> ----- Original Message -----
> From: "Norbert Sándor" <pr...@hotmail.com>
> To: "Tapestry users" <ta...@jakarta.apache.org>
> Sent: Thursday, April 22, 2004 10:45 AM
> Subject: Re: DirectLink's too long URLs freeze app + page lifecycle
>
>
>> I have a suggestion for this: a new link component (hopefully a
>> modified
>> DirectLink) would store its parameters in hidden fields. It would
>> render
>> like (only pseudo code):
>>
>> somewhere in the page to prevent nested forms:
>> <form id="Direct0Params">
>> <input name="params" type="hidden" value="serialized
>> parameters of
>> Direct0" />
>> ...
>> </form>
>>
>> the link would look like:
>> <a
>>
> href="javascript:
> document.getElementById('Direct0Params').submit();">link</a
>>>
>>
>> This would solve the "encoded URL is too long" problem. Of course it
>> could
>> be enhanced, for example DirectLink would check if the generated URL
>> is
> too
>> long and use simple link if not, but use the method above if it is.
>>
>> I think that combining this with my previous idea about (optionally)
> storing
>> hidden field values in a stack in the session would solve many current
>> problems!
>>
>> Let's wait what the developers of Tapestry think about these 2
> suggestions.
>>
>> Norbi
>>
>> ----- Original Message -----
>> From: "Norbert Sándor" <pr...@hotmail.com>
>> To: "Tapestry users" <ta...@jakarta.apache.org>
>> Sent: Thursday, April 22, 2004 9:03 AM
>> Subject: Re: DirectLink's too long URLs freeze app
>>
>>
>>> This is a very bad behaviour. DirectLink parameters should contain
>>> only
>>> primitive types or very small serialized objects.
>>> I had the same problem when I used ONE java.util.Calendar as
>>> DirectLink
>>> parameter. I had to change it to Calendar.getTime().getTime() which
>>> is a
>>> long.
>>>
>>> This can be very uncomfortable and can be solved only by good
>>> component
>>> design.
>>>
>>> Norbi
>>>
>>> ----- Original Message -----
>>> From: "Vjeran Marcinko" <vj...@tis.hr>
>>> To: <ta...@jakarta.apache.org>
>>> Sent: Thursday, April 22, 2004 8:44 AM
>>> Subject: DirectLink's too long URLs freeze app
>>>
>>>
>>>> Hi again, and again ...
>>>>
>>>> My application using contrib:Tree got stuck because generated node's
>> links
>>>> are too long, and IE doesn't respond on the click.
>>>> I can see that url parameters come from getNodeContext() method
>>>> inside
>>>> TreeNodeView.java, and there is some ComponentAddress that wrapps
>>>> TreeSourceModel.. I guess the explanation is in there but I cannot
>> figure
>>>> out what it doesn internally ?
>>>> I can also see that tree nodes gets serialized during rendering
>>> DirectLink.
>>>> Is this serialization always necessary (maybe because of this
>>>> ComponentAddress) ?
>>>>
>>>> HELP!! Any suggestions ? (BTW. My whole TreeModel is placed inside
>> Visit)
>>>>
>>>> Here is example of how long URL is :
>>>> <a
>>>>
>>>
>>
> href="/mgw-console/app?service=direct/1/Node/
> $Border.treeNodeView.direct&
>>>>
>>>
>>
> ;sp=OH4sIAAAAAAAAAO1YXWwUVRS-
> s7stbSn0B2LDj0AAiRTZv8puKyZYWhKbLLTSRklL0tydudM
>>>>
>>>
>>
> dmJ0Z7r3b3SXB6IPB-GB4ENGgQX2QmJBoYqKGF8UHEl-MT6gPPhsl-
> Ioxxnjundnd2TLTn4DCQ-d
>>>>
>>>
>>
> hdn6-c-453z3nu7P32h3UwijadArP40qclQ1rLs4pIfEpOE1gXnj2u-
> gX_NXDV6NIyaEOB1NicfG
>>>>
>>>
>>
> coy05aZSQRglhlKgZHaw47Ax6GSH37MAI3QIcL3HDjL9IVG7Tny-dm3nl4KdKFEXHUI-
> KHawavDp
>>>>
>>>
>>
> mqZQUYYwx1ElMeTVilyw-
> g9Z6t6OYY442zMjREyaGscfzp8AlDIrcI1KiNUBcAOIe4ML3J650s71
>>>>
>>>
>>
> mBCGJ7eCox8RM5jNiFx3bAv8Q694CjXODxYtz5bhqW8w2iUvKiG1xapsjACP0mK2R0bPXb7
> HzZIv
>>>>
>>>
>>
> wSNHuMLvhPOMUq1yY3P5o2_a3bn99K4KiORSzcJFw1OtLZpJT4PNgDrW6ZHO0J1egCfCbAL
> 8Jz6_
>>>>
>>>
>>
> Lt98vWKxlhI8UDFMTdqjLdSooT0wSQQ9H670MdrgpiInpa0xMzrBOE
> -15zAqA_8n8cfriL_3b3NR
>>>>
>>>
>>
> 6Gijv_fXR1y6-
> _dWXT0cFmeVOoLP70HMu_WwRKiYw5RahTIR845mO6_3vd91wh9gXZnLE4lAZInJ
>>>>
>>>
>>
> sWC7vSrHv9V__uHo3giLTqKuA2WFCrCMVB1sa0XKoU_VYmKo6RJTguoo4d3LUVhtf3HfLc2
> 9T8Ao
>>>>
>>>
>>
> Ev3PxSEQA35x75_fylr8-
> j6CWewOYRr0GGzZNW3RGbUKCooJJJtKl6CZvkstMMxPu04Q7Hsxsj1H
>>>>
>>>
>>
> Ec-
> Q4YXaJqrLFmrKKgqG47AtIKCqfbeaoZd405uW4WwNgqIIUjlopmSMVURabPA5EOHE3HC_9T
> 94
>>>>
>>>
>>
> 8-efljzfejKA102j97CwkD92jkRFsqpDk7Cw5U8ImE7fNle11IcgI5lDk-
> RInjKMnghIfphRXx_X
>>>>
>>>
>>
> hGk4Ut0aYSg2HG7blkRc9TareZTslJhavwGP_Ih7dFI57YHAb4_UScaRQ7QpIfGE45j93Tn
> 02rnw
>>>>
>>>
>>
> APbwUBcL17hnUXk-Zo-0zgQHWcxWBgIJJ2L2h1GEHrmbvTvSd_7CmZpsh-
> K2LWfz2xt_z7-154Vo
>>>>
>>>
>>
> EtS4r6qU4b1CXg-LCZqnBI0hNN-
> iSMS9pPlYq5gnl3hogFdlVOY5iQ3DIctwvrdZgDTqEsUAw8gE
>>>> 7MataaoHall0C9Jq8DV2
>>>>
>>>
>>
> KQfZinJaID9iRNyxtXKYQ6DQyddyH7tKwYVanwG9pruCUQH1jpi1gStKHWg8cMNyk3MMAOW
> rYmaV
>>>>
>>>
>>
> VAhoSgweBOowNDFNuhHCj9u0PoPeIq6MhsQY2e93vRGQR2HcwjKw6wC7JGgDgF4i5PQy_PU
> UQwdu
>>>>
>>>
>>
> IrLdceV4TAvMfsdgNpPPJFMZNYkHMwcITiaHNDI4kE4PpdUUIdjnCpZLxsrBfu5hMebYFEK
> KGmJ9
>>>>
>>>
>>
> bYqozaGGTaUkBzhqPWbTIvRIA7_WU8xJ4yypO8z4U2SEzhsqWSRFkhwg2XqKqTRJ63mczOs
> kmdUH
>>>>
>>>
>>
> _WN5rsT6sWSDtLtrRWh5eu_DK5MvMXfdDcAEAdK0sLJp4KaMIvQELjohHsth1aUkHQHbIRT
> CI6Fx
>>>>
>>>
>>
> VVvg2myHWPth0V5sjRNPd8p3u5D7kfokqK343Sc11BfN8gRsEI6HKmDoEZav-
> pSsKtj9KVgQkU0i
>>>>
>>>
>>
> FhvIJB-
> iVXpmN6RtPTPh3LpPWsOqSSNNZTeFXHGjr2rk_HxP2lmoTFWNFx_k_5Qg9Vuh7tby85Ga
>>>>
>>>
>>
> vCdX_CtZDE_160UisQraFMJqWCTvmSzKpqKj2k6bqmZ1OrolUXLaVtoWhVFKUhXkFytOGBi
> kuLDn
>>>>
>>>
>>
> P_wD-
> YtkDTSW4lCiIrZZVTbg_TVjAYfifsRX1XGft70CTGgw82l2FHhe94dHeuKqIzlJuMor6w_Y
>>>>
>>>
>>
> ij0Iz4TnibuTK7dQLJw6dfOrbHy6LDSHh-
> jEoew_l7feG7nrCpwVMmSpBFcc7KhWJbKnvqou7NrF
>>>> vLi7kqW8F2K0N7L9HZCC4dhgAAA..&sp=ANode%2F%24Border.treeView"
>>>> style="text-decoration: none">
>>>> <img
>>>>
>>>
>>
> src="/mgw-console/app?service=asset&
> sp=S%2Forg%2Fapache%2Ftapestry%2Fcon
>>>> trib%2Ftree%2Fcomponents%2Fminus.gif" border="0"/>
>>>> </a>
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: DirectLink's too long URLs freeze app + page lifecycle
Posted by Norbert Sándor <pr...@hotmail.com>.
It is possible to do this with 3.0, I thought it would make life easier if
the base DirectLink knew it (maybe controlled by a flag).
And if the parameters would be stored in hidden fields then security issues
would be solved in 3.1 (I hope that those security-friendly features will be
part of 3.1).
Norbi
----- Original Message -----
From: "Mindbridge" <mi...@yahoo.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Thursday, April 22, 2004 10:09 AM
Subject: Re: DirectLink's too long URLs freeze app + page lifecycle
> In 3.0 it is easy to make another implementation of ILinkRenderer that
> stores the parameters as fields in a form, and the link then simply
submits
> that form via JavaScript. This makes no difference in terms of the request
> management (all other code in Tapestry and the app remains the same). It
> just replaces the GET request with a POST and hence there is no limitation
> in terms of the parameter size anymore, since the POST is pretty much
> unlimited in that respect, unlike the GET.
>
> We do something similar in some cases at work, and it seems to work so
far.
> In 3.0 only two changes to your code will be necessary:
> - the new renderer must be passed to the DirectLink component in
> question (there is a parameter for that)
> - the client must have JavaScript enabled, otherwise nothing happens
> (this is the problematic part)
>
> That new additional implementation of ILinkRenderer is relatively simple,
it
> should be added to the standard Tapestry 3.1 distribution perhaps.
>
> ----- Original Message -----
> From: "Norbert Sándor" <pr...@hotmail.com>
> To: "Tapestry users" <ta...@jakarta.apache.org>
> Sent: Thursday, April 22, 2004 10:45 AM
> Subject: Re: DirectLink's too long URLs freeze app + page lifecycle
>
>
> > I have a suggestion for this: a new link component (hopefully a modified
> > DirectLink) would store its parameters in hidden fields. It would render
> > like (only pseudo code):
> >
> > somewhere in the page to prevent nested forms:
> > <form id="Direct0Params">
> > <input name="params" type="hidden" value="serialized parameters
of
> > Direct0" />
> > ...
> > </form>
> >
> > the link would look like:
> > <a
> >
>
href="javascript:document.getElementById('Direct0Params').submit();">link</a
> > >
> >
> > This would solve the "encoded URL is too long" problem. Of course it
could
> > be enhanced, for example DirectLink would check if the generated URL is
> too
> > long and use simple link if not, but use the method above if it is.
> >
> > I think that combining this with my previous idea about (optionally)
> storing
> > hidden field values in a stack in the session would solve many current
> > problems!
> >
> > Let's wait what the developers of Tapestry think about these 2
> suggestions.
> >
> > Norbi
> >
> > ----- Original Message -----
> > From: "Norbert Sándor" <pr...@hotmail.com>
> > To: "Tapestry users" <ta...@jakarta.apache.org>
> > Sent: Thursday, April 22, 2004 9:03 AM
> > Subject: Re: DirectLink's too long URLs freeze app
> >
> >
> > > This is a very bad behaviour. DirectLink parameters should contain
only
> > > primitive types or very small serialized objects.
> > > I had the same problem when I used ONE java.util.Calendar as
DirectLink
> > > parameter. I had to change it to Calendar.getTime().getTime() which is
a
> > > long.
> > >
> > > This can be very uncomfortable and can be solved only by good
component
> > > design.
> > >
> > > Norbi
> > >
> > > ----- Original Message -----
> > > From: "Vjeran Marcinko" <vj...@tis.hr>
> > > To: <ta...@jakarta.apache.org>
> > > Sent: Thursday, April 22, 2004 8:44 AM
> > > Subject: DirectLink's too long URLs freeze app
> > >
> > >
> > > > Hi again, and again ...
> > > >
> > > > My application using contrib:Tree got stuck because generated node's
> > links
> > > > are too long, and IE doesn't respond on the click.
> > > > I can see that url parameters come from getNodeContext() method
inside
> > > > TreeNodeView.java, and there is some ComponentAddress that wrapps
> > > > TreeSourceModel.. I guess the explanation is in there but I cannot
> > figure
> > > > out what it doesn internally ?
> > > > I can also see that tree nodes gets serialized during rendering
> > > DirectLink.
> > > > Is this serialization always necessary (maybe because of this
> > > > ComponentAddress) ?
> > > >
> > > > HELP!! Any suggestions ? (BTW. My whole TreeModel is placed inside
> > Visit)
> > > >
> > > > Here is example of how long URL is :
> > > > <a
> > > >
> > >
> >
>
href="/mgw-console/app?service=direct/1/Node/$Border.treeNodeView.direct&
> > > >
> > >
> >
>
;sp=OH4sIAAAAAAAAAO1YXWwUVRS-s7stbSn0B2LDj0AAiRTZv8puKyZYWhKbLLTSRklL0tydudM
> > > >
> > >
> >
>
dmJ0Z7r3b3SXB6IPB-GB4ENGgQX2QmJBoYqKGF8UHEl-MT6gPPhsl-Ioxxnjundnd2TLTn4DCQ-d
> > > >
> > >
> >
>
hdn6-c-453z3nu7P32h3UwijadArP40qclQ1rLs4pIfEpOE1gXnj2u-gX_NXDV6NIyaEOB1NicfG
> > > >
> > >
> >
>
coy05aZSQRglhlKgZHaw47Ax6GSH37MAI3QIcL3HDjL9IVG7Tny-dm3nl4KdKFEXHUI-KHawavDp
> > > >
> > >
> >
>
mqZQUYYwx1ElMeTVilyw-g9Z6t6OYY442zMjREyaGscfzp8AlDIrcI1KiNUBcAOIe4ML3J650s71
> > > >
> > >
> >
>
mBCGJ7eCox8RM5jNiFx3bAv8Q694CjXODxYtz5bhqW8w2iUvKiG1xapsjACP0mK2R0bPXb7HzZIv
> > > >
> > >
> >
>
wSNHuMLvhPOMUq1yY3P5o2_a3bn99K4KiORSzcJFw1OtLZpJT4PNgDrW6ZHO0J1egCfCbAL8Jz6_
> > > >
> > >
> >
>
Lt98vWKxlhI8UDFMTdqjLdSooT0wSQQ9H670MdrgpiInpa0xMzrBOE-15zAqA_8n8cfriL_3b3NR
> > > >
> > >
> >
>
6Gijv_fXR1y6-_dWXT0cFmeVOoLP70HMu_WwRKiYw5RahTIR845mO6_3vd91wh9gXZnLE4lAZInJ
> > > >
> > >
> >
>
sWC7vSrHv9V__uHo3giLTqKuA2WFCrCMVB1sa0XKoU_VYmKo6RJTguoo4d3LUVhtf3HfLc29T8Ao
> > > >
> > >
> >
>
Ev3PxSEQA35x75_fylr8-j6CWewOYRr0GGzZNW3RGbUKCooJJJtKl6CZvkstMMxPu04Q7Hsxsj1H
> > > >
> > >
> >
>
Ec-Q4YXaJqrLFmrKKgqG47AtIKCqfbeaoZd405uW4WwNgqIIUjlopmSMVURabPA5EOHE3HC_9T94
> > > >
> > >
> >
>
8-efljzfejKA102j97CwkD92jkRFsqpDk7Cw5U8ImE7fNle11IcgI5lDk-RInjKMnghIfphRXx_X
> > > >
> > >
> >
>
hGk4Ut0aYSg2HG7blkRc9TareZTslJhavwGP_Ih7dFI57YHAb4_UScaRQ7QpIfGE45j93Tn02rnw
> > > >
> > >
> >
>
APbwUBcL17hnUXk-Zo-0zgQHWcxWBgIJJ2L2h1GEHrmbvTvSd_7CmZpsh-K2LWfz2xt_z7-154Vo
> > > >
> > >
> >
>
EtS4r6qU4b1CXg-LCZqnBI0hNN-iSMS9pPlYq5gnl3hogFdlVOY5iQ3DIctwvrdZgDTqEsUAw8gE
> > > > 7MataaoHall0C9Jq8DV2
> > > >
> > >
> >
>
KQfZinJaID9iRNyxtXKYQ6DQyddyH7tKwYVanwG9pruCUQH1jpi1gStKHWg8cMNyk3MMAOWrYmaV
> > > >
> > >
> >
>
VAhoSgweBOowNDFNuhHCj9u0PoPeIq6MhsQY2e93vRGQR2HcwjKw6wC7JGgDgF4i5PQy_PUUQwdu
> > > >
> > >
> >
>
IrLdceV4TAvMfsdgNpPPJFMZNYkHMwcITiaHNDI4kE4PpdUUIdjnCpZLxsrBfu5hMebYFEKKGmJ9
> > > >
> > >
> >
>
bYqozaGGTaUkBzhqPWbTIvRIA7_WU8xJ4yypO8z4U2SEzhsqWSRFkhwg2XqKqTRJ63mczOskmdUH
> > > >
> > >
> >
>
_WN5rsT6sWSDtLtrRWh5eu_DK5MvMXfdDcAEAdK0sLJp4KaMIvQELjohHsth1aUkHQHbIRTCI6Fx
> > > >
> > >
> >
>
VVvg2myHWPth0V5sjRNPd8p3u5D7kfokqK343Sc11BfN8gRsEI6HKmDoEZav-pSsKtj9KVgQkU0i
> > > >
> > >
> >
>
FhvIJB-iVXpmN6RtPTPh3LpPWsOqSSNNZTeFXHGjr2rk_HxP2lmoTFWNFx_k_5Qg9Vuh7tby85Ga
> > > >
> > >
> >
>
vCdX_CtZDE_160UisQraFMJqWCTvmSzKpqKj2k6bqmZ1OrolUXLaVtoWhVFKUhXkFytOGBikuLDn
> > > >
> > >
> >
>
P_wD-YtkDTSW4lCiIrZZVTbg_TVjAYfifsRX1XGft70CTGgw82l2FHhe94dHeuKqIzlJuMor6w_Y
> > > >
> > >
> >
>
ij0Iz4TnibuTK7dQLJw6dfOrbHy6LDSHh-jEoew_l7feG7nrCpwVMmSpBFcc7KhWJbKnvqou7NrF
> > > > vLi7kqW8F2K0N7L9HZCC4dhgAAA..&sp=ANode%2F%24Border.treeView"
> > > > style="text-decoration: none">
> > > > <img
> > > >
> > >
> >
>
src="/mgw-console/app?service=asset&sp=S%2Forg%2Fapache%2Ftapestry%2Fcon
> > > > trib%2Ftree%2Fcomponents%2Fminus.gif" border="0"/>
> > > > </a>
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > 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
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: DirectLink's too long URLs freeze app + page lifecycle
Posted by Mindbridge <mi...@yahoo.com>.
In 3.0 it is easy to make another implementation of ILinkRenderer that
stores the parameters as fields in a form, and the link then simply submits
that form via JavaScript. This makes no difference in terms of the request
management (all other code in Tapestry and the app remains the same). It
just replaces the GET request with a POST and hence there is no limitation
in terms of the parameter size anymore, since the POST is pretty much
unlimited in that respect, unlike the GET.
We do something similar in some cases at work, and it seems to work so far.
In 3.0 only two changes to your code will be necessary:
- the new renderer must be passed to the DirectLink component in
question (there is a parameter for that)
- the client must have JavaScript enabled, otherwise nothing happens
(this is the problematic part)
That new additional implementation of ILinkRenderer is relatively simple, it
should be added to the standard Tapestry 3.1 distribution perhaps.
----- Original Message -----
From: "Norbert Sándor" <pr...@hotmail.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Thursday, April 22, 2004 10:45 AM
Subject: Re: DirectLink's too long URLs freeze app + page lifecycle
> I have a suggestion for this: a new link component (hopefully a modified
> DirectLink) would store its parameters in hidden fields. It would render
> like (only pseudo code):
>
> somewhere in the page to prevent nested forms:
> <form id="Direct0Params">
> <input name="params" type="hidden" value="serialized parameters of
> Direct0" />
> ...
> </form>
>
> the link would look like:
> <a
>
href="javascript:document.getElementById('Direct0Params').submit();">link</a
> >
>
> This would solve the "encoded URL is too long" problem. Of course it could
> be enhanced, for example DirectLink would check if the generated URL is
too
> long and use simple link if not, but use the method above if it is.
>
> I think that combining this with my previous idea about (optionally)
storing
> hidden field values in a stack in the session would solve many current
> problems!
>
> Let's wait what the developers of Tapestry think about these 2
suggestions.
>
> Norbi
>
> ----- Original Message -----
> From: "Norbert Sándor" <pr...@hotmail.com>
> To: "Tapestry users" <ta...@jakarta.apache.org>
> Sent: Thursday, April 22, 2004 9:03 AM
> Subject: Re: DirectLink's too long URLs freeze app
>
>
> > This is a very bad behaviour. DirectLink parameters should contain only
> > primitive types or very small serialized objects.
> > I had the same problem when I used ONE java.util.Calendar as DirectLink
> > parameter. I had to change it to Calendar.getTime().getTime() which is a
> > long.
> >
> > This can be very uncomfortable and can be solved only by good component
> > design.
> >
> > Norbi
> >
> > ----- Original Message -----
> > From: "Vjeran Marcinko" <vj...@tis.hr>
> > To: <ta...@jakarta.apache.org>
> > Sent: Thursday, April 22, 2004 8:44 AM
> > Subject: DirectLink's too long URLs freeze app
> >
> >
> > > Hi again, and again ...
> > >
> > > My application using contrib:Tree got stuck because generated node's
> links
> > > are too long, and IE doesn't respond on the click.
> > > I can see that url parameters come from getNodeContext() method inside
> > > TreeNodeView.java, and there is some ComponentAddress that wrapps
> > > TreeSourceModel.. I guess the explanation is in there but I cannot
> figure
> > > out what it doesn internally ?
> > > I can also see that tree nodes gets serialized during rendering
> > DirectLink.
> > > Is this serialization always necessary (maybe because of this
> > > ComponentAddress) ?
> > >
> > > HELP!! Any suggestions ? (BTW. My whole TreeModel is placed inside
> Visit)
> > >
> > > Here is example of how long URL is :
> > > <a
> > >
> >
>
href="/mgw-console/app?service=direct/1/Node/$Border.treeNodeView.direct&
> > >
> >
>
;sp=OH4sIAAAAAAAAAO1YXWwUVRS-s7stbSn0B2LDj0AAiRTZv8puKyZYWhKbLLTSRklL0tydudM
> > >
> >
>
dmJ0Z7r3b3SXB6IPB-GB4ENGgQX2QmJBoYqKGF8UHEl-MT6gPPhsl-Ioxxnjundnd2TLTn4DCQ-d
> > >
> >
>
hdn6-c-453z3nu7P32h3UwijadArP40qclQ1rLs4pIfEpOE1gXnj2u-gX_NXDV6NIyaEOB1NicfG
> > >
> >
>
coy05aZSQRglhlKgZHaw47Ax6GSH37MAI3QIcL3HDjL9IVG7Tny-dm3nl4KdKFEXHUI-KHawavDp
> > >
> >
>
mqZQUYYwx1ElMeTVilyw-g9Z6t6OYY442zMjREyaGscfzp8AlDIrcI1KiNUBcAOIe4ML3J650s71
> > >
> >
>
mBCGJ7eCox8RM5jNiFx3bAv8Q694CjXODxYtz5bhqW8w2iUvKiG1xapsjACP0mK2R0bPXb7HzZIv
> > >
> >
>
wSNHuMLvhPOMUq1yY3P5o2_a3bn99K4KiORSzcJFw1OtLZpJT4PNgDrW6ZHO0J1egCfCbAL8Jz6_
> > >
> >
>
Lt98vWKxlhI8UDFMTdqjLdSooT0wSQQ9H670MdrgpiInpa0xMzrBOE-15zAqA_8n8cfriL_3b3NR
> > >
> >
>
6Gijv_fXR1y6-_dWXT0cFmeVOoLP70HMu_WwRKiYw5RahTIR845mO6_3vd91wh9gXZnLE4lAZInJ
> > >
> >
>
sWC7vSrHv9V__uHo3giLTqKuA2WFCrCMVB1sa0XKoU_VYmKo6RJTguoo4d3LUVhtf3HfLc29T8Ao
> > >
> >
>
Ev3PxSEQA35x75_fylr8-j6CWewOYRr0GGzZNW3RGbUKCooJJJtKl6CZvkstMMxPu04Q7Hsxsj1H
> > >
> >
>
Ec-Q4YXaJqrLFmrKKgqG47AtIKCqfbeaoZd405uW4WwNgqIIUjlopmSMVURabPA5EOHE3HC_9T94
> > >
> >
>
8-efljzfejKA102j97CwkD92jkRFsqpDk7Cw5U8ImE7fNle11IcgI5lDk-RInjKMnghIfphRXx_X
> > >
> >
>
hGk4Ut0aYSg2HG7blkRc9TareZTslJhavwGP_Ih7dFI57YHAb4_UScaRQ7QpIfGE45j93Tn02rnw
> > >
> >
>
APbwUBcL17hnUXk-Zo-0zgQHWcxWBgIJJ2L2h1GEHrmbvTvSd_7CmZpsh-K2LWfz2xt_z7-154Vo
> > >
> >
>
EtS4r6qU4b1CXg-LCZqnBI0hNN-iSMS9pPlYq5gnl3hogFdlVOY5iQ3DIctwvrdZgDTqEsUAw8gE
> > > 7MataaoHall0C9Jq8DV2
> > >
> >
>
KQfZinJaID9iRNyxtXKYQ6DQyddyH7tKwYVanwG9pruCUQH1jpi1gStKHWg8cMNyk3MMAOWrYmaV
> > >
> >
>
VAhoSgweBOowNDFNuhHCj9u0PoPeIq6MhsQY2e93vRGQR2HcwjKw6wC7JGgDgF4i5PQy_PUUQwdu
> > >
> >
>
IrLdceV4TAvMfsdgNpPPJFMZNYkHMwcITiaHNDI4kE4PpdUUIdjnCpZLxsrBfu5hMebYFEKKGmJ9
> > >
> >
>
bYqozaGGTaUkBzhqPWbTIvRIA7_WU8xJ4yypO8z4U2SEzhsqWSRFkhwg2XqKqTRJ63mczOskmdUH
> > >
> >
>
_WN5rsT6sWSDtLtrRWh5eu_DK5MvMXfdDcAEAdK0sLJp4KaMIvQELjohHsth1aUkHQHbIRTCI6Fx
> > >
> >
>
VVvg2myHWPth0V5sjRNPd8p3u5D7kfokqK343Sc11BfN8gRsEI6HKmDoEZav-pSsKtj9KVgQkU0i
> > >
> >
>
FhvIJB-iVXpmN6RtPTPh3LpPWsOqSSNNZTeFXHGjr2rk_HxP2lmoTFWNFx_k_5Qg9Vuh7tby85Ga
> > >
> >
>
vCdX_CtZDE_160UisQraFMJqWCTvmSzKpqKj2k6bqmZ1OrolUXLaVtoWhVFKUhXkFytOGBikuLDn
> > >
> >
>
P_wD-YtkDTSW4lCiIrZZVTbg_TVjAYfifsRX1XGft70CTGgw82l2FHhe94dHeuKqIzlJuMor6w_Y
> > >
> >
>
ij0Iz4TnibuTK7dQLJw6dfOrbHy6LDSHh-jEoew_l7feG7nrCpwVMmSpBFcc7KhWJbKnvqou7NrF
> > > vLi7kqW8F2K0N7L9HZCC4dhgAAA..&sp=ANode%2F%24Border.treeView"
> > > style="text-decoration: none">
> > > <img
> > >
> >
>
src="/mgw-console/app?service=asset&sp=S%2Forg%2Fapache%2Ftapestry%2Fcon
> > > trib%2Ftree%2Fcomponents%2Fminus.gif" border="0"/>
> > > </a>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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