On 1/27/07, Hugo Palma <[EMAIL PROTECTED]> wrote:
I think both are valid options. In my opinion both ways should be provided by the framework and it should be a developers decision to use the one that fits his needs/taste.
For me, the issue is that this puts an onus on the developers (us!) to write much more code for components, while limiting their functionality in the process (locking down some parameters as simple read-only properties). There's a lot of work involved in getting a parameter to work properly, cache its value, reset at the end of the request, etc., etc., that under the current system, is handled efficiently and automatically with runtime bytecode generation. There was an endless slew of bugs in the Tapestry 2 time frame with people who didn't understand the nuances of page, component and parameter lifecycle. The worst thing is when code works under a light developer load, and then fails in production. A lot of Tapestry historically has been shielding the user so that code that appears to work in development will in fact be just as valid, threadsafe, session-aware, etc. in production. -- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
