On Oct 22, 4:20 am, sokol <[EMAIL PROTECTED]> wrote: Hi Sokol,
Good points, though I'm not sure we're on the same page. > "The point of template engines should be to separate your business > logic from your presentation logic, not separate your PHP code from > your HTML code" I'll address this point in detail below. > I choose PHP because: > 1. PHP syntax is accustomed for me and I know it very well. For this discussion, I am assuming that the audience is a team, not an individual. For individual power programmers, a templating system may be overkill and is obviously individual preference. > 2. PHP is most powerful template language. Too poweful? > 3. My IDE works with PHP well. Again, I am assuming a team with different tools and skills. > 4. Speed efficiency is very good (and if not, it could be improved > with caching) Point moot, as has been mentioned. Templates are compiled once to PHP, then cached. > My pint is that templates are not for designers but for coders, who > already knows PHP, so there is no need to create something else. I think maybe we are using the word "template" for far too many things. At some point, we start out with page(s) written in HTML - agreed? I my specific case, it is created by a 3rd party development firm, and consists of multiple files and pages. This HTML page has been called a "template" up to this point. What is that page called? Designed by designers. Then this gets "transformed" into a ... what is this called? PHP template? This page has ALSO been called a "template". Symfony template? success page? Coded by coders. Please help with the terminology, as these pages are different and the logical truth of the quote above depends entirely on which "template" one is discussing. We then do processing in Symfony, and end up with a page that is HTML, (rendered output), that should be basically identical to the first page, the difference being that the data is added. (important: this assertion is pretty much testable using automated test cases) The fact is, the intermediate result (PHP "templates") don't resemble the input nor the output. Nor much of anything else - it's not anywhere near valid XML, without the right tools it is unreadable and is rarely completely understandable, and it is nearly always "un- renderable". It can't be easily unit-tested. The code is neither functional nor object-oriented PHP. Helpers all have their own "syntax" that you have to learn as well. (arguably not a big deal but no more nor less difficult than learning a few basic tags like sf:foreach) Each and every coder has a different way of doing things, so even with the chaos described above the php templates become inconsistent. In short ... arguably the worst of PHP coding styles combined with HTML - all coded by hand, and usually by the most junior developers because, frankly, it's a boring repetitive task. There is no reason this intermediate "template" representation has to be so arbitrary. The goal isn't the separation of presentation / logic - which Symfony does do pretty well (though not perfectly, as it can be abused). The goal is to create a low-barrier bridge from the "design template" to the "php template". One that is automatically generated, renderable in a browser, accurate - and, may a dare say it - easy? for _both_ designers and coders. Hand processing the "design" template into the "code template" is currently a one way process, performed by a skilled<?) coder everytime the design changes, and arguably is one of the more error prone pieces of the development process, and one that is extremely hard to write test cases for. And this transformation has to be performed on every change iteration of the design. Boring, tedious work that costs time and money with no appreciable value added to the actual application - pure crud work, in the non database sense. I assert that that any organization with a mix of skillsets (designers and coders) working on the same project, with a limited budget and even small changes in design faces this problem many times during the project. On a more personal level, having to cut up these design templates every time the width changes from 770px to 780px - even trying to figure out what actually changed between HTML revisions so I can s/foo/ bar/g - is boring, tedious, error prone and not worth my nor my developers time. Hours better spent adding value to the application. It is that type of tedious stuff the computer should do. I guess I'm just too damn lazy[1] not to spend the time to build the appropriate software to automate this. Enough talk on my part - some people are convinced, some people aren't, most don't care - and it will be a plugin you can choose to use only if you find it useful. Right now, I need your help coding the first version of this ... which is most likely going to be a PHPTal-style XML parsing frontend, with an sf: namespace, and a "Symfony PHPView" backend generator (other generators possible), borrowing heavily from existing projects. New code will be released under the Symfony license, though other projects / components may be under different , compatible, licenses. Note: I originally pushed for Flexy ... It became obvious, though, that Flexy isn't the way to go. Discussion here has led down a different, and I hope, better. track - Did I leave something out? Nick [1] "LAZINESS: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
