Hi everyone. This last post of mine about default bindings, and also some work that I do currently gave way to little chiming about Tapestry's simplicity (or complexity), and simplicity in general.... I will try to stress out importance of simplicity.
Knowledge is good. Gaining knowledge about piece of software such as Tapestry is good. But there's one bad thing that happens when you gain knowledge - you easily start to forget how was the time when you didn't have it. How was to be newbie? And newbies have to learn. They appreciate simple things. They don't want to subscribe to mailing list to ask about problems. They want to read UserGuide, a short one, and start working. One has to take care of newbies, because 70% developers are them. Tapestry is powerful. But it is quite complex. I know that someone could say that it's because of different way of thinking than typical request-driven MVC aproach, but believe me, it's complex. I remember myself beggining with it 1,5 years ago. Now that I look at it, one cause of complexity was because of Tapestry's way to offer multiple ways of doing things. At first, it looks cool when you get provided with multiple options, but hey, multiple options take time to learn compared with single option. One could say that you don't have to learn option that you don't like, but during development one has to look at other people's stuff, co-workers stuff, tutorials on the web etc.... And these pieces of software has maybe picked other option that you didn't, which you have to learn to understand it. At the end, you have to learn whole Tapestry to be able to handle it properly. Here are the examples: - ActionLink and DirectLink : former is *kind of* deprecated, but not really, so we still have it in framework - manual and automatic handling of properties: I hate "abstract" keyword used for this, but it's much easier sometimes - implicit and explicit components - setting binding values (my last post) in 3 ways - PageRenderListener and overriding prepareForRender(): both for single purpose-> pre-render initialization (depends whether it is page or component) - Foreach and ListEdit - manual field validation, or using ValidField in some cases (when working with text fields) ..and probably some others... Of course, adding new options made work so much easier in some cases, thus it was reason to import them into framework. So, you gain more power, but you gain more complexity. It's maybe best to look through User Guide. If newbie suddenly comes upon one whole page of documentation, whereas there was half of it in the last version of software, then you surely have lost some quality. So sometimes it has to be asked - was it worth it? Of course, plenty of things become more powerful *and* simplier in new versions: For component unifying Foreach and ListEdit, removal of "direction" is totaly awesome, etc... Inspiration for this post came this morning, when I was writing UserGuidefor my remoting library that is supose to be distributed to third-party companies. I thought documentation will be quite short considering that library is very simple to use. But when I started writing it, I realized I forgot to include "Logging" section because I assumed everyone knows what Commons-Logging is. But suddenly I realized that bunch of people in big-corporate companies, with vanilla programmers, never even heard of it, thus I needed to include this section. Then more of this things kept coming in, and I had to force myself to think the way newbie does. Cheers, Vjeran -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 10.5.2005 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
