Symfony YAML – A PHP library that speaks YAML

via components.symfony-project.org

Fabian presenting the freshly hatched stand alone components for PHP (I’m still wondering what he’s hiding behind his back )

Posted via web from Dasher’s Dev Den

Symfony: Overloading and Overriding Plugins & Base classes

There’s a couple of places that tend to cause confusion when people try to override Symfony & plugin functionality and the autoloader doesn’t help when you’re trying to test things out.

You can generally create your own version of any class – if you put the new version in the right place and if the file and class are named properly.
The location you put the file depends on a number of factors (is it a core module or a plugin) and the scope you want to affect.

With plugins generally the best approach to start is to be as local to your Symfony app as possible.

1. Clear your cache – it doesn’t hurt to do this before and after you start making changes and it’s a good habit to do this often
2. Start by making a folder for the in apps\<applicationName>\modules\<pluginName> (often you just make the folder rather than using the generator)
   • Depending on what you’re overloading you create the sub folder here for it – so if you’re modifying a template then create a templates folder under the plugin folder you just created
3. Now copy the existing file from the plugin to the folder you just created- it’ll be a good starting place to making any changes.  When copying a file it’s the file that will be used initially by the autoloader  rather than a file named Base….
   • So if you’re looking to override the actions for sfGuard, it’s going to be under the sfGuard\modules\sfGuardUser\actions\actions.class.php
   • Well written plugins will use a base file – for sfGuard this is BasesfGuardUserActions.class.php – which allows easy overriding of your own functionality – you’ll see a reference to this in the top of the actions file
   • You’ll need to change the require/require_once statement in the top of the file you just copied – to point to the correct place as when you override the autoloader won’t be able to find the class you’re trying to include.
   • This file will generally just be a placeholder – with all the work being done in the parent class.  You’ll need to refer to the base class or have a decent IDE that gives you code assist or exploring of the methods in the parent to determine what method signatures are available for you
4. Now you can implement your own functionality in the file – for an action start with something simple like overriding a method and putting die(“hey – it worked! – Who’s da man?!?!”).  You can even put this just under the require statement to test – so you’ll know that it was your customised file that was included rather than the specific one within the plugin itself.
5. Clear your cache again and fire up your browser to load a page under the application you used above
6. Now you see your die statement is being hit – you can implement the actual code you want to happen

The locations available for you to put custom classes are:

• project\apps\thisApp\modules\moduleName\folderType\fileName
• project\apps\thisApp\lib\folderType\fileName
• project\apps\thisApp\lib\fileName
• project\lib\folderType\fileName
• project\lib\fileName

Where:

thisApp is your application name
moduleName is the name of your module or the plugin name
folderType is the type of folder – i.e. actions, templates, model, etc
fileName is the name of the file in the expected format (so actions.class.php for the actions class)

Posted via web from Dasher’s Dev Den

Spidermonkey in PECL « BombStrike’s blog

bombstrike has a new post about Spidermonkey interface for PHP, now available in PECL, here’s the post on his site

The PHP JS lib has been put into PECL which, with the coming release of PHP 5.3 will finally allow some interesting scenarios – especially when it comes to testing. It should be possible to extend the Symfony Web tester to include the JS behaviours, Ajax in test cases and a whole lot more!
tag: synfony, Server side JS

Posted via web from Dasher’s Dev Den

Symfony Debugging: Browser tips

Often people have issues with how best to debug their application from the browser when developing with Symfony.

There’s a couple of tools available that make the dev’s life easier:

• Firefox + Firebug
• Desktop Proxy (Fiddler)

The winning combo of Firefox + Firebug allow you to see what’s on the page, inspect your form + input tags and work out if there are problems locating page assets (like css, images and JS).  Just right click on any of the page elements and select “Inspect Element” and you can navigate the HTML in a quick and intuitive way.  Enable the Script, Net & Console for the site by clicking on the headings from within Firebug and you’ll be given access to those features and you can examine which assets are missing, load times, set breakpoints on your script – all in realtime and on the fly.

Watching the Firebug net panel – you’ll see details of HTTP GET’s, POST’s and AJAX requests but sometimes it misses a few things – especially when you’re using Flash or Flex on the page – which uses connections outside of the browser and therefore not tracked by Firebug.

firebug net panel

In this case you’ll need to use a desktop proxy to monitor the connection which can proxy all connections and will allow you to inspect & decode the traffic.  Fiddler is a lightweight desktop proxy for the Windows Platform that does just this and more.  You can capture, review, decode, replay and construct all connections – drilling into and examining what’s happening and thereby giving you a much clearer picture about what’s happening between the browser and the server.

Posted via web from Dasher’s Dev Den

SourceForge.net: Community Awards: Support Symfony

Support Symfony in the SourceForge.net Community Choice Awards!

Posted via web from Dasher’s Dev Den