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). That being said, and everything else being equal (talk about equivocating!!), the MVC model and it's functional separation is probably the best approach. 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, (b) the Developer needs a RAD capability (perhaps to quickly prototype a potential solution), (c) the Designer is fully trusted (so you don't have worry about intentional or unintentional goofs), or, (d) the Designer has a reasonable skill with procedural structures. In addition, such deviations may be justified where (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). 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. Just my $0.02. Regards, Terry Steichen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
