You must first sign up to be able to contribute.

sfDojo Plugin

sfDojo is a plugin that targets the dojo toolkit integration on Symfony. This integration must be in a way that refactoring an existing project will be a low cost operation. The benefits of dojo are pretty obvious concerning the UI and interaction. Since Symfony lacks on strong Widgets, this plugin can be the way to achieve fast development of nice and professional UI.

NEW Sourceforge project at with SVN repository.

You might also want to have a look at the sfJSONRPCPlugin plugin for a way to implement JSON-RPC services in symfony that can be used with dojo.rpc.JsonService?.

First release (0.0.1)

This release only includes a helper for the dojo Tooltip component. I'll add more widgets gradually, or feel free to ask on the mailing list if there's a specific one you need.


Added helper for the Tree widget (and related, such as TreeNode?). Some internal changes.

Planned Features:

  • Dojo implementation of current ajax, visuals effects, drag and drop, and server side validation helpers
    • Integrate dojo event system for correct timing/ordering of events
  • Add ajax navigation support: forward button, back button, and bookmark support for single page interactions
  • Add layout controls for: containers, windows, tabs, dialogs, modals, buttons
  • Add navigation controls for: menus, tree menus, wizards
  • Add form controls for: date/time/color picker, inline editing
    • Integrate dojo client side validation using current validate.yml settings
  • Add misc widgets
    • google/yahoo maps
    • sortable tables
    • svg chart generation

Feel Free to Add Suggestions Here:

  • Easy Installation via PEAR
  • Automatic javascript code generation
    • autoloading of only needed modules
  • Automatic overriding of css rules
    • like appTabPane or moduleTabPane
  • Fix package.xml so that dependencies is symfony < 0.9.9999 instead of 0.9.999.


  • Should this plugin provide output helpers or integrate into symfony specific functionalities, like transparent RPC support, since dojo is an active and evolving project?
  • RPC should be treated as a simple module/action -> template or a more complex solution?
  • What about extending sfActions to sfDojoRemoteActions to handle automatic decoding and decoding of JSON requests and responses?
    • roel -> I like the idea, but we'd have to settle on a php JSON implementation; JSON-PHP can be run anywhere where php scripts can be installed, but php-json is very fast - or we'd have to add another abstraction layer between the sfDojo code and the actual parsing library.
      • promag -> well yeah JSON without extending dojo rpc.
      • promag -> should the remote object be the module? and remote procedures the actions of that module?
      • promag -> and how should the serialization be done? for instance, propel objects can't be serialized because there will be undesirable output.
  • Should remote objects implement a specific interface like sfDojoRemoteObject? This could be used to generate SMD for dojo.
  • It would be nice to have some routing rules to beautify the RPC process like:
    • GET = /smd/shoping/cart
    • GET = /rpc/shoping/cart POST = {"params":[],"method":"getItems","id":1}
  • Extend dojo with cached json-rpc support. (DONE!! and improves performance)
    • one can specify which procedures should invalidate the cache


  • joão 'promag' barbosa (