Eventually I'm going to be saving the values in RDF - the values won't
have a persistent key, they're just literal values. I'm also keen to
avoid using any session persistence but will do if it's necessary. Can
tapestry deal with simple values that don't have identity in this way?
To understand this you need to know what that key is really used for.....
Say I have a Person Object...
public class Person(){
public String name;
public String id;
}
and two person Object sin a list;
Person bob;
Person alice;
List<Person> personList;
bob.setName("Bob");
bob.setId("1");
alice.setName("Alice");
alice.setId("2");
personList.add(bob);
personList.add(alice);
Now... when if I set my keyExpression to be person.id when tapestry
renders out the form it stores a hidden field with the ids in order..
in this case it would have "1" and "2". Why is this important? Well
you have to understand what happens during a rewind. It is nothing
magical really and the simplistic way to explain is that your page
just renders out again but with the form bindings reversed.... so in
your case....
<input jwcid="@TextField" value="ognl:name" />
when it gets to that input field... instead of reading the "value"
parameter with getName() it simply writes that paremeter with
setName().
so say I got the page and it has a list of my current users....
* [ BOB ]
* [ALICE ]
now I want to change Bob's name to Robert so I edit.....
* [ROBERT]
* [ALICE]
and hit submit..
What happens if while I was changing the name on the form.. someone
somehow change the original person list so that the names are
backwards so the objects are { alice, bob}. If tapestry allowed it
this would be bad! Because you meant to change Bob's name but as far
as Tapestry is concerned you just instructed it to set the name on the
first item on the list to "Robert". And if the order on the list was
somehow changed it's your Alice object that will get it's name change.
This is why tapestry stores extra information in the hidden field.
What it does, is before actually calling setName() it will check that
your keyExpression submitted with the form matches the keyExpression
of the object from the list. If the list got changed this will be
different and tapestry will detect this and throw you an exception so
you don't accidentally delete or modify th wrong object.
Of course... if you don't have a real key you can either make one up.
Or if your oject converts automatically to a string tapestry will just
store that in the hidden fields. Of course, if you don't care about
what I just described or you know for certain that nobody will modify
the list, you could set keyExpression to something constant so it
always matches no matter what.
I hope this explenation was useful. The whole rewind idea seemed
magical to me until someone explained it to me like this.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
