Yii Playground: collaborative demo app.

Yii 1.1 Tips, Snippets and Tutorials
1

Yii Playground

Yii Playground is a demo application that uses the PHP Yii Framework to show some features of the framework starting from basic examples. It doesn’t do nothing useful but it is great to play with as you learn how things works downloading and editing the code.

–

[color="#FF0000"]read before post:[/color] this post is meant only for introduce the project and for discuss about it between the active contributors; if you have any request, question or suggestion please post them in this other thread. Thanks.

–

Features:

  • modular, with small examples for each topic

  • write the code once and then it will be showed, live from the source, on your demo page (so if you update the source you don’t have to update the documentation too / each time)

  • community oriented: just join, request write access, and commit your snippet

  • "wiki style" shared project using svn

Goals:

  • always compatible with the last stable Yii version: all examples will have to be current and working

  • easy to understand examples

  • examples should follow "best practices" and should show the best or one of the best ways of doing that particular thing; more experienced users can supervise on this

Concept / preview video:

Right now we are looking for people that can help by providing and commiting some code, so if you want to join, just read here! Thanks.

p.s.

to see how all this started, read here ;)

2

Currently working examples:

  • Ajax request using ajaxLink and ajaxButton

  • Zii Jui dialog

  • Zii Jui datepicker

  • Zii Jui autocomplete

  • Zii Jui progress bar

  • Zii Jui tabs

  • CGridView

  • CPagination

  • Breadcrumbs

  • i18n: date and time

3

This is really an amazing idea. Have you thought of having an online version that people can use without installing? If you don’t mind, I could host it for you and I’d even write a script to handle updating the demo to the latest version of the playground. What do you think?

4

Hi!

Yes… but was a bit unsure about this as I’d like to have also some examples regarding topics like security and file uploads… that one should test from localhost… and also cause the meaning of this project is not to see the documentation / the examples… but to play with them trying to change / improve them and then eventually contribute back by committing the changes…

but:

this would be great! in this way you could have your script replacing the views of the "dangerous" samples like file upload and so on with a view that states "to try this download the source from the project website" or something similar, what do you think?

Also, having an online version would be a nice way for people to "try before download"… that in the end will lead them to download the source and so on…

I’d like to see many people with write access to the svn repo as the approach should be wiki-style so that anyone who see a small bug or something to change in order to have the sample working with the new Yii release and so on, can just do it in a minute and commit it…

So… it shouldn’t be something that requires a long work for few people but a few minutes of many ;)

Also… when you usually read how to do something, you first test it with a dummy module and then you implement it in your real project… so the playground is a way to test what you’ve learned and share it with others… and this is why the point is to have people downloading it instead of just browsing it online… but as I said, having it online could be useful and lead more people to download it ;)

Of course, it will be nice to have you as a committer of the project so if you’d like to have write access please pm me!

bye,

Giovanni.

5

Just opened issue#1: Divide examples into modules.

I think it should be done to isolate examples and not to search in a big amount of controllers and views.

6

Hi samdark,

I agree with you… How do you suggest to organize them in relation with the menu hierarchy we’ve setup (that anyway is still a draf)?

thanks.

bye,

Giovanni.

7

Submodules will make things relatively complex so I suggest:


AjaxModule

  RequestController

InterfaceModule

  ZiiDialogController

  BreadcrumbsController

I18nModule

  BasicsController

AuthModule

  RBACController

  SRBACController

Also I don’t really like extra code in views:




$this->sc->setStart(__LINE__);

…

$source =$this->sc->getSourceToLine(__LINE__, __FILE__);

…

<div class="source_box">

<?php $this->sc->printOut('php', $source); ?>

</div><!-- source_box -->

…

<?php $this->widget('application.extensions.syntaxhighlighter.SyntaxHighlighter', array()); ?>

source_box surely can be moved to layout or decorator.

Syntax can be highlighted by http://www.yiiframework.com/doc/api/CTextHighlighter

8

Hi,

I think I get the idea; I could try to rearrange it in this way next week as I’ll be away from tomorrow to sunday.

Why not / what do you suggest? I thought it was useful to have it in that way cause you just set it up once and then don’t think about it anymore… and you get the “frame” of your code you want to be showed in the demo.

Consider also that a view and a controller won’t necessary correspond to just one example… for example in the dialog controller you can have the basic example and then, on the same page, some other examples that makes a more advanced use of the dialog box or in the ajax request demo you can have other examples on how to do it… ??? …at least this was my idea; do you think that it would be better to keep it “1:1” ? I feel that in that way there would be too much views / controllers around, but also having more examples for the same topic on the same view could lead it to be messy… :blink:

I remember that this was my first idea too but then for some reason I preferred to go with the syntaxhighlighter extension… don’t remeber actually why right now; a cool feature of that script is the buttons on the top right corner that appears when you hover the source code and let you copy / paste and view it in plain without line numbers so it is easy to copy and paste it… ::) But we can probably achieve the same result easily using CTextHighlighter so for me it doesn’t makes a big difference; what are your thoughts?

edit: forgot to say: I wouldn’t put that in the layout as it should be possible, from my original idea I wrote above, to have more than one “source_box” for each view (one for each example). Maybe decorators would be the best solution but honestly I never used them :P so… are they worth to be used in this situation / what are the pro? thanks.

bye,

Giovanni.

9

About extra code in views. Source code markers are probably OK but I’m still thinking at least text highlighting script can be moved to layout.

10

I’ll get the demo up after school ends - two weeks. Could you add me to the project? My gmail is poppitypop. looking forward to this

11

hey, guys,

I’ve added CJuiDatePicker, could you please take a look?

thanks

:)

regards!!

12

That’s nice!

But maybe you forgot to add the view file?

I get this error:




CException

Description


JuiController cannot find the requested view "zii_datepicker".

And in fact it seems that protected/views/jui/zii_datepicker.php doesn’t exist

13

hum, thanks for reporting…I’m wondering if there are files under css/zii_datepicker also…I’ll do a check

thanks again

regards…

14

well, it seems that now things are ok, please, try again guys

sorry for that inconvenience of missing files

regards!

:)

15

done it ;) thanks.

thanks scoob, I’ll have a look to it soon; just one thing I saw from the source: the folder yiiplayground/css/zii_datePicker/ maybe could be renamed in yiiplayground/css/jui/to host jQuery ui custom themes (that can be used not only from the datepicker), right?

I’m also thinking to set up a widget for “references” and “see also” links, what do you guys think?

bye,

Giovanni.

16

hey, Giovanni,

sure, I’ll create a new complete jui theme because I’ve selected only Datepicker and base css files in themeroller

in my opinion, widgets like “references” and “see also” would be very nice and help us to keep the code clean in the whole project, as in some cases it’s necessary to include too much text and links in order to explain a little piece of code in the sample

:)

regards!!

17

Hi!

@scoob: I changed a little bit the css you used for the input text field you used in the datepicker example ;) …also I noticed that you were using spaces to indent; I’d prefer to use tab in examples for more “uniform” results, as mentioned in the guidelines in my first post. If you are using netbeans, you can set this as a per-project setting.

@samdark: I tried to put the ajaxRequest demo inside a module called AjaxModule; is this how you meant it?

About decorator and the widget for ref. & see also links I didn’t had the time to look at them yet…

bye,

Giovanni.

18

no problem, I’ve created two new styles for datepicker and I’ll try to commit changes tonight

about spaces, I’m sorry, even though I’ve used tabs, Netbeans was converting them into spaces…I changed the global prefs and this should be fine in the next releases…

thanks for your advices

:)

ps. I add your e-mail address to my GTalk, did you receive my invitation? (tried using your login info from google code repository)

regards

— edit -----

I added two new jui themes, but I’m facing some problems when I try to remove the old css folder from the project (it’s not removed)…I’m using kdesvn if you guys have any suggestion, thanks in advance

19

Virtual DarKness

Yes. Something like that. I would suggest renaming AjaxController to RequestController so later you will be able to add, for example, FormValidationController.

20

@samdark: I’ve put online a couple of pages in the wiki, you should be able to edit them:

http://code.google.com/p/yiiplayground/wiki/MenuHierarchyDraft

http://code.google.com/p/yiiplayground/wiki/DirectoryAndFilesStructureDraft

I think that is very important to define the structure of the app without going on providing new samples, cause it is important to find a structure that will let us to manage things easily, without ending with a mess of files, folders and menu items…

I think the menu should be divided by area according to the question “what are you looking for / interested in” more than from a technical point of view… so for example I won’t put the FormValidationController under the AjaxModule but instead under the UiModule cause when you want to design your interface you learn how to build a form and then how to validate it… Also in my original idea I was planning to keep more code of examples of the same are under the same controller so that the AjaxController could be used for other stuff. ::) But I’m not sure what is the best solution… maybe, since we move to use modules, we can then divide examples to have a more 1:1 relation between controllers and views or to form smaller groups of views used by each controller.

The problem is that of course many examples could be used in many area and cover more topics, for this reason it is important to define a main area / topic for eache example and then eventually use the "see also" links to point to this example from somewhere else or from the example to another example.

Also… if you look at protected/modules/AjaxModule/views/ajax/index.php you see that each module / area have a main index view that should be an index / summary page with a more "flexible" list of examples so that on example could be, in theory, linked in more than one index page (of course it can also be put in more than one menu, but you must anyway define a main one to decide where to put your code).

So… what are your thoughts ?

You (all who joined this project) can use the wiki page to write down a couple of examples of how you would organize menu and file structure.

bye,

Giovanni.

p.s.

I’ve committed some changes to use decorator / layout as suggested by samdark; I think I’ve found a solution that requires less code and it is flexible at the same time; for more info look at the source (r21) and this page: http://code.google.com/p/yiiplayground/wiki/renderSourceBox