*Fixed table name bug
see r12
Thanks Jonah,
I have tried to use the latest version of your skeleton app. With one exception that I modified the entry script as below, everything including password recovery works fine 
- $yii = '../yiiRepo/framework/yii.php'; + $yii = '../../framework/yii.php';
@Jonah: Cool, will have a look at my (Linux) box now. For you it doesn't really hurt (mixing LC tablenames in MySQL and UCfirst in source on WAMP), but it will work on *nix too.
Defining tablenames in the model can be a bit confusing, especially when using AR and SQL in your source (or use Modelname::Model()->tableName to address a table in SQL).
So for me: Nice if you have to use legacy tables, but further it's not really workable. Unfortunately there is no other way to address tablenames as a variable as far as I know. There were some requests for it, especially if you want to prefix tablenames.
About the different branches: Well it looks like two different codebases in Googlecode, it feels like two different issuelists, it taste… so for me it's two different branches…
There is only one SVN now, the first one it being deleted. The main one is linked to on the topic post.
What I did is I simply extended CActiveRecord::tableName() to return the lowercase version of what it returned before. So now it expects tables to be lower-case. If you want a different table name, overwrite tableName() in your model and have it return what you want the table name to be.
So now all the SQLs generated in the skeleton app should have lowercase table names. This way there is no problem for anyone, correct? This seemed like the only solution so it would work on both linux and windoews and os x.
Big update: Added ParseCachebehavior
To get an understanding of how to use it look at the wiki page:
http://code.google.c…wiki/parsecache
And read the course comments in the behavior file
In the skeleton app it is used on the user 'about' column to cache the CMarkdown
Don't forget to install the table for it
NOTE: Requires the very latest svn build of yii (r707)!
I’m getting a CException: User does not have a method named “parseCacheRelation”.
Using Yii r712 (trunk) and (stock) skeleton r23. Any ideas?
edit: Using Yii r712 1.0 -> all works fine!
About the tables: encoding is set to latin1. Any specific reason not to use utf8?
No, that's just what phpmyadmin did for me… do you think it should be utf-8 instead?
if so, is it case sensitive (eg UTF8, utf-
Right now i'm adding a post feature to the skeleton app.
You should easily be able to extend it to work in anyway you want, as this is just the skeleton of it. For instance you could modify it to be:
*a news system (where only admins can post)
*a multi-user or single user blogging system
By default it will behave like a a multi-user blog system.
It will take use of the ParseCachebehavior to deal with the markdown (i was very happy on how easy it was to install and use)
I also set up bare-bones for extending yiic and having your own template files
&does anyone think I should remove Loggablebehavior from the skeleton? It's not used and i don't see many common uses for it
PHP Error
Description
Trying to get property of non-object
Source File
/var/www/html/yii/demos/skeleton-app/protected/views/post/list.php(17)
when I clicked the button of posts (http://localhost/demos/skeleton-app/post/list).
Please fix the following input errors:
* Username is incorrect.
when I tried to 'Login' (http://localhost/demos/skeleton-app/user/login) after I registerd my account using 'Register'.
I am using app-skeleton r29, on Yii r715.
Ah, my bad. The test data supplied had corrupted foreign keys. That was the first error… should be fixed now… the second error should also be fixed now.
Thanks,
Jonah
EDIT: BTW also the foreign key ON DELETE option for the post table was incorrect an should be changed to CASCADE
You can adjust the table encoding format easily with PHPMyAdmin, so your export dump will have the right encoding enclosed (utf8).
To actually be able to use the encoding, add: 'charset'=>'utf8', to the db array in the config file main.php
About LoggableBehaviour, didn't use it yet, but perhaps its nice to enable this for certain groups, like admin. For logging common users its a bit much perhaps.
When I go to PHPMyAdmin there are like 20 different versions of utf8 i can switch to, how do I know which one to use?
And actually using the log for admin is a good idea. Didn't think of that…
Ok true about the utf-8 in phpMyAdmin. I use utf8_general_ci, think that's one of the most common ones.
A mysql tabledump will add CHARSET=utf8 to it.
Another thought about logging: Maybe make it so we can 'attach' it to a user or group to monitor that user or group?
Just a sidenote: Be careful not to mix up charset with collation in MySQL. What you can change with phpMyAdmin easily is collation. It only affects sorting of results when using ORDER BY. To change the CHARSET of a table, you need to export and re-import it. At least i don’t know of any other way.
Edit: I think, Unicode was worth a cookbook article 
Hi all,
Great idea this skeleton app… thanks for you efforts.
Why don't you make available download files for the latest nightly snapshot or something? In extensions or in Google code. This would make downloads easy if no svn access is available.
Cheers
Thanks mike for the cookbook article, I will switch it to utf in the next version.
@gib Your right, the next version will have a downloadable version
I’ve been thinking about the ParseCachebehavior that is included.
Right now it stores the parsed data in a separate table, unlike in the blog tutorial where it is stored in the same table but under a different column. Storing the cache in a separate table seemed like a good idea because you could then add the behavior to a model without adding columns to that table to hold the caches.
But now I'm looking at downsides
Slower as it requires extra mysql queries
You can only store the parsed data in a column of type text
you have to worry about eager-loading the cache in your queries
you can't access the cache directly but have to use a behavior method
I'm thinking about changing the behavior to store the parsed data in the same table, and under the column with the same name as the source column but with the configurable suffix 'Parsed' (like the blog but with a different suffix)
So the parsed content of content would be stored in contentParsed in the same table
It would be able to be any type of data - even numerical.
This could be used to even cache an average (star) rating and store it in an int column.
Also you wouldn't have to worry about eager-loading the cache which was a hassle for me.
Any thoughts before I do this?
To be honest, I wasn't convinced that the separate parsecache table is the best solution, for the reasons you already mentioned.
I personally think the idea to store the display/cached data in a separate column at the time of insert/update is the way to go. But only for certain, very specific 'parsed' data.
Don't really see the need for other data in a cached column, one of the main reasons is that for other data (like ints, vars, averages etc) Yii does have very nice cache options built in.
If you want speed and flexibility, put the output in memcache.
Yet another option can be to use fragment cache in the view.
But if you want more speed, you could make the (separate) parsecache table a MySQL 'memory' table. Needs to be rebuild after a restart, but can be pretty fast. Make the column a blob if you want to store other stuff in it as well.
Storing and regularly updating average star ratings in a furthermore quite static table doesn't feel so good to me. better to use one of the other Yii options for that probably.
You define which columns to parse and cache in the behavior settings. You also define the method to parse it in the behavior settings.
Your right, it wouldn't do much for a rating system, but this is what you could do:
Say you store ratings for articles
You might have a totalRating column, numberRatings column, and averageRating column.
Say if someone votes a 6:
totalRating += 6
numberRatings += 1
And the ParseCacheBahavior could then be set up to to calculate averageRating in beforeSave(), which would be:
averageRating = totalRating / numberRatings
This however is much more useful for parsing such as Markdown, which is what it does by default. And now if you want markdown in a varchar column, that would be easy
Great job with the skeleton. Its a great way to start working with the framework.
However i´m having an issue with the /post/list page. It wont load the "body" of the page and the css. Im not getting any error messages. Everything else works fine!
This is what it looks like: http://skitch.com/ca…mozilla-firefox
Anybody else having the same problem?