Entries tagged “php”

In symfony, versioning a model was not terribly difficult. I had my own specialized brute-force way of doing this.

I always like to think of what different interpreted programming languages bring to the table.

I decided to play version control private-eye today when my coworker mentioned that we make a system call to check the time several times per request on a few specific pages.

I’ve been porting some PHP to python during SuperHappyDevHouse and was amazed at how little code I needed to write since python makes list manipulation a breeze.

I get Smarty thanks to django… yeah, it’s weird.

Back to my original comment about templating, smarty really is trying to limit the scope of PHP in a good way. Too often I see a lot of heavy-lifting in the templates. It’s so bad it makes my MVC’d brain explode.

Django templates are very limited, based on a philosophy of keeping view logic and only view logic in the templates.

This is what smart tries to do and it’s a reasonable solution to the fact that PHP is a templating language with a kitchen sink. It’s saying, okay… well let’s treat PHP as a programming language, and keep Smarty as the template.

symfony of course says (well not really, or in any official capacity, but would you believe… frameworks talk to me), some PHP is view and some is model/controller. We’ll suggest which ones are which, but really we’re not getting in the way of making your life a living hell by sticking complicated business logic inline.

[tags]smarty, symfony, php, python, django[/tags]

So I started yesterday with Django, and I decided I didn’t want to futz with creating another mysql database that I’d need to manage, etc. Instead I’ll just use sqlite.

I wanted to keep my sqlite database within my project regardless of where I might move my project later. So I did this:

I confused a lot of people on IRC, but it’s really quite easy:

• __file__ is the filename of the current script, very similar to PHP’s __FILE__
• os.path.abspath calculates the absolute path, hence the absolute path of the current file
• os.path.join does all the nasty business of joining paths together and figuring out what type of slashes are needed, etc.
• ‘data/db.sqlite’ is a string

So really all we were doing is creating a relative path, but setting it absolutely.

[tags]php, python, symfony, frameworks, programming[/tags]

[tags]php, cgi, path_info, nginx, symfony[/tags]

symfony and other applications rely on the server’s PATH_INFO being set properly. According to NCSA:

The extra path information, as given by the client. In other words, scripts can be accessed by their virtual pathname, followed by extra information at the end of this path. The extra information is sent as `PATH_INFO`. This information *should be decoded by the server* if it comes from a URL before it is passed to the CGI script.

Unfortunately, I use a nonstandard server that doesn’t natively support CGI, so everything sent to the FastCGI server is done so via parameters that are usually obtained from the HTTP request, but I can’t figure out how to do a urldecode in my configuration.

So to workaround this I used the auto_prepend_file directive in php.ini. With OP code caching this shouldn’t hurt too much:

auto_prepend_file = /var/www/pathinfofix.php

I then added the following script:

<?php 
$_SERVER['PATH_INFO'] = urldecode($_SERVER['ORIG_PATH_INFO']);

Voila, the PATH_INFO is in a format that symfony (and any other PHP script that depends on PATH_INFO) needs.

[tags]doctrine, php, symfony, sfDoctrine, database,errors[/tags]

[tags]php, propel, doctrine, validators, symfony, optiopt, startup[/tags]

Lately I’ve been experimenting with Doctrine on a few projects. It does have some requirements, including the PDO layer of PHP 5.2. Things didn’t work right off the bat on Dreamhost (which I still use for non-critical things), so I opted to build my own php.

[tags]Zend, Zend Search Lucene, Search, Lucene, php, symfony, zsl[/tags]

[tags]Zend, Zend Search Lucene, Search, Lucene, php, symfony, zsl[/tags]

Previously we covered an all-at-once approach to indexing objects in your symfony app. But for some reason, people find the need to allow users to sign up, or change their email addresses and then all of a sudden our wonderful Lucene index is out of date.

Here lies the strength of using Zend Search Lucene in your app, you can now get the flexibility of interacting with a Lucene index, no matter how it was created and add, update and delete documents to it.

The last thing you want to do is have a cron job in charge of making sure your index is always up to date by reindexing regularly. This is an inelegant and inefficient process.

A smarter method would be to trigger an update of the index each time you update your database. Luckily the ORM layer allows us to do this using objects (in our case Propel objects).

If we look at our user example from before, we did set ourselves up to easily do this using our User::generateZSLDocument() function, which did most of the heavy lifting.

We can make a few small changes to the User class:

We have an attribute called $reindex. When it is false we don’t need to worry about the index. When something significant changes, like an update to your name or email address, then we set $reindex to true. Then when we save with an overridden save method:

Now we’ve got the exact same data that we created during our original indexing. This handled creating and updating object, but we miss updating the index when deleting objects.

Luckily we already made a function User::removeFromIndex() to remove any related documents from the index, so our delete function can be pretty simple:

[tags]Zend, Zend Search Lucene, Search, Lucene, php, symfony, zsl, index[/tags]

[tags]Minnebar, symfony, barcamp, frameworks, php, php5[/tags]

[tags]Zend, Zend Search Lucene, Search, Lucene, php, symfony, zsl, plugins[/tags]

[tags]geocoding, caching, REST, symfony, Cache_Lite, php, cache, sfFunctionCache[/tags]

For reviewsby.us we do a lot of geocoding. To facilitate we use Yahoo! Geocoding API. This helps us normalize data, obtain latitude and longitude, interpret location specific searches.

These REST queries happen a lot and will continue to happen, but this data that Yahoo! provides is fairly static. We’re basically querying a database of sorts. So it makes sense that we should cache this data.

We’ll demonstrate how to cache these queries using symfony’s sfFunctionCache class.

I wrote a wrapper (I’ll release it as a plugin if requested) for the Geocoding API, the bulk of the work (the REST call) occurs in a function called doQueryGIS:

The call to this function is always wrapped with queryGIS:

This wrapper creates a sfFunctionCache objet and calls the function and caches it for subsequent queries.

What this means is once Yahoo! teaches reviewsby.us that India is located at (25.42°, 77.830002°) and that the precision is ‘country’ we remember it in the future.

These features will be incorporated into future versions of reviewsby.us.

[tags]best practices, php[/tags]

[tags]best practices,php,openID[/tags] [PHP]: http://php.net/ [openID]: http://openid.net/ [reviewsby.us]: http://reviewsby.us/ [symfony]: http://www.symfony-project.com/

In August I took a break from reviewsby.us only to be plagued by spam. In September, I relinquished portions of the project planning to my wife. We haven’t released anything publicly, yet, but there’s a lot in development.

• I updated the development framework to symfony 1.0 alpha and took care of a whole slew of bugs.
• Katie and I came up with a wireframe that details some of the upcoming changes.
• I upgraded the user logic to take advantage of sfGuardUser, a user management plugin for symfony.

I’m in progress of writing location specific searches. I’m slow to implement. It seems that this month is far busier than I’d like, and I can rarely get in a block of enough time to just crank this out. The problem with geographic-specific searches is mySQL supports those types of queries, but it’s not as easy as I’d like. Zend Search Lucene with some support from PHP, however, may yield some promising results. As always, I’ll share my findings in a forthcoming tutorial.

Anyway, no visible updates on the actual site, since I didn’t want to put alpha software on the live site. I’m sure by next month symfony will be ready.

[tags]zend, search, lucene, zend search lucene, zsl, symfony,php[/tags]