You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "squallmat ." <sq...@gmail.com> on 2014/08/14 17:25:40 UTC
best practice for persisting fields
Hi,
each time on a submit failed the field values associated to a simple string
persist without requiring @Persist annotation. But when you have any other
type of fields, for example a list from an ajaxformloop, or a file
selection, their values doesn't persist naturally, you have to use @Persist
(and even the FLASH one doesn't work).
That's really frustrating and cause you to have to manage some values in
session that force you to use really weird tricks to manage them, for
example when you come back later to a form you failed submit before and you
see a part of old-entered values or fiels of an ajaxformloop still there.
I would like to know if there is a method, a best practice, to handle the
submitting persistence of values that are not link to simple String
Property.
Thanks in advance.
Re: best practice for persisting fields
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 14 Aug 2014 12:55:46 -0300, Muhammad Gelbana <m....@gmail.com>
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 *without* validation errors, but
returns immediately when validation errors happen, so you don't need to
@Persist the edited properties in order to show the validation errors
without losing the typed values.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: best practice for persisting fields
Posted by Muhammad Gelbana <m....@gmail.com>.
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 I need to be persisted. Of course you
may need more objects but that's how I find my self eventually doing it.
Probably because I've been using Tapestry for a specific application with
strict needs.
You know if use @Persist, then you persist your values in he user's session
but in this page only ? Using @SessionState has an implication which is
having the type of the persisted value, as the key to it. Meaning that if
you use @SessionState to persist a User object. If you use @SessionState
again in a different page to refer to another User object with whatever
name, you'll still be referring to the same object. Because the variable
name isn't the key, its it's type.
If you state a specific situation where you are facing issues, it may be
easier to get an answer.
*---------------------*
*Muhammad Gelbana*
http://www.linkedin.com/in/mgelbana
On Thu, Aug 14, 2014 at 6:25 PM, squallmat . <sq...@gmail.com> wrote:
> Hi,
>
> each time on a submit failed the field values associated to a simple string
> persist without requiring @Persist annotation. But when you have any other
> type of fields, for example a list from an ajaxformloop, or a file
> selection, their values doesn't persist naturally, you have to use @Persist
> (and even the FLASH one doesn't work).
> That's really frustrating and cause you to have to manage some values in
> session that force you to use really weird tricks to manage them, for
> example when you come back later to a form you failed submit before and you
> see a part of old-entered values or fiels of an ajaxformloop still there.
>
> I would like to know if there is a method, a best practice, to handle the
> submitting persistence of values that are not link to simple String
> Property.
>
> Thanks in advance.
>
Re: best practice for persisting fields
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 14 Aug 2014 12:25:40 -0300, squallmat . <sq...@gmail.com>
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. But when you have
> any other type of fields, for example a list from an ajaxformloop,
Any process using more than one render request and one action request
(form submission, event links, etc) will need some kind of persistence.
> or a file selection, their values doesn't persist naturally,
I don't think HTML supports giving an <input type="file"> an initial value.
> you have to use @Persist (and even the FLASH one doesn't work).
You missed the point here. The problem isn't simple string vs list. It's
one request vs multiple ones.
> That's really frustrating and cause you to have to manage some values in
> session that force you to use really weird tricks to manage them, for
> example when you come back later to a form you failed submit before and
> you see a part of old-entered values or fiels of an ajaxformloop still
> there.
I don't like AjaxFormLoop, to be honest, so I don't use it.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: best practice for persisting fields
Posted by Geoff Callender <ge...@gmail.com>.
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/storingdatainapage
In T5.3, you need persistence to avoid losing certain fields, eg. hidden fields, when a Form is in error. That's because it redirects and the ValidationTracker only looks after the input-capable fields. You'll see JumpStart for T5.3handling it with flash persistence.
T5.4 is much simpler: you no longer need persistence because it doesn't redirect (on Form error).
As for AjaxFormLoop, which I don't like either, here are three examples that do not use @Persist. Like Lance's suggestion, they use an encoder:
http://jumpstart.doublenegative.com.au/jumpstart/examples/ajax/formloop1
http://jumpstart.doublenegative.com.au/jumpstart/examples/ajax/formloopwithholders1
http://jumpstart.doublenegative.com.au/jumpstart/examples/ajax/formlooptailored1
Geoff
On 15 Aug 2014, at 8:16 pm, Lance Java <la...@googlemail.com> wrote:
> Thinking about this a bit more, you can probably avoid @Persist by using an
> appropriate ValueEncoder.
>
> eg:
> <t:ajaxformloop t:id="foos" source="foos" value="foo"
> encoder="lazyEncoder">...</t:ajaxformloop>
>
> public class LazyValueEncoder<T> implements ValueEncoder<T> {
> private static final String CLIENT_NULL = "XXX";
> private ValueEncoder<T> encoder;
> private Class<T> type;
> public LazyValueEncoder<T>(ValueEncoderSource source, Class<T> type) {
> this.encoder = source.getValueEncoder(type);
> this.type = type;
> }
> public String toClient(T value) {
> if (value == null) {
> return CLIENT_NULL;
> }
> return encoder.toClient(value);
> }
> public T toValue(String client) {
> if (CLIENT_NULL.equals(client)) {
> return type.newInstance();
> }
> return encoder.toValue(client);
> }
> }
>
> public class MyPage {
> @Property private List<Foo> foos;
> @Property private Foo foo;
> @Inject private ValueEncoderSource source;
>
> public ValueEncoder<Foo> getLazyEncoder() {
> return new LazyValueEncoder(source, Foo.class);
> }
>
> public Foo onAddRowFromFoos() {
> return null;
> }
> }
>
> Warning: Untested code
Re: best practice for persisting fields
Posted by Lance Java <la...@googlemail.com>.
Actually... on second thought you can't return null from add since tapestry
needs to render the empty record.
Try this instead:
eg:
<t:ajaxformloop t:id="foos" source="foos" value="foo"
encoder="nullNewEncoder">...</t:ajaxformloop>
public class NullNewValueEncoder<T> implements ValueEncoder<T> {
private static final String CLIENT_NULL = "XXX";
private ValueEncoder<T> encoder;
private Class<T> type;
public NullNewValueEncoder<T>(ValueEncoderSource source, Class<T> type) {
this.encoder = source.getValueEncoder(type);
this.type = type;
}
public String toClient(T value) {
String client = encoder.toClient(value);
if (client == null) {
// eg hibernate entity id was null
return CLIENT_NULL;
}
}
public T toValue(String client) {
if (CLIENT_NULL.equals(client)) {
// this object will be used in the POST request (requires no-args
constructor)
return type.newInstance();
}
return encoder.toValue(client);
}
}
public class MyPage {
@Property private List<Foo> foos;
@Property private Foo foo;
@Inject private ValueEncoderSource source;
public ValueEncoder<Foo> getNullNewEncoder() {
return new NullNewValueEncoder(source, Foo.class);
}
public Foo onAddRowFromFoos() {
// this object will be used to render the empty row then discarded
return new Foo();
}
}
Re: best practice for persisting fields
Posted by Lance Java <la...@googlemail.com>.
Thinking about this a bit more, you can probably avoid @Persist by using an
appropriate ValueEncoder.
eg:
<t:ajaxformloop t:id="foos" source="foos" value="foo"
encoder="lazyEncoder">...</t:ajaxformloop>
public class LazyValueEncoder<T> implements ValueEncoder<T> {
private static final String CLIENT_NULL = "XXX";
private ValueEncoder<T> encoder;
private Class<T> type;
public LazyValueEncoder<T>(ValueEncoderSource source, Class<T> type) {
this.encoder = source.getValueEncoder(type);
this.type = type;
}
public String toClient(T value) {
if (value == null) {
return CLIENT_NULL;
}
return encoder.toClient(value);
}
public T toValue(String client) {
if (CLIENT_NULL.equals(client)) {
return type.newInstance();
}
return encoder.toValue(client);
}
}
public class MyPage {
@Property private List<Foo> foos;
@Property private Foo foo;
@Inject private ValueEncoderSource source;
public ValueEncoder<Foo> getLazyEncoder() {
return new LazyValueEncoder(source, Foo.class);
}
public Foo onAddRowFromFoos() {
return null;
}
}
Warning: Untested code
Re: best practice for persisting fields
Posted by Lance Java <la...@googlemail.com>.
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 ." <sq...@gmail.com> wrote:
> Hi,
>
> each time on a submit failed the field values associated to a simple string
> persist without requiring @Persist annotation. But when you have any other
> type of fields, for example a list from an ajaxformloop, or a file
> selection, their values doesn't persist naturally, you have to use @Persist
> (and even the FLASH one doesn't work).
> That's really frustrating and cause you to have to manage some values in
> session that force you to use really weird tricks to manage them, for
> example when you come back later to a form you failed submit before and you
> see a part of old-entered values or fiels of an ajaxformloop still there.
>
> I would like to know if there is a method, a best practice, to handle the
> submitting persistence of values that are not link to simple String
> Property.
>
> Thanks in advance.
>