Yii Playground: collaborative demo app.


I’ve moved the ui examples under the UiModule and commited changes on svn; let me know if you have a look at it ;) Also please let me know what you think about my last post, thanks.



Directory structure looks good for me. Menu Hierarchy too. I like #3 where extensions have a separate area.

About dividing examples into modules / controllers. I think if examples are from the same topic and are really close, they should be done in one module. For example, different form validators could be shown in a single controller. Same for CHtml helpers.

If they are from the same topic but not really connected — different controller from the same module. For example, totally different ajax widgets such as captcha and gridview.

"See also" looks like a good idea.

New renderSourceBox looks good.

Hi samdark,

thanks for your reply.

In the meantime I’ve implemented a first version of the “see also” box, let me know what you think.

I’ve also moved the SrcCollect class to a component as suggested to me by mindplay and added a couple of examples (tabs and autocomplete).

For menu I was undecided between #2 and #3, but I think we should move to #3 ;)



Here’s the demo:


I’m trying to decide what the best way for you to be able to update it is. Have you used SSH? I could just give you SSH access, that would be simplest

The best thing is to use post-commit hooks to deploy changes on SVN commit.

Often (for all of my cases anyways) you don’t want to update a live site on every svn commit.

@jonah: did you updated something? I just want to enter your site


and the attached error appears.

This morning (I’m from Argentina) the site works perfectly!!

Works fine now.

Yeah, may be was something temporal…

Keep the good work!!

Sometimes I think DreamHost acts funny :/. One time I released a site on dreamhost and we got all sorts of reports like this from users… Then we switched to jaguarpc and no more weird reports. Dreamhost is awesome in many other ways though that other hosts lack


I were thinking of adding a right menu (optional) like the one in the jQuery UI docs (http://jqueryui.com/demos/button/ - "radios, checkboxes, icons, …") to avoid having the main menu with too many items.

For example today PoL added a demo about advanced ajax request that was on the same topic of the ajax request one… and I’d also like to add more examples for CGridView that could take too much space if everything is put on one single page.

So imho, it would be nice to have a widget that allow you to pass a list of links and creates for you a menu with links to other examples of the same topic. Other examples could be a link that point to another page/url or to the same page using an anchor.

What do you think? With this one the UI should be complete.

I’m also going to store in session the value of the show/hide source toggle so that if you change page it keeps the behavior you choose.




there is another “important” update regarding database (as it will be more “definitive” I’ll write a few lines about it in the wiki too)

We’ve now setup the playground so that we have two database files:

  • factory.db

  • user.db

the second one won’t be committed on svn, and it is automatically generated (where possible) copying it from the factory.db one.

The factory.db file is the file that you want to edit when you want to make available a new table for an example that uses database data or when you edit an existing table. You change this file and then you commit it.

When you first run your demo app, the factory.db file will be copied to user.db and you’ll be going using this one, so if you input some test data the original/clean database won’t be touched and you won’t end up committing all your tests on svn ;D

You can also reset the user.db database whenever you want clicking the reset database link that it is also useful if your user.db gets out of date. (at this time you’ll have to guess it or compare by hand the two files)

…so… hopefully you are going to see some examples that involves db data input soon B)



Maybe it’s better to use SQL instead of solid SQLite DB? SQL is easier to merge and can be reviewed without a special tool.


you mean to have factory.sql with the schema and then use that file to create the user.db one? and then just keep the factory.sql on svn?

This could be a better alternative, but if you want to keep some demo data on your factory.sql database you’ll have to remember to reset your user.db database before altering it / adding a new table to it to then export it to factory.sql (for example in case you need to change it for a new demo). also it was more easy for me to do in that way (just copy the file) that is easy to implement also on the live website and can be set as a cron…

But your I agree with your points too so maybe we could change this as you suggested… but for me isn’t a priority right now as I’d like to try to write some demos about other topics and I have few free time available. Of course if some one is willing to improve this, is more than welcome ;)

But as I said there are things I like in the current solution and some other I like on the one suggested by samdark… ::) …what do you guys think?




I’ve completed the advanced date and time user input / output example… please see:



As you can see it relies on a custom component, but I wanted to do it in this way cause I were not able to find an equivalent built on Yii…

Please also consider that I’ll have to do some small updates in the example, like a switch to show input from formatted to raw and vice-versa and this is also why, for the example, I don’t convert data types in the model… mh… actually I could maybe use a scenario but there is room for improvements.

Anyway… I don’t know if I’ve done it in the best way, so we can discuss it in this topic. Also the LocaleManager component gives an example on how to use the Yii’s built in functions to manage the date in your locale. And btw… this example is also probably missing a thing: timezone and dst :(

Also please notice that I’m “extending” the Yii built-in locales with files in protected/i18n/data/ that are merging custom data with yii’s defaults, using the same technique used for the config files.

Let me know what you think; imho at this time the yii’s built-in functions for date formatting are nice for date output but they are not flexible for date input.




we now have the RightMenu widget ;)

Have a look at:



…enjoy B) ;D

imho, this makes the user interface "feature complete"… so now we can focus on contents. This "sub-menu" will allow better content organization, using the main menu mainly for each single topic, and then providing N "sub-examples".

As you can see you can also hide the menu, that can be useful for smaller monitors… and… it looks better if your browser has some css3 support ;) (!=IE)




big thanks

Virtual DarKness

RightMenu is a bit funny. Try moving mouse around it and it will keep sliding right and left for some time.

I’m not seeing this behavior in chrome 5.0.375…maybe a “standards” issue?

Maybe. I’ve tested in latest Opera.