Hi, thanks for the tips. I'm always interested in opinions on my writing style and how to communicate better.
Regarding your critique of Fragmentify, that's actually not so much what I'm advocating here as it is just the impetus for realising that there are 2 distinct components to templating which are: 1) the re-use of common assets, and 2) the application of some "logic" to display dynamic data.
It doesn't matter what you use to fragment your markup (I personally think that using XPath to manipulate an XML document isn't particularly off the mark but whatever, to each their own). Dreamweaver allows you to edit common assets pretty easily and then export a ZIP with head-to-foot complete HTML documents in it. I'm sure there are a million other ways to skin that cat.
What I'm saying is that the separation between "display logic" and "business logic" either doesn't exist or at the very least shouldn't be occuring between the backend and the frontend.
You could, if you wanted to, put your "view rendering" code in some other place in your application, but that's tangential to my case for completely removing any and all logic from templates and working solely with (and iterating solely with) HTML/CSS/JS when building your interfaces.
Personally I'd never use it because I intensely dislike the syntax of HTML and CSS and avoid it at all costs since discovering HAML/sass.
I find a text editor (vim in my case)/photoshop + haml/sass + live reload to be my most productive workflow, one screen for the text editor, one screen for the browser, when I save the browser reloads the page.
For me there are a lot of things that just work smoother by having the data populated, when I work with designers I just take whatever they give me (sometimes just a PSD) and work with it, if they need static HTML/CSS I just use wget/save as webpage to save the html and assets.
Regarding your critique of Fragmentify, that's actually not so much what I'm advocating here as it is just the impetus for realising that there are 2 distinct components to templating which are: 1) the re-use of common assets, and 2) the application of some "logic" to display dynamic data.
It doesn't matter what you use to fragment your markup (I personally think that using XPath to manipulate an XML document isn't particularly off the mark but whatever, to each their own). Dreamweaver allows you to edit common assets pretty easily and then export a ZIP with head-to-foot complete HTML documents in it. I'm sure there are a million other ways to skin that cat.
What I'm saying is that the separation between "display logic" and "business logic" either doesn't exist or at the very least shouldn't be occuring between the backend and the frontend.
You could, if you wanted to, put your "view rendering" code in some other place in your application, but that's tangential to my case for completely removing any and all logic from templates and working solely with (and iterating solely with) HTML/CSS/JS when building your interfaces.