[EMAIL PROTECTED] (Warren Vail) wrote in news:[EMAIL PROTECTED]:
> My own experience has shown that separation of a presentation layer > from an application layer, doesn't occur where we think it should. > HTML as a language has no capability to be dynamic, and if we are > going to ask that the page be dynamic, we are going to need to make > sure we don't attempt to split layers along language boundaries. > JavaScript, as we typically use it, adds some dynamic nature to our > pages, but often is not based on database content. This is where PHP > comes in and the split becomes more vague. If what the user sees, is > controlled by database content, then splitting presentation and > application layers becomes a frustrating exercise in theoretical > purity, that often adds to response times of applications. Certainly. This is not a theoretical exercise but frustration with dealing with my own code, trying to implement revisions, and basically feeling like I need a map of some kind to know where I am. That's why I'm interested in what other people really do rather than theoretical models they think might be the "purest." And it isn't just code and content separation, which isn't always practical as an absolute, but code separation. If I have a simple set of actions to perform, say a series of functions to enter data into a db, review the entry, edit the entry, etc. how can I organize my code so it is easy to maintain and so some things can be reused? Objects? Functions? Fuses? Switches? All of these have their adherents... I'm trying to find one that adheres to me-- i.e. that is usable without being so extensive and abstract that I spend more time trying to learn how to fit the framework than actually getting something done... c -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
