This is getting too philosophical for my taste. There are many reasons to
justify different ways of programming and each user, according to his/her
requirements, experience and circumstances weights them differently and may
decide in a different way. I am not about argue in favor of any one method.
I just developed a program that might help one of those particular methods,
which anyone is free to choose or not to. If you find it useful, I am happy
to help, if you don't, that is fine with me.
Satyam
----- Original Message -----
From: "Paul Novitski" <paul@xxxxxxxxxxxxxxxxxxx>
To: <php-general@xxxxxxxxxxxxx>
Sent: Friday, December 01, 2006 1:47 AM
Subject: Re: Tidy HTML source?
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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
