Actually... on second thought you can't return null from add since tapestry
needs to render the empty record.
Try this instead:
eg:
...
public class NullNewValueEncoder implements ValueEncoder {
private static final String CLIENT_NULL = "XXX";
private ValueEncoder encoder;
private Class
I agree with Thiago: "My best practices for persisting fields is this: just do
it when there's no way of avoiding it."
Most JumpStart examples avoid @Persist. The reasons are given in the "Caution"
section of this page:
http://jumpstart.doublenegative.com.au/jumpstart7/examples/state/s
Thinking about this a bit more, you can probably avoid @Persist by using an
appropriate ValueEncoder.
eg:
...
public class LazyValueEncoder implements ValueEncoder {
private static final String CLIENT_NULL = "XXX";
private ValueEncoder encoder;
private Class type;
public LazyValueEnco
There's really 3 options:
1. Use the HttpSession
2. Save to the database and pass ids (perhaps a staging table or status=
temp)
3. Store values on the client (hidden fields, data attributes, javascript
variables, activation context, request parameters)
On 14 Aug 2014 16:26, "squallmat ." wrote:
On Thu, 14 Aug 2014 12:55:46 -0300, Muhammad Gelbana
wrote:
What version are you using ? This will make a difference because prior to
v5.4 (I think ?) tapestry used to redirect after posing a form, so
persisting some fields were sometimes needed..
5.4 still redirects after posting a form *w
What version are you using ? This will make a difference because prior to
v5.4 (I think ?) tapestry used to redirect after posing a form, so
persisting some fields were sometimes needed..
I usually have one @Persist'ed object being edited by my page. This object
had, within it, all the values that
On Thu, 14 Aug 2014 12:25:40 -0300, squallmat .
wrote:
Hi,
Hi!
My best practices for persisting fields is this: just do it when there's
no way of avoiding it.
each time on a submit failed the field values associated to a simple
string persist without requiring @Persist annotation. Bu
