Two good points. On #1: Yes, you must invoke fireObservedChange(). As a component with state, you are also responsible for registering as a PageDetachListener (from finishLoad()) and reseting persistent state.
There is currently a new Tutorial being assembled that will address this, and I'm working on a new documentation set as well. #2: Double clicks Yes, this is a problem and can affect frames as well. The page recorders are stored inside the engine. What's happening is the first request is hung or slow while rendering, after locking the page recorder. The second request gets the page recorder, but its in the locked state already. The solution to this is a little refactoring, to handle this situation better. Basically, add a layer to handle this locking. Bear in mind that page recorders look simpler than they are. The design of Tapestry specifically allows other forms of page recorders. The current framework only implements simple page recorders, which store data in a Map stored within the engine and HttpSession. In the future there will be page recorders that store state as HTTP Cookies. That's why page recorders have to lock; cookies can only be written before any actual page content is written back to the client web browser. I've also given thought to adding extra client-side scripting for Forms, to (at least) warn users about resubmitting a form. -- [EMAIL PROTECTED] http://tapestry.sf.net > > Hello, after reading an interesting threat on the Serverside recently, > I decided to give Tapestry a try. I think it is a _really_ great product, > it is really a relief being able to ditch JSP completely :-) > I am seriously going to suggest this as a replacement for Struts in > Cap Gemini Ernst & Young Norway when I have gained a bit more experience > with it. > > After some fumbling, I have a few comments/questions that I hope you > can consider. > > Persisteny page state: After reading about this in the developer > documentation (Tapestry 2.1) I feel you could be a bit more clear > about this. You mention the need for Pages to call fireObservedChange() > but what about stateful Components (that are not pages)? I went > through your examples with stateful components, and could find no > references to fireObservedChange(). > > I assume stateful Components also needs to call fireObservedChange() > as I got some weird problems in my stateful components when I submitted > multiple simultaneous requests (thus using different objects from the > pool, I presume) until I implemented fireObservedChange() calls. > > In the examples such as the Portlet's expanded property, no > fireObservedChange() is called. Instead, it seems to pull a trick > using a model. > > Does this mean that _all_ state in a stateful component must be > directly exposed as public properties? > > In short, handling of persistent state is easy to do wrong and errors > are sometimes difficult to discover. Therefore I feel it really should > be discussed more thoroughly. > > Double-clicking: > When I double-click a Direct link that is bound to a persistent property I get > the > net.sf.tapestry.ApplicationRuntimeException: > "Page recorder for page Home is locked after a commit(), but received a > change to property startCount of component Home/counter1." > > As this is a really serious errormessage for a quite common problem (clicking > a link again after waiting impatiently a few seconds), how can I avoid it? > > Again, great work! > Karl Ivar Dahl ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
