v1nce posted:

Duck, I get that you're trying to limit the amount your designers can do, to avoid them injecting all sorts of horrors directly into the View, but picking a restrictive template system to achieve this isn't the right way to go in my opinion. You either have to learn to trust your co-workers, or you need to run code reviews on stuff they write.

In regards to separating code and display in the templates, I find raw PHP allows for much better separation then Smarty. It's far more readable to a developer on first glance if it's not written like garbage, and a good IDE can actually trace the origin of variables.

For example, if I want to list users, and keep track of the active user:

php:

<?
<table id="myUsers">
<?php
// track active user
$active = '';

// List my users
foreach ($users as $user)
{
    // on-the-fly adjustments; I could do this inline, but I like this method as it makes the vars look cleaner in the HTML.
    $name = ucwords( $user['name'] );
    $birthday = date('Y-m-d', $user['birthTimestamp']);
    $active = ($user['active'] ? $user['name'] : $active );

    ?>
        <tr><td><?php echo $name; ?></td><td><?php echo $birthday; ?></td></tr>
    <?php
}
?>
</table>
<p>Active User: <?php echo $active; ?></p>
?>

Compared to smarty:

php:

<?
<table id="myUsers">

{* Track active user *}
{assign var='active' value=''}

{* List my users *}
{foreach from=$users item=user}
    <tr><td>{$user.name|ucwords}</td><td>{$user.birthTimestamp|date_format:'%Y-%m-%d'}</td></tr>
    {if $user.active}
        {assign var='active' value=$user.name}
    {/if}
{/foreach}
</table>
<p>Active User: {$active|ucwords}</p>
?>

We've made multiple systems using Smarty and PHP templates, and I can tell you from experience I'd much rather work with a PHP-based "template" than Smarty any day of the week. I can see your reasons, but I think it's just going to kick your rear end at a later date.

That said, i'm not saying to set a bunch of variables and then include() your template PHP file; I'm still advocating the use of a view layer with segregated variables and the separation of business and view logic, all I'm saying is; don't try to prevent logic in your View and make it impossible to use any kind of PHP, because one day you'll really need it.

v1nce posted:

Duck, I get that you're trying to limit the amount your designers can do, to avoid them injecting all sorts of horrors directly into the View, but picking a restrictive template system to achieve this isn't the right way to go in my opinion. You either have to learn to trust your co-workers, or you need to run code reviews on stuff they write.

In regards to separating code and display in the templates, I find raw PHP allows for much better separation then Smarty. It's far more readable to a developer on first glance if it's not written like garbage, and a good IDE can actually trace the origin of variables.

For example, if I want to list users, and keep track of the active user:

php:

<?
<table id="myUsers"><?php// track active user$active = '';// List my usersforeach ($users as $user){    // on-the-fly adjustments; I could do this inline, but I like this method as it makes the vars look cleaner in the HTML.    $name = ucwords( $user['name'] );    $birthday = date('Y-m-d', $user['birthTimestamp']);    $active = ($user['active'] ? $user['name'] : $active );    ?>        <tr><td><?php echo $name; ?></td><td><?php echo $birthday; ?></td></tr>    <?php}?></table><p>Active User: <?php echo $active; ?></p>?>

Compared to smarty:

php:

<?
<table id="myUsers">{* Track active user *}{assign var='active' value=''}{* List my users *}{foreach from=$users item=user}    <tr><td>{$user.name|ucwords}</td><td>{$user.birthTimestamp|date_format:'%Y-%m-%d'}</td></tr>    {if $user.active}        {assign var='active' value=$user.name}    {/if}{/foreach}</table><p>Active User: {$active|ucwords}</p>?>

We've made multiple systems using Smarty and PHP templates, and I can tell you from experience I'd much rather work with a PHP-based "template" than Smarty any day of the week. I can see your reasons, but I think it's just going to kick your rear end at a later date.

That said, i'm not saying to set a bunch of variables and then include() your template PHP file; I'm still advocating the use of a view layer with segregated variables and the separation of business and view logic, all I'm saying is; don't try to prevent logic in your View and make it impossible to use any kind of PHP, because one day you'll really need it.

Golbez posted:

Memcache vs memcached. From what I read, memcached is the better PHP extension. Unfortunately, it is not supported in Windows, which is what our development machines are. (The servers are Linux).

Should we build a wrapper around it to only use memcached if it's detected, use memcache instead, or just buck up and switch our dev environments to Linux?

I guess the main question here is, does the wrapper idea make sense? It does in my head, simply don't assume memcached is enabled. Note that this is in house and not for redistribution, so we don't need to care about third party stops setups.

Golbez posted:

Hm, thanks. So if we didn't go with a wrapper, what suggestion do you have for our predicament?

Golbez posted:

Hm, thanks. So if we didn't go with a wrapper, what suggestion do you have for our predicament?

Jabor posted:

Wait, are you saying that you make all your class members public if you're the only one who's going to be working on a project?

Good Will Hrunting posted:

I'm working on a project for school where I'm querying a Mongo collection with PHP and getting a result set. I want to create XML to send back to the JS for processing, and I know I can do it with a large chunk of gross repeated code, but I'm wondering how to optimize it. I was thinking something along the lines of:

php:

<?
foreach ($result as $doc) {
    $record = $dom->createElement("Record");

        foreach(key/value pair in $doc){
        // create the key element and text node, append it
        }
        //append record to the XML document
?>

I'm not sure if there's a way to access each [key] => [value] pair within each document. Can I do foreach($doc as $pair) or is that not legal? From my understanding the result pairs are just arrays inside an array so I feel like that should be legal even if I'm not doing it properly.

duck monster posted:

Chances are if I'm the only one working on it, my language choice wont even support private variables, because there isn't a reason ever not to use python
in a situation where you have a choice 99.99% of the time. And with due respsect to where I am, given a choice on a project language , in 2013 it sure as hell it won't by PHP. Time, and sanity, is money.

edit: Oh god, magic_variables_gpc breaks mysql_escape_string and creates *double slashes* thus rending things MORE insecure.

Burn the fields and salt the earths, I need to move this shop to either a good framework, or something not php loving pronto. The "long drop"(poo poo starts at the top and executes through the code to the bottom, then the programmer hangs himself with it in despair) method of web coding needs to die.

edit2: Oh god, I just discovered the boss who's that untrained he doesn't know how functions work codes *on the live server* using an ftp client. I was loving wondering where his copy of the code was. I have so much work to do.

duck monster posted:

magic_variables_gpc

duck monster posted:

There is THIS clanger however

PHP code:

		$result = exec("/usr/bin/nslookup ".substr($email, strpos($email, "@")+1), $output); //I dont trust this at all.
		if (!substr_count(implode(",", $output), "NXDOMAIN")) { 
			create_user($email);

...

This is borked. But I need to prove it. I had him leaning over with me fuming about this insane code as I tried to exploit it using stuff like

duckmonster@magicalwebsite.com ; cat /etc/passwd > /var/www/passwds.txt

But nothing I could do could exploit this. Anyone know a good way to DEMONSTRATE that this code is insane and broken to my boss?

Zamujasa posted:

Why are you using magic_variables_gpc? Jesus Christ write a drop-in replacement using mysqli and even the most basic of prepared queries or something as soon as you can.

v1nce posted:

v1nce posted:

Most people if they have one rule, write it as:

code:

# if it's not a file, and not a directory, send the URL to the dispatcher
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) dispatcher.php?url=$1 [L,QSA]

This setup would let you have routes to /css or /images etc rather than blocking that entire section off from your script, so you could process images for resizing, minify or lessCss if you so desire.

This is fine, but if you have more than one RewriteRule then you may end up writing those conditions over and over for each rule. To get around that, if you know you always want files that exist to be used, you can try out the following:

code:

# If a file or a directory, do nothing (-) and stop processing (L).
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule (.*) - [L]

# Everything else goes to the dispatcher
RewriteRule (.*) dispatcher.php?url=$1 [L,QSA]

quote:

The problem I have is that methods in the pageview class need to access properties in both the dispatcher and controller classes.

McGlockenshire posted:

You're falling into a bunch of beginner traps here.

quote:

Use consistent capitalization and naming. Most in PHP have settled on UpperCamelCase for class names, lowerCamelCase for method names and lower_underscores for properties and variables. You have no consistency here. Just because PHP doesn't care about capitalization here doesn't mean you shouldn't care.

Methods should either be verbs or verbish. You are asking an object (a noun) to do a thing (verb it). Go might be a verb, but it doesn't describe what the method does. Beans isn't a freaking verb.

quote:

If your constructor does nothing except for call parent::__construct(), you don't need a constructor in that class. The one provided by the parent will work.

quote:

Never ever give methods the same name as their class. Ever. PHP4 considers these consturctors, and PHP5 will fall back to using them if it sees no constructor. Is this the reason for your empty constructor?

quote:

Your classes depend on external data in the form of $_REQUEST (in Dispatcher::Go() and beans::run()). This is probably bad, especially when you begin automated testing. Instead of relying on $_REQUEST, pass either it or the specific values into the object at construct time or the method at call time.

quote:

Dispatcher:ispatch() by way of Dispatcher::Go() blindly trusts user input to perform a require. This is a security hole wide enough to drive a train through. You must filter and validate user input.

quote:

In pageView (argh fix your naming), your constructor calls is_smarty_instantiated and then discards the output. What's the purpose of the method? All of the functionality can be stashed in the init_smarty method.

quote:

Now that we have the simple stuff out of the way,

Your conceptual model is broken.

The controller that gets instantiated by the dispatcher shouldn't give a drat that a dispatcher existed. All it should know is that it exists, and that all of the data it needs has been made available to it.

That controller then should gather all of the data it needs to perform whatever operation it needs to do, perform that operation, and then gather all of the information it needs to provide the user with output.

All of that output should then be sent back to the user somehow. You're choosing to use Smarty. Bad choice, but whatevs. You can do this either directly from within the controller, or by having the controller return the data to the thing that called it (dispatcher), and let it take care of things.

Outside of being passed all of the data it needs in order to do its job, the output rendering bits shouldn't care what instantiated them.

McGlockenshire posted:

Oh, crap.

Sorry, somehow I misinterpreted "new to OOP" as "new to MVC" and... yeah.

I'll come back tomorrow afternoon with some more concrete recommendations.

Personally, I advise avoiding most frameworks until you're more comfortable with OOP and MVC. One of the best way to grow to appreciate a framework is to do all the hard work yourself first and discover how much of a royal pain in the rear end the standard request lifecycle can be.

Also, do keep in mind that OOP isn't the be-all and end-all of development. Some of the best code I've ever worked with has been an OOP backend glued together using good old procedural bits.

v1nce posted:

These guys have pretty good points. My code example was more geared towards your exact problem at the time; I'm not sure I'd recommend it as a starting point for a new framework.
The irony always is, by the time you've rolled your own and figured out the problems you've made for yourself, you could have learned to use an existing framework (CakePHP, Laravel, CodeIgnighter, Zend, etc). If you're going to deploy something that's not just a personal piece, always go with a framework.

That's not to say rolling your own isn't a great learning exercise; If you're still getting a feel for PHP and OOP (or code in general) then it's almost a rite of passage. It's also a lot more interesting when you want to know how things work from front to back, rather than just tacking things onto the black box that are other frameworks.

Apologies for my naming conventions in the sample code, I could have been a lot more helpful with that but it was just a quick half hour job, McGlockenshire makes a lot of good points.

You'll want to watch out for Beans::Run as this is basically just a sub-dispatcher which then calls your desired action. I'd recommend modifying the Dispatcher itself to call the function directly after checking if it exists (see method_exists), which would add another layer of safety to the dispatcher; if it's not a file, with the class, with the action, bail out with a 404. Again, still a big security hole there, but it depends on the structure of your framework.

You also don't need to have Beans be an extension of Dispatcher. If you're after the variables from Dispatcher, find a different way to do it. Passing all the functionality from Dispatcher onto Beans is a bit crazy just for one variable. Dispatcher shouldn't be a place for initialising config variables either; it's a tool the system uses and nothing more.

Most frameworks would solve this problem by having a Configure/Registry class which contains a whole ton of variables you'll want to get at in a variety of places. This class would be static and you'd call variables by doing poo poo like Configure::get('smarty_template_path');. Some of the more recent frameworks don't use statics and instead pass the config around as something which is available inside the view/controller ($this->configure->get('smarty_blah'), but that's a lot more complicated if you're just learning, and it's better to stick with the static class.

Finally, having a pageView class is a nice move; if you scrap smarty it'll be easier to replace if you've got it segregated like this. Don't call the Dispatcher at the end of this classes code though, my example had it in the index.php only for my own convenience. Instead consider restructuring your code something like the following:

code:

/index.php
/libs/disaptcher.php
/libs/pageview.php
/controllers/beans.php

where index.php contains:

php:

<?php
// index.php - Bootstrap file

// Load libraries
require_once('libs/dispatcher.php');
require_once('libs/pageview.php');

// Run dispatcher
$dispatcher = new Dispatcher();
$dispatcher->go();

Having controllers inside a controllers directory will help mitigate the security hole too, as you'll modify your code to only load files that are in the controllers directory. You'll still need more sanity checks, but it's a good start.

Winter is Coming might be right though; a few books won't hurt.

duck monster posted:

So Cake. Seems good, but uh, its kinda bulky and crufty looking.
Code igniter looks neat, but I sure do see a lot of people claiming its redundant on the net.
Laraval... Looks neat, but its also a bit huge looking and I dont know how well supported it is.

What else is there. Learning curve is important! If I had my way I'd do it in Django, but I'm not sure the boss (who insists on hacking this himself too) wants to learn a new language, even though python is actually amazingly easy.

mooky posted:

I have no idea what Doctrine is, and I don't like the example they used in the beginning of the book with the blog posts, this doesn't make sense to me:

quote:

I understand it's making a database call using doctrine, I'm not sure what getManager() is and it isn't clear to me based on the example if in the query, "SELECT p FROM AcmeBlogBundle:Post p" where 'p' comes from and what is AcmeBlogBundle:Post?

Calyn posted:

First off, there is another decent tutorial for Symfony2 here that goes through the basic things in a more step-by-step basis: http://www.ens.ro/2012/03/21/jobeet-tutorial-with-symfony2/
Maybe that helps.

musclecoder posted:

Quick Overview: Doctrine is an ORM - Object Relational Manager. [...]

Doctrine is big and complex and sometimes slow. I would not recommend it for beginners. The only issue is that it and Symfony2 are kind of in bed together to begin with.

Calyn posted:

Doctrine is very powerful once you get used to it, but you CAN choose to ignore it. (please don't)