I've been squeezing a little bit of this in, while I'm waiting for compiles and things on my day job.
It's coming out really sweet. I've revved the component specification so that parameters can now identify a direction: in, out, in-out or custom. custom is the default, and means the parameter is handled entirely by the component (i.e., the same as is done in earlier versions of Tapestry). out and in-out are currently the same as custom, though that may change. custom is also the default (if not specified, or when using the 1.1 DTD). In: the parameter is set before invoking renderComponent () and cleared after invoking renderComponent(). I call this "connecting the parameter to a property". There are a few conditions that must be met. The java- type of the parameter must match the type of the property. The property must be read/write. The parameter direction must be "in". By default, the property name matches the parameter name, but this can be overriden. If the binding is static, the property is set just once (before the first render) and left alone. The code for components is much simpler now. For out, in-out and custom components, you still need to get the binding. I've been thinking about adding handling so that out parameters are set, through the binding, after the component renders. That is, Tapestry could read the property from the component, and update through the binding with the value. The problem with out parameters is that the timing is tricky, to have the framework handle it automatically. Take a Foreach: it updates its value and index parameters during the render (before invoking renderWrapped()), so out wouldn't work there. For form components, the in part would work fine, but the out is tricky: the parameters should only be in during the render phase, and only out during the (subsequent) rewind phase. Then there's the issue with listeners ... for components (such as Submit and ImageSubmit) that have a listener, the listener should be notified after the out parameters have been updated. So those parameters will probably stay custom. Where I'm headed is to increase the number of parameter directions. Traditional in, out, in-out aren't enough: I need something like "form-style" (in during render, out during rewind) perhaps, or other variations. For the moment, I'll just leave the form component properties set to "custom". This gives us a good migration path for future changes. Another thought I've had is to declare a property- binding as "invariant". This would provide a cross point between dynamic property bindings and static/field bindings. In the former, the property must be resolved each time, because the value could be different each time. In the latter, the property can be resolved just once, since (by definition) it can't change. Using an invariant property binding, the property would be resolved just the first time. This would typically be used for things like listeners, parsed scripts and assets. I'm a little leery about it, because you could screw up Tapestry by having an invariant binding point to an object (like the engine or visit) outside of the page's object graph. More likely, the developer would get confused. So are invariant bindings a premature optimization? Even as I'm writing this, I'm leaning towards leaving them out until they are shown to be needed. It's just that connected properties are going to have some measurable (but hopefully not noticable) performance impact ... simply because more properties will be resolved through dynamic property bindings more often. Still, what I like about connected parameters is that they will operate much more like people expect them to work (notice the number of newbie questions related to parameters and properties). Developing simple components (those without any output parameters) will be cake. -- [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
