Jon, It would be nice to see a simple, informative, non-ridicule comment from you.
But, alas.... 1) Your assertion that I agree with you reflects something other than my views. (Hint1: what do you call it when someone declares they know what I believe when that is at odds with what I actually do believe? Hint2: It starts with an 'A'. ) 2) Regarding RAD, the advantage of making a change in the template and running the change immediately is much faster than a recompile and restarting the servlet container. (The ratio, for Tomcat, is about 15:1, all things considered.) 3) Absolute trust in the developer and absolute distrust for the designer isn't 'reality world'. (I have another term for it, but won't engage in the ridicule I object to.) 4) If your statement is true that appropriate code reuse is only achievable by use of JSP, we're really in trouble. (But I don't buy it at all.) 5) I admit to not knowing much about Turbine - For nearly a year I have been using a different framework (with Velocity) that works great so I've had little reason to learn about yet another one. Far from trying to 're-invent Turbine', I've just been ignoring it. Regards, Terry ----- Original Message ----- From: "Jon Scott Stevens" <[EMAIL PROTECTED]> To: "velocity-dev" <[EMAIL PROTECTED]> Sent: Sunday, May 19, 2002 4:03 PM Subject: Re: ToolLoader tool > on 5/19/02 12:05 PM, "Terry Steichen" <[EMAIL PROTECTED]> wrote: > > > I believe we start confusing ends and means when we get too strident about > > defining what a so-called Designer 'should' do, and what a Developer > > 'should' do - especially when we seek to have software 'enforce' that set of > > 'shoulds'. > > > > We, of course, have lots of experience accumulated regarding what might be > > called 'best practices', and we are wise to take full advantage of that > > experience. (As was mentioned, there are 'years' of discussion on this in > > the various lists.) But too often the declaration of 'shoulds' takes on a > > kind of religious 'truth' (the intensity of which is often reflected in the > > heavy use of CAPITAL LETTERS to blast this 'truth' into the consciousness of > > questioners, heretics, blasphemers -sp? or merely the dim-witted). > > People need guidance. This is done by providing a framework of best > practices and letting them figure out that that framework is trying to tell > them. Since this is the velocity DEVELOPERS list, one can assume that the > people here care about helping develop a tool and set of practices that > others can use. This is exactly where the should's and must's should be > discussed. > > > That being said, and everything else being equal (talk about > > equivocating!!), the MVC model and it's functional separation is probably > > the best approach. > > In other words: > > "I agree with Jon cause he knows what he is talking about, but since I'm not > able to directly agree with him for fear of actually admitting he is right, > I'm not going to admit it directly." > > ;-) > ;-) > ;-) > > > However, there are other situations in which may well justify deviations > > from that approach. Examples that come immediately to mind include those in > > which (a) the Designer and the Developer (and, most importantly, the > > Maintainer) are (and will remain) one and the same, > > IMHO that even more of a reason to do it right. > > > (b) the Developer needs > > a RAD capability (perhaps to quickly prototype a potential solution), > > It doesn't take any longer to develop things with the model I'm talking > about. > > > (c) > > the Designer is fully trusted (so you don't have worry about intentional or > > unintentional goofs), > > Sorry, I live in reality world. ;-) > > > or, (d) the Designer has a reasonable skill with > > procedural structures. In addition, such deviations may be justified where > > Sorry, I live in reality world. ;-) > > > (e) the design of the particular system is such that the best overall > > code/function reusability is accomplished by adding a bit more complexity to > > the template (than would otherwise be considered ideal). > > Wow, you should work for Sun and push JSP. ;-) You almost have a convincing > argument. Not. ;-) > > > IMHO, Velocity would ideally be structured to default to the MVC model, but > > would allow (without too much convoluted effort) to support situations such > > as those listed above. > > Velocity is already there...nothing in Velocity is going to change regarding > supporting anything that already exists... > > What needs to be figured out is if you guys are going to re-invent Turbine > or not. ;-) > > -jon > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
