On Feb 16, 2007, at 8:32 PM, Kent Tong wrote:
So, what you're really saying is that people are going to prefer option A:<t:comp id="showProperties"> ... <t:comp id="propLoop"> <dt>${propertyName}</dt> <dd>${propertyValue}</dd> </t:comp> ... </t:comp> with public void configure_showProperties() { _showProperties.setTest(getShowPropertyList()); } public void configure_propLoop() { _propLoop.setSource(getInfo().getPropertyNames()); } to: <t:comp type="If" test="showPropertyList"> ...<t:comp type="Loop" source="info.propertyNames" value="propertyName"><dt>${propertyName}</dt> <dd>${propertyValue}</dd> </t:comp> ... </t:comp> with ... nothing ...Yes, I believe more Java users prefer option A especially when most of the Java code in option A can be generated using a code template. There is really no much more typing required, while we enjoy the warm and fuzzy feeling of compile-time checking and auto-completion.
Sorry to say this, but option "A" is essentially a half-baked implementation of Wicket, without any of that framework's elegance or consistency. It seems to utterly contradict the primary goals of Tapestry 5 which, as I understand them, are to bring some of the advantages of *dynamic languages* to a Java web framework in addition to refining the concepts developed in earlier versions of Tapestry -- none of which emphasized static typing.
It would be a serious mistake to build two fundamentally different philosophies into Tapestry 5 and expect users to perceive the schizophrenic result as "flexible." They won't -- they'll only find it confusing and will move on to other, more coherent frameworks.
Regarding the more fundamental issue of run-time vs. compile-time type checking, Howard has apparently worked miracles to mitigate one of the primary disadvantages of run-time checking by providing (for the first time, I believe) ZTT in a Java web framework. ZTT is precisely why developers who work with dynamic languages don't seem to miss compile-time checking. They write some code, run the app and it either works or it doesn't. With ZTT, it's so quick and easy to run your code that bouncing back and forth between coding and testing is really no big deal.
I also have to note that, based on the total lack of support from users or developers for the concept of "type-safe Tapestry", I'm afraid Kent is the only one who doesn't see that he is pulling in a different and ultimately counterproductive direction.
I apologize for being so blunt, especially since I'm not a Tapestry developer (besides a couple of minor patches) and only sporadically contribute to the user list. However, this particular issue appears very clear-cut to me and I think if Tapestry developers have a similar opinion (which I suspect they do) they should put the kibosh on this and move on towards a 5.0 release.
-Ryan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
