On Thursday 30 November 2006 18:51, Paul Novitski wrote:
> With respect to separating code and markup, you said "sometimes there
> are reasons not to do so, for example, web services." What are some
> of those reasons?
At 11/30/2006 10:57 AM, Sancar Saran wrote:
What about performance ?
Web services tend to be quite small applications, but even for larger
ones I've never found performance to be an issue. Servers are fast
and built for this kind of work: opening and reading files, running
software. They have fast chips and big RAM. Regardless of which
technique you use, you're going to utilize server resources and get
your results in however many milliseconds.
A templating system requires the processor to merge content with
template. An inline markup assembly system requires the processor to
build the markup from function calls. Where is the technique that
doesn't take machine cycles?
What about compexity ?
I separate logic from markup in order to reduce complexity. I find
both PHP logic and HTML markup easier to write, read, proofread, and
modify when they're separate from one another (I use the word 'clean').
Those SO nice seperated template system produces lots of mini TPL files.
I'm not talking about "those template systems," whichever ones you're
referring to, I'm talking about programming style and practice. I
don't use any templating system you've ever seen. I roll my own
code. I can make my templates as few or many as the project deserves.
You only need to produce as many template files as you need and
want. Separation of markup from logic doesn't necessarily mean
separate files: when I'm doing somethign quick & dirty I'll include
the markup in the PHP file as a heredoc. What's most helpful to me
is to remove the markup tags and attributes from the PHP logic
structures as much as possible.
I haven't seen any templating system out there in the world that I
like, mostly because they mix the markup & logic too much for my
taste or because they don't let me design the markup precisely the way I want.
You have to include them...
Includes are easy. Actually I usually use file_get_contents() in a
function that selects accompanying CSS & template files programmatically.
You have to parse them.
Not necessarily. But if you do need to parse them, you need to write
the parsing engine only once.
Also you have to track and manage them.
Yes, as you must manage all the files that make up a project. Adding
a few more isn't a burden, especially if they bring clarity and
efficiency to the work.
And I'm not sure those template system gives you freedom. Because you cannot
change your site design with this tpl files. If you change them too much you
have to change your php code.
I beg to differ: you *can* change your site design if you're using
templates. That's part of the purpose of layer separation and
templating in the first place, to enable markup changes without
necessarily requiring software changes. You're free to change the
template and/or change the stylesheet and/or change the data source
according to your needs.
Although we talk of separating logic from markup from presentation,
these are not absolutely clean separations -- each component must
have hooks in the others, otherwise there's no basis for a
merge! Therefore if you change one component greatly enough, at
least one other component must change as well. This is true of HTML
and CSS, it's true of HTML and JavaScript, it's true of HTML and
PHP. It's true of any interactive components in any system. It's
true of PHP itself -- if you change a function's arguments or return
type or a class's methods, you'll have to change the parts of your
code that call that function or invoke that class. That's just the
way it is. I'm sure you wouldn't argue that we write our software as
one long mainline stream just to avoid includes and function
calls. But it sounds as though you're suggesting that logic & markup
should be combined in the same statements simply because you don't
want to have to change more than one component.
Really good website designs can make modification less
onerous. Layer separation is one of those techniques.
Fortunately there are many ways to accomplish similar goals. I'm not
claiming that my own programming preferences are the best, only that
they work the best for me. It's good that we take different paths --
that's how evolution happens. What I'm asking for are the rationales
so I can see if Satyam's methodology could work for me. I agree that
his pre-processed PHP looks very clean. If I thought markup should
be constructed incrementally with program logic I'd be tempted to use it.
...
And my point of view. Using <html tag <?php echo value ?> > <?php echo
value ?></htmltag> days are over...
I agree completely! I hate that messy crap that results from mixing
markup with PHP.
Sancar, you seem to have had some very negative experiences with
templating systems that were either hard to understand or poorly
designed. I sympathise with you, but you may have let your
disappointment cloud your perceptions on this subject. It isn't
necessary to throw out the concept of separation of markup from logic
just because many attempts to implement it have failed.
I'll be very interested to see where Satyam's pre-processor work
leads. It's possible, if not probable, that someday I'll be
convinced that inline markup assembly is as desirable as, say, inline
SQL processing.
Warm regards,
Paul
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
