I would like to suggest that anonymous components might not make Tapestry simpler to learn. By adding anonymous components, you will be telling newbies that there are two places to look for a component definition, instead of just one. As I see it, the distinction is quite clear. Sure it took me a while (in the WO days) to figure what goes where, but now I'm there, I really like being able to see an exception/error report, and know exactly which file contains the error. Full credit must go to Tapestry's error reporting - top notch.
It just seems simpler to me to explain to someone that if you see a jwc tag or a jwcid in a tag, it means Tapestry will be replacing that tag, so go look in the 'Tapestry file' to see how it will do that - your code goes there. Simple. If OGNL isn't enough for you (and in a heck of a lot of cases these days, it will be!), and you need some helper beans, or a custom component/page implementation, then you can set them up in the 'Tapestry file'. This is simple because there are no blurred responsibilities - it is clear what goes where. I suppose it would be clear too if there was some way to define parameters in the template, and define assets and helper beans too so it was all in one file (except the component/page Java implementation), but then you have to try and trawl through an HTML nightmare to find your code, and then we're back to JSP. I like having my component type in the same place as its parameters, and I like that place being the same place as the other Tapestry hookup code that is needed (assets, helper beans etc). What makes this confusing is not necessarily the 'complexity' of the the framework it's the complexity/paradigm of other frameworks that must be unlearnt. Whenever I have to teach someone Tapestry, the first question I ask them is "do you have JSP experience?". Usually they answer "yes", expecting me to be pleased or to say "good", but I don't. Having the JSP mindset just seems to confuse everything, and it really does have to be unlearnt. I think it would be better to put the effort that would be required to develop anonymous components (and other such 'newbie friendly, but 'ideal distorting' concepts) into making "Tapestry for Dummies" type documentation - provide some shade and cool beverages along the learning curve hike rather than try to flatten it out. Either that or put the effort into making Tapestry play with other frameworks to help migrate from those other frameworks to Tapestry. But I want JSP integration, not JSP assimilation (actually, I don't want JSP integration at all, but I can see its merit). Or another, better (already mentioned) way to utilise efforts - put it into a cohesive set of prebuilt components. These are the things that Tapestry needs - make the rewards high, rather than the drawbacks low. So at the end of the day, this just seems to be a complex thing to get the hang of - why is that necessarily a bad thing? Do we want to turn Tapestry into a VB just so that any old Joe Schmoe can understand it? I appreciate Howard's desire for mainstream acceptance, and some more visibility would be great (though it has picked up a lot recently - I wonder why?). But I am not sure that I buy into the vision of making Tapestry THE Java web developement framework - there are always going to be alternatives, and IMO, there will always be more popular alternatives than Tapestry (we are just too late, no matter how much better we are!). And having alternatives is a good thing... Rant over. Thanks to all who contribute positively to this excellent framework. Richard ------------------------------------------------------- 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
