I completely agree. The recent discussion of "let's make Tapestry easier to use by incorporating broken ideas from completely broken solutions like jsp" has me worried. The reason I like Tapestry is that it currently doesn't encourage a lot of broken ideas.
Anonymous components will add gratuitous complexity. Embedding a mini language like OGNL inside TApestry is adding gratuitous complexity and encouraging bad behaviour. Mixing proceudural code into the templates and bindings polllutes the simplicity of the Tapestry model for a very, very marginal return. In the end, I'm willing to bet that what you initially gain in development speed by using OGNL will, over the life of a project, be lost many times over in debugging and maintaining "yet another" non-type-safe language script. >From: "Richard Lewis-Shell" <[EMAIL PROTECTED]> >To: "Tapestry Developer \(E-mail\)" ><[EMAIL PROTECTED]> >Subject: [Tapestry-developer] Re: Tapestry focus (was Marc Fleury issues) >Date: Thu, 10 Oct 2002 18:54:58 +1300 > >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 Joseph Panico [EMAIL PROTECTED] _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com ------------------------------------------------------- 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
