BlueFire Data Solutions

So recently I posted about how symfony has made the move to officially support Doctrine as the default ORM in future releases of my favorite PHP framework.  A lot of questions were raised, mainly because even though Propel is still going to be supported by symfony, it looked like Propel was dead in the water with not much active development taking place.

Interestingly enough, when I happened to look on the Propel website, I noticed a Propel version 1.4 and that got me wondering.  After some hunting, it turns out a blast from symfony’s past is now heading the development of the project.  That’s right folks, Francois Zaninotto is now working on revamping Propel (see here (groups.google.com) for more details).

I’m glad to see that a good ORM is getting someone with a lot of good ideas leading the forefront.  I’m very interested in seeing what will be coming out of the gate with the revamped version 2.0.

Tags: propel, Symfony

Well, as posted yesterday on the symfony blog Doctrine will now be the defacto standard for symfony’s ORM. To be honest, I’m not surprised at all with this move – it makes sense seeing that the Doctrine team are on board at Sensio. Sensio Labs was looking for something that fit with their overall strategy from what I’ve read on the forums and on the blog, so by hiring the Doctrine team they can now help shape the ORM to work well with the rest of the framework.

Not to worry Propel fans – Propel is still able to be used, it’ll just take a bit more configuring on the developer’s part. The thing I’m concerned about is what’s going to happen with all those plugins that are Propel only? I have a feeling that Propel will eventually be phased out a little at a time as Doctrine begins to overtake it’s capabilities.

Looks like I’ll be hitting the books again….

Sensio Labs has also gone in the book publishing business by the way, with the standard books that were already available from Lulu.com now for sale at other book sites (Amazon.com) and the new Doctrine documentation both on the doctrine site and available in dead tree format.

Tags: doctrine, propel, Symfony

Just wanted to make a quick post about some recent work I’ve been doing with the end goal being my first plugin for symfony.  A customer recently requested an event calendar for their site, so I figured what better way to build one that with symfony?  Currently, the calendar has a month view.  I’m working now on integrating the events into the calendar.  Once that has been accomplished, I’ll release the first beta.

My ultimate goal for the plugin is to have a daily, weekly, monthly, and yearly views with events viewed based off of user security level (which I am using the sfGuardPlugin for user security).  I have been working off and on for the last week or so to get the calendar into shape.

Once I get the event system integrated, I’ll post some pics.

In other news, I’ve been working on various tutorials that I really need to finish up.  I’ll try to have one out on symfony AJAX integrations soon.

Tags: sfAgendaCalPlugin, Symfony

Had the roughest time getting this one going – so therefore I’m posting just in case anyone else gets stuck.

Today, I started adding user security to the training database I’ve been developing in Symfony 1.1.  One of the great things about a strong framework like Symfony is the ability to create/distribute plugins to increase the core framework’s functionality.  A very popular plugin, that I decided to use for my project, is sfGuardPlugin.  This plugin handles security with groups and a bunch of other features that I haven’t played with yet.

There’s a real good instruction set for installation/configuration with the plugin.  However, one thing not mentioned in the instructions is the fact that you have to update your schema.xml file.  Otherwise, propel will throw this nice error:

No package found for database “propel” in schema.xml.  The propel.packageObjectModel property requires the package attribute to be set for each database.

So you’ll need to update your schema file from this:

<?xml version=”1.0″ encoding=”utf-8″?>
<database name=”propel” defaultIdMethod=”native” noxsd=”true”>

to this:

<?xml version=”1.0″ encoding=”utf-8″?>
<database name=”propel” defaultIdMethod=”native” noxsd=”true” package=”lib.model”>

The reason why is due to when a plugin has a schema of it’s own.  Symfony/Propel will attempt to merge the plugin schema with your application schema.  Your application schema though is not initially setup to handle this kind of merger.  Adding that one variable should take care of that!

Edit:  I originally had the change to be:

package=”model”

This was incorrect and will result in your forms and models being stored in the primay folder for your symfony project – which will result in you wondering what the hell happened (as has been my problem for the last two days =S).

Update

So, have you been having the interesting problem of your schema not updating your schema.sql file, like I have?  Well, I found out why just now.  Due to the added line in your schema.xml file, a lib.model.schema.sql file is created.  When I deleted the schema.sql file and renamed the lib.model.schema.sql to schema.sql, the database updated properly.

Tags: Plugins, sfGuardPlugin, Symfony

So at work I have been developing my symfony skills by rebuilding some of the database systems I’ve worked on in the past (first up:  update the Training Database….).  I know that with symfony 1.2, javascript will be uncoupled from the framework to allow for each developer to work with their favorite javascript framework (jQuery here =p) instead of being forced into Prototype/script.aculo.us helpers.

I’m excited to see what javascript development this will bring in with seperate plugins for each of the major javascript frameworks – with this making the symfony project even stronger than before.

What does this all mean for BlueFire?  Well, for starters I’m changing direction with the example software for the site and working with symfony as the primary framework for my projects.  Look out for some samples up in the coming weeks =D

Tags: javascript, Symfony

So I’ve spent the better part of a week and a half/two weeks working on getting up to speed on Symfony, the PHP framework I finally settled down to using.  If you haven’t heard about it, I strongly suggest you check it out.  It’s a very user-friendly framework, with the ability to build on the base code and extremely easy to get into.

Symfony Project

There is some excellent documentation to read – including an open sourced copy of the printed manual, which is updated with the latest and greatest data about each version (currently running at 1.0, 1.1, and 1.2).

I decided to start running through the Askeet tutorial – which is currently just for version 1.0, but stubborn as I am, I’ve been working with the latest version of 1.1, with the intent of moving to 1.2 when it becomes fully stable.  If you are up to the challenge yourself, feel free to drop a line if you have any questions, or check out the community forums – you’ll see me up there, mainly in the Askeet forum atm (DBA_Alex, just fyi =p ).

I have gotten up to day 11, which is where I’ll be picking back up tomorrow.  I’m truly looking forward to when the project team finally updates the askeet tutorial for the other symfony versions.

Anywho, tonight I’m getting back to work on updating the blog’s design to match the rest of the site – something I hope to complete before the week is out.  Once I finish that, I’ll be pushing out a few tutorials that I’ve held onto which I’ve been polishing up – one on Pentaho report creation, and another on using the php sparkline program.

Tags: Symfony