CodeIgniter Forums

Full Version: Pulling my hairout
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2

El Forum

[eluser]phantomkiwi[/eluser]
After spending about a week reading up on all the different frameworks I thought I'll give CL a go...

So far I've found the follow Pitfalls

1. There is no logical way to call a template first then assign a page (view) or sections (views) to the template.

1.A. Inserting view calls in the controller to make a skin ruins the whole point of a layout separation from code. As the layout calls would be in the code...

1.B. Also even if someone figures out a way around templates, you run in to another problem a page (view) could have a CSS or javascript file of it's own or ones that override the template CSS after all this is the way layouts should work.

2. How on earth do you make dynamic menu's based of Auth access?

------------------------------------------------------------------

I'm going back to my own framework which is database cached driven.

Where you can:

Create a template assign css, javascript
Create pages assign to different templates and assign css, js to the page
Create includes
Tell where the sections go int the template
Auth logging
Dynamic Menus
Plus heaps more to list

File based PHP frameworks are stuck in the dark ages

El Forum

[eluser]bigtony[/eluser]
If your framework is so superior then yes indeed you should continue to use it. The rest of us have discovered easy solutions to all of your alleged 'pitfalls' either ourselves or by using the search feature of the forums.

If you were unable to that says more about you than it does about CI... ;-)

El Forum

[eluser]jayrulez[/eluser]
[quote author="phantomkiwi" date="1249128322"]After spending about a week reading up on all the different frameworks I thought I'll give CL a go...

So far I've found the follow Pitfalls

1. There is no logical way to call a template first then assign a page (view) or sections (views) to the template.

1.A. Inserting view calls in the controller to make a skin ruins the whole point of a layout separation from code. As the layout calls would be in the code...

1.B. Also even if someone figures out a way around templates, you run in to another problem a page (view) could have a CSS or javascript file of it's own or ones that override the template CSS after all this is the way layouts should work.

2. How on earth do you make dynamic menu's based of Auth access?

------------------------------------------------------------------

I'm going back to my own framework which is database cached driven.

Where you can:

Create a template assign css, javascript
Create pages assign to different templates and assign css, js to the page
Create includes
Tell where the sections go int the template
Auth logging
Dynamic Menus
Plus heaps more to list

File based PHP frameworks are stuck in the dark ages[/quote]

which framework is that?

El Forum

[eluser]Stallon[/eluser]
i bet he his talking about cakephp or such.... he deserves a slow framework, which is not readily deployable Tongue

El Forum

[eluser]garymardell[/eluser]
Quote:File based PHP frameworks are stuck in the dark ages

I don't even know what that means. Smile

El Forum

[eluser]phantomkiwi[/eluser]
It means the viewers controllers and models are stored in a database with a backend manager...

So you can quickly create a template embed a page in side the template attach javascript and css add inlcudes (snippets). Assign permissions (auth) publish dates etc...

Then you can create dynamic menus based on permissions and orders without going through lots of files and editing variables.

Plus it has a fall-back to the 'normal' flat file approach, for backwards compatibility.

I'm working on it now...

Just think of it as CodeIgnitor on steroids!

El Forum

[eluser]wiredesignz[/eluser]
Sounds to me like CodeIgniter on tranquilizers. Database access is slower than file access.

But I would be interested to see how you store a controller or model in a database. Unless its a proper object database you would be adding major overhead to your framework.

This entire thread suggests your understanding of the MVC design pattern and PHP object theory might be a bit incomplete.

Also considering the number of people that use CodeIgniter suggests that it does actually work.

El Forum

[eluser]jayrulez[/eluser]
[quote author="phantomkiwi" date="1249281860"]It means the viewers controllers and models are stored in a database with a backend manager...

So you can quickly create a template embed a page in side the template attach javascript and css add inlcudes (snippets). Assign permissions (auth) publish dates etc...

Then you can create dynamic menus based on permissions and orders without going through lots of files and editing variables.

Plus it has a fall-back to the 'normal' flat file approach, for backwards compatibility.

I'm working on it now...

Just think of it as CodeIgnitor on steroids![/quote]

what would be the advantages to storing controllers and models in the database? i was under the impression that controllers are supposed to call models in order to interact with the database, and following this logic in accordance with your aim, you would interact with the database to access a controller which will get a model from the database in order to call a model to interact with the database. what would be the sense to doing all that?

and with regards to auth/rbac/acl there are frameworks like yii,i-framework etc... that provide those and you can create dynamic menus based on permission with them.

and as for templates, there are frameworks that offer what u mentioned

El Forum

[eluser]phantomkiwi[/eluser]
So you can build a site quicker without having to flick through the file system and could be extended to a CMS framework...

File systems never make for very good dynamic menu structures and page reordering etc....

El Forum

[eluser]RogerM[/eluser]
It seems like you haven't tried CI to the fullest of it's capabilities.

Most have found ways around your problems that you are having and successfully put out web apps by doing it.

If your framework is that much better then CI, then go back to it. We all have our frameworks that we like, and it seems CI isn't for you.


Best of luck in your coding.
Pages: 1 2