Website and admin structure

[eluser]Colin Williams[/eluser]

Are you referring to seperating a web app into 2 halves? I can see there would be some issues in regards to duplicate code and having to maintain that duplicate code etc, but I think for relatively simple projects (eg. a portfolio, where the visitor does not interact with the site a great deal) it can simplify things a bit. Why do you think it would be a bad approach? Interested to hear your reply.

A couple of things... Yes, I am against splitting up the app into a backend and a frontend. Duplicate code is certainly a part of that, but I don't like it even at a higher level. Seems to me people go that route because they figure it will be easier to do blanket access control on a single controller (or directory of controllers). But that's just a poor excuse for a bad authorization system.

I don't like the example of a simple portfolio. Why in the world would someone employ a framework like CI to build something better handled by a CMS. And still, the argument for splitting it up probably comes back to the lack of a flexible authorization scheme.

Why have two controllers for one object?

[eluser]underskor[/eluser]
[quote author="Colin Williams" date="1232720282"]I don't like the example of a simple portfolio. Why in the world would someone employ a framework like CI to build something better handled by a CMS.[/quote]

I'm not sure I understand what point you are making there. A 'simple portfolio' should just use a CMS?

[eluser]Colin Williams[/eluser]
It would make the most business sense, underskor. Faster to prototype. Faster to develop. Easier to maintain. Broader support availability. If you are just creating a site for an entity to create, manage and display portfolio items, a CMS is probably the logical way to go. CI would make more sense for a site that has features not covered by basic CMS functionality--if the conventions of a CMS don't align with the application in question.

[eluser]underskor[/eluser]
Ah yeah, I see what you mean - 'why reinvent the wheel if the requirements of a project are met by software out there'.

[eluser]Michael;[/eluser]
I think the idea behind creating a frontend and backend is more about user familiarity. I have been working for quite some time on a CMS application which targets small/medium sized business websites.

I was demonstrating to a client how to manage their site with the avail javascript functionality that would allow them to manage their content from the front end ... Now, not 5 minutes before that I went over the Access and Authorization system, as well as the available Administration backend, not forgetting to mention and highlight the fact that making the fronend inline editing and administration configurable, etc; the first question out of my client's mouth:

"So, if I turn this on will just anyone be able to edit my site?"

So, from a technical perspective I agree with you. It's far, far more intuitive and, IMO, provides a more streamlined code base if you roll it all into one. But the "end user" *EXPECTS* and has very strong opinions on how "secure" something really is if their "Administration" is not segregated from the rest of the site. Silly, I know ...

Michael;

[eluser]IamPrototype[/eluser]
[quote author="Michael;" date="1232713343"]Greets all,

I just thought I would throw my set up into the mix here. It's a bit different, but it's rather organized and keeps everything clean and straight forward. As a lot of sites end up on a shared hosting plan, or just linux hosting in general, this does user a '/home/user/' path scheme ...

/system
/application
-> /controllers
-> -> /admin
-> -> -> blog.php
-> -> -> forum.php
-> -> blog.php
-> -> forum.php
/public_html
-> /assets
-> -> /css
-> -> /images
-> -> /js
-> /themes
-> -> /x-theme
-> -> /y-theme

This setup allows you to have a single application folder, thus only 1 index.php. No extra routing constraints or concerns. In fact, the only thing you have to remember is that www.example.com/admin/ will route to whatever your default controller is ... i.e. if blog.php is your default controller, then when you put www.example.com/admin/ into your browser it will default to the blog.php file in your admin folder.

Michael;[/quote]

That is what I use too!

[eluser]Phil Sturgeon[/eluser]
[quote author="Michael;" date="1232738395"]"So, if I turn this on will just anyone be able to edit my site?"[/quote]

You: "No, only administrators."

Client: "Ahh, ok!"

I really can't see this being an argument against in-line editing, and doesn't really bring anything to the argument of code separation. You can have a separate frontend and backend shown to the user whether you run it as two applications or not, the only difference is the layout of the code and the amount of duplication required to get the same effect.

[eluser]corkscrew[/eluser]
Hello All

Relatively new to Codeigniter.
Enjoying the ease of use but:

What is the generally accepted method of handling

www.example.com/admin/

The "default controller issue"



Tom

[eluser]Phil Sturgeon[/eluser]
When I am building an admin structure with sub-directories I use:

Code:

$route['admin'] = "admin/dashboard";

[eluser]Joshua Logsdon[/eluser]
I can second that. Also I wanted to add that I've sometimes made the 'admin' route something uncommon like 'mysiteadmin' if you need to keep it less obvious.