I think something to consider is that not everything is Black and White, or should I say Logic and Presentation. I think that the variation of the owner field mentioned below is an example of "Presentation Logic" (a grey area) You want to maintain 1 form to handle multiple purposes. Don't make the form so smart that it knows exactly how to tell if the user is an owner or not, just make it just barely smart enough to know whether or not to show that field. And let your business logic set a special variable that the form is looking for.
I do this sort of thing all the time when building a form that will be used for initial creating and subsequent editing of a record in a DB. the form might end with something like this. (very simple example just to illustrate a point)
<@ifempty <@var Request$presLogic_IsEditing>> <input type=submit name=submit value="Create My Account"> <@else> <input type=submit name=submit value="Edit My Information"> </@if>
You could use the same thing at the top of the form to change the action that the form submits too. All the while only having to maintain 1 form (from a look and feel standpoint)
Your Logic would just have to remember to assign a value to "Request$presLogic_IsEditing" If you have a standard for naming these variables you end up with nice easy to edit presentation code (with a few tags here and there) and clean logic that doesn't care about presentation issues, or worse "build" presentation code.
/John
William M.Conlon wrote:
I'm embarking on some major enhancements to an application, and I'm wrestling with this issue, so I thought I would ask where others come down on this issue.
For relatively simple apps, Witango makes it easy to put separate rules from presentation. Rules go in actions, and presentation goes in resultsHTML.
But as things get complex, there can be an incentive to use metatags in place of actions to reduce the size of files. One extreme would be to write SQL statements with lots of <@IF>, etc, so that the logic is embedded in the SQL query, and one DirectDBMS action could generate a range of queries. I kind of shy away from this, even though it would be convenient, and would tend to use IF actions to split my queries into distinct cases.
On the other hand, I have tended to put some business logic into my ResultsHTML, so I only have to maintain presentation element. Here's an example -- a new record form. If it's a regular user, the owner field is fixed by the userid; if it's an admin user, I present a select form element to allow the owner to be chosen. Here, I would take the position that I would rather embed some logic in presentation, than have to maintain HTML variants for each class of user.
I suppose that an Object-Oriented approach could work, but that seems like a lot of effort, and I'm not sure that encapsulating logic and presentation in a class file is any better from a long-term maintenance perspective.
What do others do in practice?
bill
________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
