Category: PHP

GIT Ignores and Symfony

By Matt Daum | 2 Comments on GIT Ignores and Symfony

We use GIT for version control at Setfive.  However often with our Symfony projects creating all the ignore files in all the plugins model/base’s and other locations throughout the project get very tiresome.  Since on some larger projects you can end up with 10-20 plugins, having to create an ignore for the autogenerated model, forms, and filters takes a long time.  Today we really quickly just wrote a plugin that allows you to quickly just run symfony util:generate-ignores git --add-ignores and it will automatically place the .gitignore file throughout your project in the correct locations and add them into your next commit.  You can also just have it place them throughout the project, but not add them to the next commit if you drop the --add-ignores option.  The plugin also accepts “cvs” instead of git for cvs based projects.

The reason you do not want the base, om, etc. directories in your repository is because every time a person rebuilds the model they will be updating those files(many times just changing the timestamp at the top of the autogenerated files), which causes uncessarily large commits.

You can get the plugin via http://www.symfony-project.org/plugins/sfSCMIgnoresTaskPlugin or install it via symfony plugin:install sfSCMIgnoresTaskPlugin.

If you have any questions/requests shoot us an email.

sfPropelPager and GROUP BY criteria

By Ashish Datta | 2 Comments on sfPropelPager and GROUP BY criteria

So for one reason or another (actually a few bad ones) I ended up having to use a Criteria object looking like this:

It makes SQL that looks something like this: 

“SELECT tag_id, tag_model, id, COUNT(*) AS the_count FROM sf_tagging WHERE tag_id IN (1,2,3) GROUP BY taggable_model, taggable_id HAVING the_count > int”

The query sucks but whatever it works.

My issue came when I tried to use it with a sfPropelPager. I set up the pager per usual but for some reason the results that were coming back weren’t correct. For some reason, the COUNT being returned by the sfPropelPager was completely wrong. It turns out the offending lines are here in sfPropelPager.class.php :

For whatever reason, sfPropelPager clears the GROUP BY clauses before it calculates the COUNT for a criteria object. I’m not sure why it does this – but it certainly is unexpected and breaks my query in particular.

There are a handful of posts about this on the Symfony forums and it looks like the Propel people know about the issue to.

The solution to this is to use the setPeerCountMethod() from sfPropelPager. The setPeerCountMethod() function allows you to specify a custom COUNT() method inside the peer for your Criteria. I went ahead and added a new function to put the GROUP BY columns back in:

This solution works but it is extremely rigid. Since the custom count function has to be static you’d really be out of luck if you had variable columns or other dynamic requirements.

I’d love to know if someone has a cleaner/better/more elegant solution for this.

Client-side validation for the new Symfony forms with jQuery

By Hamid Palo | 3 Comments on Client-side validation for the new Symfony forms with jQuery

The new Symfony forms are great improvement over the old forms and once you get over the learning curve you can’t imagine life without them. The only problem with them is that they don’t really offer client-side validation (yes, being agnostic when it comes to Javascript libraries is maybe good but come on). There is fortunately a plugin that does client-side validation but it is Prototype-based, and looks a bit clunky.

For those of us using jQuery there was nothing, so we decided to write our own small helper that integrates this jQuery validator with the new forms. It’s nothing fancy, but it does the trick for now, and we may expand it into a full-fledged plugin that does all sorts of crazy things.

Using the helper:

  1. Download and install the jQuery validation plugin.
  2. Download the helper and put it in lib/helper/jQueryValHelper.php
  3. Include the jQueryVal helper.
  4. To enable the helper for a specific form:
    <?php echo jquery_val_form_tag($form, array(‘action’ => url_for(“@register“) ))?>

That’s it.

The validator currently supports email, min and max length validation. The only required option is action, the other options you can pass it are:

  1. error_placement: Change where the errors are rendered, for example:
    'error_placement' => 'error.prependTo(element.parent().next())'
  2. error_element: Change the element used to render the errors, default is label.

All other options you pass are added to the form as attributes.

More BOSS!

By Ashish Datta | 2 Comments on More BOSS!

So I had some time (not really Daum just couldn’t get me to do any real work) so I wrote up a thin wrapper around Yahoo BOSS.

The code is available here

I mashed it into the where/what/when thing and made a swag front end ;)

The only search class implimented is the web one. I’ll probably try and do news/image later this weekend. I also haven’t tested ANY of the features so it’s very possible nothing works.