(no subject)
Pardon me for a moment while I do a bit of ranting on web templating.
Generally speaking, when you are building a dynamic web page (it is rendered based on information from a database, user input, ...) the standard mode of thinking is that you should separate your application and business logic from your templates. Why? Because embedding what your application does as part of rendering the html generally causes some nasty issues that all come together to make code unmaintainable.
Recently, I've been doing a small bit of paid ColdFusion* development as a favor. ColdFusion was a language designed, more or less, to give web pages the ability to fetch and render information from a database. More recent versions have thrown in the proverbial kitchen sink, offering most of the operations one could expect from a full-on programming language, including (from what I can tell) the use of java libraries, calling out to the command line, and reading/writing files.
Personally, I can see the desire to want to quickly fetch data from a database to display. But that's a slippery slope; soon you'll be accepting form variables, storing the data in the database, ... What was once a simple "oh, we'll just be displaying some data" soon becomes a full on application. And because of the ... ugliness of an xml-based programming language syntax, everyone's productivity dealing with it goes to crap.
PHP is another one of these languages. On the upside, at least it doesn't use XML (similar to C++). The downside is that everyone and their brother thinks that they know php, so everyone is writing a huge amount of crap php web pages, and I've so far not heard of anyone not embedding everything in php (though at least it's got Smarty and other validation toolkits).
There's also JSP, ASP, ... which use templates very similar in syntax to PHP with different languages.
Other templating languages, like Cheetah and Spitfire, allow the "do everything in the template" technique, but both (as well as pretty much all Python-backed templating languages) require the use of a parent server that commonly handles form validation, database/object manipulation, etc. Heck, in the Cheetah and Spitfire I have my fingers in, the act of doing anything related to the database in a template is publicly shamed.
Please make Josiah happy, separate your web application code into layers:
* database code (this actually makes database calls)
* object logic (you can combine this with database code with an ORM, but those usually produce *insane* database schemas ... though Google's appengine does this really nicely)
* business logic (this can be combined with object logic in most situations, or at least hang out in the same files)
* server logic (this should always be separate from all other layers)
* templates (this should perform basic rendering operations on pre-populated objects)
It's not just a different design to be different, it's a different design to make your application maintainable in the future.
Thank you.
* ColdFusion was developed by the Allaire brothers, at least one of which went to Macalester, which is my alma mater.
Generally speaking, when you are building a dynamic web page (it is rendered based on information from a database, user input, ...) the standard mode of thinking is that you should separate your application and business logic from your templates. Why? Because embedding what your application does as part of rendering the html generally causes some nasty issues that all come together to make code unmaintainable.
Recently, I've been doing a small bit of paid ColdFusion* development as a favor. ColdFusion was a language designed, more or less, to give web pages the ability to fetch and render information from a database. More recent versions have thrown in the proverbial kitchen sink, offering most of the operations one could expect from a full-on programming language, including (from what I can tell) the use of java libraries, calling out to the command line, and reading/writing files.
Personally, I can see the desire to want to quickly fetch data from a database to display. But that's a slippery slope; soon you'll be accepting form variables, storing the data in the database, ... What was once a simple "oh, we'll just be displaying some data" soon becomes a full on application. And because of the ... ugliness of an xml-based programming language syntax, everyone's productivity dealing with it goes to crap.
PHP is another one of these languages. On the upside, at least it doesn't use XML (similar to C++). The downside is that everyone and their brother thinks that they know php, so everyone is writing a huge amount of crap php web pages, and I've so far not heard of anyone not embedding everything in php (though at least it's got Smarty and other validation toolkits).
There's also JSP, ASP, ... which use templates very similar in syntax to PHP with different languages.
Other templating languages, like Cheetah and Spitfire, allow the "do everything in the template" technique, but both (as well as pretty much all Python-backed templating languages) require the use of a parent server that commonly handles form validation, database/object manipulation, etc. Heck, in the Cheetah and Spitfire I have my fingers in, the act of doing anything related to the database in a template is publicly shamed.
Please make Josiah happy, separate your web application code into layers:
* database code (this actually makes database calls)
* object logic (you can combine this with database code with an ORM, but those usually produce *insane* database schemas ... though Google's appengine does this really nicely)
* business logic (this can be combined with object logic in most situations, or at least hang out in the same files)
* server logic (this should always be separate from all other layers)
* templates (this should perform basic rendering operations on pre-populated objects)
It's not just a different design to be different, it's a different design to make your application maintainable in the future.
Thank you.
* ColdFusion was developed by the Allaire brothers, at least one of which went to Macalester, which is my alma mater.