PHP no nos

[.josh]

eh... at the end of the day, if that works for you, then go for it.  I personally don't see the benefit in swapping one syntax for another.  Running a validator is IMO not that big a deal.  Not to mention, I don't really see how that code maintains the spirit of MVC.  If I were a designer just trying to focus on content and html, I'd have to learn to code to do it your way. 

[roopurt18]

I consider this an interesting discussion so I'll keep addressing issues as I have time and people bring them up.  In other words, not to be a pain in the ass and not to defend my choice.

 

I don't really see how that code maintains the spirit of MVC

Designers are not capable of creating a proper view in the first place.  The view is going to have PHP variables and data objects flying in from the controller and the designer is not going to know how to interact with them properly or they're going to have to write some sort of scripting code anyways.  If the application has a "heavy" JavaScript UI the designer is not going to know how to add the extra markup classes or IDs you need to get the JavaScript to work correctly.

 

If I were a designer just trying to focus on content and html, I'd have to learn to code to do it your way.

Designers should create the layout for the site and create "copy-me-templates" that the developers use to build menus, forms, or other UI elements.  In other words, the designer should create the XHTML layout and then create sample files of the markup for forms, menus, or whatever else.  Then the developers should use those sample files as how to spit out the markup the designer wants.

 

Running a validator is IMO not that big a deal.

It depends on if the page has any JavaScript generated content or not.  When you choose to "View source," most browsers only give you the source the page originally loaded with.  With a FireFox extension, you can choose to "View Generated Source," which will give you the source as the page is right now.  It will also include any extra markup inserted by plug-ins such as firebug, so it's not truly the source your PHP code is kicking out.  You can expand DOM elements in firebug and choose "copy innerHTML" to see their contents, but again it will not be the exact source your PHP code kicked out.

[.josh]

Designers should not be making html "templates" to be handing to coders.  Coders should be making a system that designers can use, so they can easily add new pages/content.  It is pages/content that is constantly being added to a site, not code.  Look at any CMS as an example.

 

And yes, javascript generated content will not show up in the view source, and you are correct, you would need a live DOM inspector to see that...but I can take your argument and apply it to your own class.  PHP kicks out the javascript etc... there is no way for php to know ahead of time what it's going to do with whatever you give javascript.  Javascript is going to take what you give it and do its thing client-side, and you may or may not get errors (and they may or may not be browser (version)? specific, and php ain't gonna know anything about it.

[roopurt18]

Coders should be making a system that designers can use, so they can easily add new pages/content.  It is pages/content that is constantly being added to a site, not code.  Look at any CMS as an example.

When static content is being added to a site, developers should not be involved.  You're absolutely right.

 

Designers, not developers, should be designing how a site should look.  Again we both agree.  So it's up to the designer to decide how a form should be constructed.  Which tags should be added and in which order.  It is up to the designer to create the necessary styles and classes to make forms look nice and aligned for block elements and inline (such as city, state, zip all on one line).

 

I'll even agree that for most sites, it is pages and content that is being added.

 

However, I mostly develop web applications.  I might have two or three pieces of static content; everything else is highly interactive user interface tied closely to a database.  I'm constantly adding fields to the database, updating the fields in the UI, updating the JavaScript to do special things with the fields, adding validation logic attached to the fields, writing specialized queries to present data in a specific way, etc.  There's no way a designer could keep up with me.  In this environment, it would be much better for the designer to say:

"Hey,  I made a nice layout for your application.  I gave you a template for your forms so they all look nice.  As long as you adhere to my template, your application will look nice."

 

I'm not quite sure what you were trying to say in the second part of your post.

[gizmola]

roopurt --

  I think that your framework works for you, and if that's what makes you efficient, then there's no need to defend yourself.  However, I agree with CV, that in a traditional development house where they have a breakdown of wedevs and webdesigners, the designers usually are able understand what they need to in the creation of templates.  It's the developer's job to get what they need into the view in a form that is useful for that particular template.  This is where template systems have tried to provide value and reusability whether that be through a template scripting language like smarty or through one that allows for drop in of php, short tag format, and view helpers and partials.  Designers typically can understand the rudiments of looping, and in some cases are full blown developers who know js, html and css very well, but may not know php. 

[roopurt18]

I'll leave that part of the discussion alone as it'll just go in circles at this point.

 

So back on topic, and I may have missed it if it's been discussed, I can't stand it when people lose readability for non-optimizations or perform just plain silly optimizations.

 

For example using all single quotes instead of double quotes.

 

Or rather than using temp variables creating long chains of nested functions like:

echo implode( ', ', array_reverse( array_map( 'trim', /*you get the idea */ ) ) );

 

Or; Put; Everything=Onto; One; Line;

 

Or writing code that extends miles past the 80 character margin.

[.josh]

@roopurt: okay for your situation I can see how you would say doing it that way might work out better for you, so if that works for you, then more power to you

 

For example using all single quotes instead of double quotes.

 

Agreed.  And to extend that, I hate how people liberally escape quotes to make up for stuff like that.  How can having a long string of escaped quotes possibly help anybody? I've seen more than plenty of syntax errors posted on the forums that were due to people getting lost in their quoting endeavors.

 

Or rather than using temp variables creating long chains of nested functions like:

echo implode( ', ', array_reverse( array_map( 'trim', /*you get the idea */ ) ) );

 

Agreed.  At best, this does not help readability.  At worst, it hurts error handling capabilities. 

 

Or; Put; Everything=Onto; One; Line;

 

yeah... I really don't see the point in this, with few exceptions, like for instance, a switch with a bunch of single line code blocks. I don't have issue with the break; being added to the end of them.

 

Or writing code that extends miles past the 80 character margin.

 

To be fair though, this is kind of a hangup from the good old days.  With high res monitors, 80 chars wide should not be a big deal, except catering to people who refuse to update their hardware...on the other hand...I guess trying to sort through shit from a command line might suck, but I'd counter that with..why are you messing with a script from a command line instead of a real editor anyways?

 

 

 

 

[roopurt18]

To be fair though, this is kind of a hangup from the good old days.  With high res monitors, 80 chars wide should not be a big deal, except catering to people who refuse to update their hardware...on the other hand...I guess trying to sort through shit from a command line might suck, but I'd counter that with..why are you messing with a script from a command line instead of a real editor anyways?

 

At university I did all of my C coding via 80 char wide telnet session, so I completely understand the hang-up.

 

Even after I started using fancy IDEs I stuck with 80 char wide for a looooong time.  Within the past year I've become a bit more lazy and will go to like 120 chars wide for some things.

 

Every once in a while I end up editing a file live on a remote server (to try and figure out WTF is wrong with it) and get stuck with that 80 char limit again.

[nrg_alpha]

Or rather than using temp variables creating long chains of nested functions like:

echo implode( ', ', array_reverse( array_map( 'trim', /*you get the idea */ ) ) );

 

Or; Put; Everything=Onto; One; Line;

 

Ohhh even better.. how 'bout nested ternary operators? 

 

$test = 'one';
echo $test == 'one' ? 'one' :  $test == 'two' ? 'two' : 'three';
/* Ultimately evaluates to 'two'; as the initial test for $test evaluates as 'one'
* however, (in the wise words of Billy Mays "But wait! There's more!") that 'one' is now checked to see if it is in turn true...
* in which case it is, thus 'two' of the final 'two' or 'three' choice is chosen. Nice way to cluster f#$k the mind.
*/

[oni-kun]

Or rather than using temp variables creating long chains of nested functions like:

echo implode( ', ', array_reverse( array_map( 'trim', /*you get the idea */ ) ) );

 

Or; Put; Everything=Onto; One; Line;

 

Ohhh even better.. how 'bout nested ternary operators? 

 

$test = 'one';
echo $test == 'one' ? 'one' :  $test == 'two' ? 'two' : 'three';
/* Ultimately evaluates to 'two'; as the initial test for $test evaluates as 'one'
* however, (in the wise words of Billy Mays "But wait! There's more!") that 'one' is now checked to see if it is in turn true...
* in which case it is, thus 'two' of the final 'two' or 'three' choice is chosen. Nice way to cluster f#$k the mind.
*/

 

Those used to confuse me, but I never got around to learning them, After learning what they do that seems very simple. It's sorta like pseudocode, "Does $var have 3? Then do: displaymsg() else: displayerror()"

[Daniel0]

Yeah but not when you nest them. Readability should never be sacrificed in favor of fewer lines. The code is for you and other humans to read after all.

[gizmola]

Yeah but not when you nest them. Readability should never be sacrificed in favor of fewer lines. The code is for you and other humans to read after all.

 

++

[oni-kun]

Yeah but not when you nest them. Readability should never be sacrificed in favor of fewer lines. The code is for you and other humans to read after all.

 

Ternary operators are slow as well. 10,000,000 iterations that (statement) returns:

Longhand: 16.7164548893(s)

Ternary: 19.1882539418(s)

[Daniel0]

Right, so in average it's 0.000000247 seconds slower on your system? You better watch out it doesn't kill your server

[oni-kun]

Right, so in average it's 0.000000247 seconds slower on your system? You better watch out it doesn't kill your server

 

I've experienced many handfuls of people say using explode/substr/str_replace combined, sometimes in a loop, together are more 'efficient' than the 'heavy' use of a simple preg_match. 10,000,000 requests in (24ms)? If they had that much, they would be in space on their own moondome with alien spacebabes and a mountain of floating Tequila.

[nrg_alpha]

In the event of say preg_match vs built-in functionality like str_replace, explode, etc, it's circumstancial. Typically, while regex is extremely robust and useful, it is heavier (as there is more overhead involved). Depending on the task at hand, sometimes it does make sense to use those built-in functions as opposed to regex. In reality, it appears that in most cases, the speed difference comparison between both methods won't amount to anything special (but again, it highly depends on the task at hand and the data involved). Often you'll see benchmarking tests with a loop involving thousands of iterations, and the difference between methods is so small that on a reasonable amount of looping, it will even make less of a difference (we humans won't be able to tell the speed difference).

 

Having said that, I am personally an advocate of squeezing out performance (as a generality anyways). If the situation calls for making better use of built-in functions over regex, so be it. That's the way I'll go (or vise versa). Squeezing out extra performance juice never hurts IMO. But admittedly, the speed differences are most likely to be infinitesimal at best in most real world situations.

[.josh]

overall I lean towards readability.  I get off to regex but most people run away screaming even thinking about it.  If I can accomplish the same thing using an strpos and an explode or some other similar thing, I'll usually go for that, as it would be easier for future people touching it to figure it out. 

[roopurt18]

I use regexp all the time when I need to validate formats or extract portions of a string.  Although I do agree the regexp engine is probably more "heavy" than basic string operations.

[Lamez]

I use regexp all the time when I need to validate formats or extract portions of a string.  Although I do agree the regexp engine is probably more "heavy" than basic string operations.

 

<?php
function checkEmail($email){
if(filter_var($email, FILTER_VALIDATE_EMAIL)){
    	   return true;
}else{
    	   return false;
}
}
?>

[oni-kun]

I use regexp all the time when I need to validate formats or extract portions of a string.  Although I do agree the regexp engine is probably more "heavy" than basic string operations.

 

<?php
function checkEmail($email){
if(filter_var($email, FILTER_VALIDATE_EMAIL)){
    	   return true;
}else{
    	   return false;
}
}
?>

 

And what do you think filter_var does? For all we know it could be running many times heavier calculations backend.

 

Strpos is faster, but I meant the sheer uses of some of it is slower than preg_match. What I'm getting at is they're (users who are bias to str* functions) try to 'emulate' the function of the patterns, it makes no sense, and is indeed slower in most standard cases that could use preg_match and succeed in less lines and function calls.

 

Two wrongs don't make a right! But three rights makes a left? 

[salathe]

And what do you think filter_var does? For all we know it could be running many times heavier calculations backend.

With regards to the email filter presented, all that it does is run the value through a regular expression. Nothing magical nor complicated.

[.josh]

And what do you think filter_var does? For all we know it could be running many times heavier calculations backend.

With regards to the email filter presented, all that it does is run the value through a regular expression. Nothing magical nor complicated.

 

well sir, that's where you are wrong. regex is magical. 

[salathe]

regex is magical.

Hehe, oops my mistake.

[oni-kun]

regex is magical.

Hehe, oops my mistake.

 

So using var_filter is automagically faster than regex and strpos because it's 'neither' according to them! And now:

"I'd recommend using var_filter(), It's much faster than regex."

"Why use such a heavy function for such a simple thing? Obviously use input_filter() for this."

...

[Philip]

"I'd recommend using var_filter(), It's much faster than regex."

"Why use such a heavy function for such a simple thing? Obviously use input_filter() for this."

 

Who said these?