Closed sergeyklay closed 11 years ago
For performance big sites, we've changed many core classes with our own classes ORM, Config, Log, Request etc. I'll be committing ORM class shortly with less changes to cope up with Kohana. But in the present stack, the system folder has nothing changed, it's same as kohana core.
I'm just waiting for your commits, once you've added the changes, I'll add mine, we've done lot of changes to menu, widgets, etc.
I think you need to pull your commits..
My changes are scattered about and not systematic. I think we're doing one and the same job...
lot of changes to menu
@sandeepone Can i use the descriptions of parent items for top menu and to put them under the items title? See screenshot below:
You can use menu discription field to do this output. All items have description filed for this purpose. Let me know, if you get any issues with it.
See screenshot below
We're using MPTT for menus for better parent child relationship and for performance. So every item or parent has same set of fields. All you need to do is, just add description to parent items and no description for child items. And modify the menu render to echo the description where necessary. If you're using twitter bootstrap css, needs some work. If you can set up a demo, I can help you.
All right. Later on, I turn to you with this request
Pushed ORM classes into Gleez module than separate ORM module with performance and event/actions. Added icons support directly in Menu UI form fontawesome.
I would recommend using good practice.
For example, all protected properties and methods must begin with the _
prefix. For example:
class Classname {
protected $_var1;
protected static $_var2;
...
protected function _functionname()
{
Classname->$_var1 ....
Classname::$_var2 ....
}
}
This will help in the future, third-party developers to easily navigate through your code.
And also it would be nice if we all used the same quantity and quality of indentation (spaces XOR tabs). Maybe we should take as a basis the recommendations guys from Kohana and finish a little to fit their needs. I believe that these things should be documented in the Gleez Wiki
I've converted most of the members to _prefix, still there are long list of things to do. I agree with you.
Transfered all these issues to #169
We need some means for counting the amount of code that we are different from Kohana. I do not rule out the fact that when the differences will be quite a lot, we will cease to depend on Kohana