I don't understand why you want to rewind the page?
You should never have to invoke those methods.
> We have a page that displays an object and a list of
subobjects.
> All objects are retrieved from a database when the
page is
> attached and all objects have unique ids.
> Each subobject has a boolean value that we want to be
able to
> toggle from the display page. We display the
subobjects in a table
> using a Foreach and in each row we put a Direct with
a context of
> the subobject's id. The Direct is supposed to toggle
the boolean
> in the subobject and rerender the page.
You Direct component's listener method should be able to
extract the object primary key from the context, read
the object from the database, toggle its binary
property, and store it back into the database.
public void action(...)
{
String objectId = context[0];
MyObject object = readFromDatabase(objectId);
object.toggleBoolean();
object.saveBackToDatabase();
}
That's about it.
There's more about your page construction I don't
understand.
> From reading the tapestry docos it seems that the
Direct needs to
> rewind and rerender the page after it updates the
database. I can't
> figure out how to do this; are there any simple
examples of this
> (I find it hard to learn things from VLib since it's
so large and
> is doing so many things)?
I think you are trying to "outguess" Tapestry; in some
cases you have to be *aware* of the render and rewind
phases (for instance, when you use the Action component,
or do something tricky with Forms such as looping inside
the Form), but you never have to invoke them. The point
of using the Direct component is to avoid doing a rewind
at all.
> Another option may be to use a ListEdit instead of a
Foreach. I get
> the impression from the docs that it is supposed to
help with this
> type of problem. But I can't figure out how to use a
ListEdit.
> Are there any simple examples using a ListEdit?
ListEdit is for use inside a Form. If I was implenting
your interface, I'd use a Form, ListEdit and Checkbox to
accomplish what you are doing. That way, you can update
multiple properties of muliple detail objects all in one
go.
When the page first renders, how does it know what
master object to display?
Say you have a masterObjectId that identifies the master
object (which contains the subobjects whose property you
are trying to edit).
You probably want to store the master object primary key
as a persistent page property.
You can then override beginResponse() to load the master
object. You can have a Foreach that queries the master
object for the list of subobjects.
Again, I wouldn't override attach() either. That's
called when the page object is first created (or taken
from the pool), before persistent page properties are
restored. beginResponse() is the right method to
override. Generally, the JavaDoc specifies methods that
should be overriden, and clearly states whether the
overriden method needs to be invoked as well.
I sort of picture a little script when developing pages.
First page of the script: What do I do now? In your
case, the script says: "Display a master object and
detail objects, with links."
So I code up a way to store the master object (or, at
least, the primary key of the master object), figure out
how to get the detail objects, figure out what to store
in the links.
Second page of script: What happens next? In your case,
the user clicks a link. Your goal is to (a) update the
detail object property and (b) redisplay the page,
reflecting the change.
So, you need to identify the detail object in you link;
so you put the primary key of the detail object into the
context parameters.
To redisplay the page, you need that master object
again. If you can get its primary key from the detail
object, then you are already in good shape. If not, you
need to put the master object primary key in the context
parameters, or store it persisently in the page.
And, you always want to remember that the page instance
for the first request cycle will not (necessarily) be
the page instance for the second cycle; you have to
store any data that carries over as a persistent page
property, or as a context parameter (in the URL), or in
a Hidden form field, or somewhere in your Visit ... the
right solution depends on the situation.
Hope this helps ... you get better responses with
specific questions than with general stuff.
--
[EMAIL PROTECTED]
http://tapestry.sf.net
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer
