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]>
