On Fri, 2008-07-18 at 21:28 +0300, Sancar Saran wrote:
> Hello,
>
> I want to write some of my ideas about php performance and maintenance. Also
> you may consider this response to Robert's template systems arguments.
>
> I hope my english does not disturb too much.
>
> As a uneducated php developer, I have open mind to anything. I try lots of
> things. After so many projects, so many line of code here where I'm...
>
> 1-) Template systems
>
> Are usesless, they are cpu hungry, they are complex, they are bloated. Every
> template creator try to beat each other. And look that smarty. I wonder when
> they start to write their own sql interpeter.
*lol* Everyone's mileage may vary. But you've just made an extremely
broad and sweeping statement that cannot be true. If I elaborate on your
statement's core argument... then we may as well be using C to create
websites instead of PHP... I sure as hell don't want to do that, even
though C is far more efficient than PHP with respect to processor
efficiency.
> And of course I wrote one. Which can use sql, memcached and lots this that.
> Sure it was very good one. With memcache support it was very fast.
Couldn't have been very fast if you're complaining about template
engines sucking.
> So ? at end of the story, our html designers can't understand the system and
> start to wheening. Lots of code goes to junk...
You argue they can't understand a template's syntax, but in the same
post you argue for the use of PHP as a template engine... which implies
the need to understand PHP. I don't buy it. Also, it strongly depends on
who is producing the templates. Certainly some template solutions are
very complex, some are very easy.
> using inline php code for template is the best way. You can do what ever you
> want.
Best way for you maybe. I've used PHP as a template engine and some
things are extremely convoluted to perform. My own template solution
(which supports plug-ins) has a default XML tag system to facilitate
content block or processors. Fortunately it's my own tag implementation
that only requires the template tags themselves to be well-formed. This
has the advantage over PHP in that I can punt block rendering to tag
definitions with arbitrary parameters in whatever order is comfortable
to the content person. PHP would require a function with specific
parameter ordering and no missing parameters... or an array of
configuration entries. Additionally, by using tags to facilitate some
content structures, I can change these structures site-side on a whim
and the tags are expanded at compile-time NOT at run-time. Although I
can certainly include PHP code int he expansion to support run-time
aspects if necessary. Additionally, using an accumulator tag accumulator
output tag combinations I can target content in a page's content
template to the page layout template with exquisite ease. Try doing that
in PHP without using buffering and manual tracking of variables and
buffers. Similarly I can choose to include modules in my content
template and have the loading and processing of the module relocated to
the beginning of the output PHP script, thus punting content processing
till after all modules are loaded... which means if the module needs to
perform a redirect for whatever reason it can do so before content
output begins... or I can just leave the module to run where it is
included in the content. Content/code relocation is extremely powerful.
> Just use military grade dicipline yourself to do only read in template.php
> files.
My templates allow PHP if you want... but I've only done so in very rare
cases where I'm wrapping a legacy system that was poorly designed. So I
guess I get the best of both worlds... I can use all my template aspects
AND use PHP if I absoluely must... right inside the template. This is
the advantage to using a template solution that actually produces a PHP
script.
> 2-) Using XML and other kind of txt datastructure for storing someting...
>
> Are nuts ? why you store that data in external data structure. Is PHP arrays
> arent powerfull enought to store someting. ?
Sometimes you need to share data with non-PHP applications. Sometimes
you wants something that can later be edited by hand. Sometimes XML is a
fantastic solution and PHP serialize (or PHP script) is not. Sometimes.
> then guess what, if you use opcode cache (as APC). you dont need to spend any
> cycle to open, parse, check ect.
Op-code cache won't help you when you need to load that same data
structure in a python script.
> (and I don't say anything exporting your data to 3rd party system. or
> importing data from 3rd party system)
Oh. Well sometimes you still want to edit or read the data manually.
> 3-) You may apply number 2 to for sql operations.
> If you got lots of read sql operations and if the data can store in php array.
> (I mean if you don't need to sql language for searching data)
Depends, if you provide a configuration interface for a client, why
would you store it in a flat file? What if the configuration applies to
multiple redundant webservers. What if your filesystem is read-only and
all data is pulled from a DB server.
> You may generate some kind of cache system, which produces php output
>
> combining with apc your speed up was enormus.
You still need to pull that data form somewhere before you cache it.
> 4-) OO programming paradigm..
> I still don't believe full blown oo programming under php. And there where
> some areas to use php OO for fixin some design problems.
>
> Php does not have namespaces, because of this you may got variable or function
> name crashing.
>
> Also you can access php objects anywhere from your code.
>
> So ?
>
> With public static keywors. you can give your code a pseudo name space and you
> can access your data globally even doesn't write te everywhere like
> global $this, $that, $bleh;
>
> example
> class evo {
>
> public static $config = array(); // config array
> public static $lang = array(); // language array
>
> public static function get_module($o) {
> .....
> $return $array;
> }
> }
>
> you can store data in your variables
> evo::$config['this'] = 'bleh';
> and call them
> evo::$config['this'];
>
> anywhere in your code no globals no fuss no buzz.
>
> Of course there where lots of programmers around here to saying OO paradigm
> much more on that.
>
> I hope one the I found that much more :). for now all off them marketing
> buzzword for me.
I'm not sure where you're going with this. Some like OO, some do not. To
each their own. Use what works best for you without losing site of the
problem.
> 5-) function options...
> function hede($name=hede,$this=true,$bleh=0){
>
> }
>
> well it nice but what if I want to expand this function ? But I use that thing
> lots of location, shall I rewrite all of them... unh..!!!.
>
> A yes OO programming right ?
>
> but what about this.
>
> function hede($o){
>
> }
>
> $o was an array we can store everthing what ever we want to use in the
> function.
Yes flexible... but oh so tedious. Also, it's inefficient since
everytime you access a passed property you need to do an extra level of
lookup into the configuration array. Of course you do that with objects
anyways. Additionally, this means no contract is formed between your
function and it's expectations. If you want to force requirement of a
variable you now need to manually check it's existence.
> 6-) array in array out in the functions
>
> Well lets expand the number 5
>
> function hede($o){
> ....
> return $result;
> }
>
> $result was string containing our returns. But what if we want to return
> someting different ?
>
> So we have to create other function very similar to.
>
> And if we return data in array format, we can put anything in the array. with
> this we can even change behavior of the function for certain tasks
>
> function hede($o){
> ....
> return $o;
> }
Yes you can do that. I certainly hope I never have to maintain your
code. Everytime I want to use a value from one of your functions I must
first grab it from a returned array. I thought you wanted things
simpler.
<?php
$ret = calcCircumference( array( 'radius' => $radius ) );
$circumference = $ret['circumference'];
?>
Yikes.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
