What if you move your classes from tapestry.utility to
tapestry.base.utility which is controlled by tapestrymaybe
http://tapestry.apache.org/class-reloading.html
On 01/06/2014 4:58 am, "Boris Horvat" wrote:
> In what package should I put this component? Currently it resides in
>
> package co
Here is the code that will trigger the issue (I needed a bit of time to
isolate everything sorry for the delay.
The fact that loop is around element is what is triggering the issue
${values}
Hi, thanks for the quick response
Thiago, the entire form is already in a zone.
I don't think that stack trace will help but here it is
Stack trace
-
org.apache.tapestry5.corelib.components.Form.executeStoredActions(Form.java:649)
-
org.apache.tapestry5.corelib.components.Form.adv
The easiest solution is to wrap the whole form inside a Zone and update
this zone.
On Sat, 31 May 2014 15:55:10 -0300, Boris Horvat
wrote:
Hi everyone,
I have form that basically displays couple of checkboxs that user can
select/deselect. Once he is made his choice he clicks a button and
On Sat, May 31, 2014 at 11:55 AM, Boris Horvat
wrote:
> I have form that basically displays couple of checkboxs that user can
> select/deselect. Once he is made his choice he clicks a button and a form
> is submited, zone is refreshed (include the form).
> All of the data is nicely displayed but
In what package should I put this component? Currently it resides in
package com.bomahabo.flow.tapestry.utility
and it uses
private AjaxResponseRenderer ajaxResponseRenderer;
private Request request;
private JavaScriptSupport javascript;
Should I move it outside of the tapestry in o
Hi everyone,
I have form that basically displays couple of checkboxs that user can
select/deselect. Once he is made his choice he clicks a button and a form
is submited, zone is refreshed (include the form).
All of the data is nicely displayed but a second submissions throws the
error
Forms requ
On Sat, 31 May 2014 07:51:56 -0300, Muhammad Gelbana
wrote:
I don't see a reason why Tapestry doesn't support such a case. Unless
Tapestry uses a 3rd party library that strictly complies with the java
beans specifications to read getters\setters,
Tapestry doesn't use a 3rd party library. It
I don't see a reason why Tapestry doesn't support such a case. Unless
Tapestry uses a 3rd party library that strictly complies with the java
beans specifications to read getters\setters, It would be a pleasure for
Tapestry users to find Tapestry going an extra mile to make their lives
easier, that'
