Welcome Guest, Not a member yet? Register   Sign In
Flexible intranet development. Taking thoughts.
#1

[eluser]vasocreta[/eluser]
Hi, CI coders!

I am 3 days old to CI, coming from a Fusebox (intermediate) background. Fusebox presented some issues for me as I tried to think through a current project where I am developing an intranet for my workplace. I work in education and the challenge that faces me is that my itty-bitty organization at the university requires an intranet that will be made up of many micro-sites. There are about 10-15 different working groups and each group is in charge of their own content. As it turns out, each group wants to incorporate their own designs for their little section of the intranet as well.

In this case, I feel that Fusebox allowed me a bit more of a straightforward path to achieving this. But I want to use CI.

So...onto the question, eh?
When setting up controllers, I was thinking that each controller would represent a group. Is this the best way to think about this? I guess I am so used to using hierarchy of folders (Circuits, for you Fusebox speakers) to structure my backend. With CI, it seems that each controller is simply a file rather than a folder that contains files.
Can the controller folder contain folders? Is there a reason to even do that?

That is enough from the noob for now. I appreciate any insight I can gain from all of you. I have heard about the CI community and that is a big part of what made me want to try this framework.
#2

[eluser]kurucu[/eluser]
I don't wish to be hated, but if it is just an intranet you are developing (i.e. clever content) then ModX might be a good place to look, especially the Revolution version (currently in beta phase) which allows you to specify different 'contexts' e.g. for your university microsites. It is very powerful and through the use of 'snippets' allows you to generate and present content from an unlimited variety of sources.

Hatespeach over.

In my mind, controllers are normally broken into functionality rather than necessarily site areas. That said, you can of course do what you want. However, by ordering them by functionality only the resources needed for each function have to be loaded and so they are more efficient. Also, it's cleaner and simpler to follow (you would pass a parameters to change context). You can store them in folders, and this does the same as on disk - for categorisation and organisation.

With CI (and probably any framework/cms) you have to stop thinking of the raw filesystem unless debugging. Instead, you have to think in terms of the frameworks native language and intentions, otherwise there is probably going to be a collision later down the line, or maybe even no point to using the framework.

So, thinking in CI terms, it's obviously worth reading the documentation, but the controllers are essentially the request brokers, pulling in the relevant data, processing it, and sending it off to somewhere for changing to a suitable output. Despite the fact that they are stored on the filesystem, you rather want to forget that users could access any other resource except images/client scripts/css etc.

There are many deviations and advanced/specific uses of controllers and folders in the controller directory, but that should be enough to get you thinking.
#3

[eluser]kurucu[/eluser]
It's just occured to me - from the way you have asked the question I am wondering about your intentions for the controller.

Ordinarily, a page on an intranet is one set of content, and another is another. You would not provide a controller for each page of content, and if that's what your expecting then I think you have the wrong end of the stick.

A controller provides a suite of functions, and those functions (I mean actions rather than software functions) each do a particular job. So, you might provide a controller 'page' and a function 'view' which always renders intranet pages, and then it accepts a parameter 'page_id' to know which page to render. At least, that's the most scaleable method - you can add pages without changing your code. It is unlikely you would want different controllers and functions for each page unless each page (and I speak of content pages here) had very different functionality. If that is what you want, a CMS or CMF is what you're looking for (like ModX).

But, if you didn't ask that, and you are developing a suite of intranet functionality then CI is definitely the place for you. CI is a structured way to write PHP programs (excuse me if I'm teaching a granny to suck eggs here, but I think your question might have made a few bad assumptions). Thus, you would use CI to write, perhaps, the intranet authentication, page viewing, departmental staff and student lists, maintain a course list, get information from the education system for presenting an individual with their results and chosen subjects...

In other words, specific functionality including that of a CMS.
#4

[eluser]vasocreta[/eluser]
THANK YOU for all of this input. I have a lot to sift through as I venture on this intranet thing and your feedback and thoughts were helpful and insightful.

I think that the main thing with any framework is learning how to leverage the structure of the framework with the envisioned structure (IA) of the site in development. The intranet that we are building is slightly unique in the sense that it is really a bunch of micro-sites that essentially live under a singular umbrella. So, you might have a little home on the intranet for HR, but then you have a project team that desires their neck of the woods to be laid out differently and incorporate different functionality than another project team.

Anyway...that is probably more than you wanted to know.

For now, I am going to be plugging through the documentation, using up A LOT of sticky notes on the wall and checking out ModX (which will not work if it is like most other CMSs and all pages have to conform to a singular theme).

Your gracious replies have added some flavor to the cud I am currently chewing. :-)
#5

[eluser]BrianDHall[/eluser]
After a little thinking, it might be best to do this by extending Controller with a MY_controller. In the MY_controller you build all your stuff that is common to the whole intranet, such as a login/auth system, perhaps basic page template concept (like every page will have header, footer, navigation, content, etc) etc.

Then you can build individual controllers for each micro-site or department to over-ride only the things they want differently.

So if HR wants special functions just for them, easy - just pop open the HR controller and add to your hearts content. If there is a bug or feature that needs addressed for the company as a whole, just pop open your MY_controller and fix/add any way you like and instantly all sites will benefit from your improvements.

For URL you can either use sub-directories or sub-domains, as the routes file makes it pretty easy - hopefully you will have access to .htaccess url rewriting, as this makes things just cleaner looking and gives you a little more leeway in how you rig URLs to work.

This I think would be the best combination of flexibility and code reuse, and if some crazy department wants to just be totally crazily different than all the others - no problem!

You'll just want to organize your views sensibly so it is easy to see what view is shared amongst most/all sites, and which ones are department specific. You can just use folders for that, CI doesn't mind.

EDIT: As for Models, you can just use them normally or any way you want. I can't imagine any reason you couldn't use one Users table/model login system with a department field to restrict functions by department or position, etc.

In theory if some new department wants a basic site you could throw it together in a few minutes with minimal copy/pasting - they'll just get a site like you designed your basic template. As they want changes you just over-ride as you go, extending and modifying without fear of screwing up some other department site.
#6

[eluser]kurucu[/eluser]
I would be surprised if any CMS forces you to stick to a single theme. But either way, in complete contrast ModX sees everything you can access as another 'resource' and so the output could be different themes, just as it could be a PDF, XML or a Flash movie. Therefore, you can make information as common or unique as you like. What's more, with contexts you can set up intranet stuff as common, and then override any setting you like in the local context.

I love CI to pieces, and am building a whole custom website with it, including forums, CMS, and two complex applications (which are private until I've finished). But, for what you want, I think CI would be overkill. Something like ModX would already implement security, listed content (e.g. news/blogs/galleries - in fact whatever you want), the editors, file management etc etc etc. Plus it lets you plug in and use any PHP you need to connect to other systems or display custom data. And you can put it on the page however you want - you don't have to comply to "boxes" or any of the other common CMS stuff.

In short, unless there is some specific functionality you need to write yourself, you'll just be reinventing the wheel. I am using CI because I want to use common and custom data across a variety of systems including some I am building myself. I don't have access to LDAP or anything else that might tie it together, plus I'm interested in writing and customising the software to be exactly what I want. While it might be fun, you don't have to force yourself down that route needlessly.
#7

[eluser]vasocreta[/eluser]
Thanks, guys, for the advice(s) ;-)
I am truly considering all angles at this point, so reading different perspectives is very helpful.

On one side of the coin, there is a great advantage to rolling your own sort of CMS. It gives us maximum control over the functions of our site and we won't really ever suffer from any kind of bloat.

On the other hand, I agree that there is no real reason to reinvent the wheel when it comes to common features.

I think I need to think.
#8

[eluser]BrianDHall[/eluser]
You might also want to spend a little time and go ahead and try out a CMS, try putting up together a simple hello world sort of site and make changes. I did this with Magento (more ecommerce than pure CMS, admittedly) and hit a brick wall as soon as I got beyond the GUI - endless files, non-existant documentation, unhelpful tutorials, such a mess. I tried Joomla and found basic core functionality, like their category system, fundamentally worthless for my project and would need re-writing anyway. Drupal seems great, but if everyone says its hard to learn than I'm willing to believe them and I don't wanna bother Smile

Its really a question of how closely a pre-packaged system meets your needs. If you have do re-invent their core functionality there might be no point in messing with the complexities of someone else's system when you don't really need their extra features.

I've seen sites use Wordpress very smartly, and I've seen sites use it and suffer months of development by an entire team when one person could have built it from scratch in CodeIgniter.

If the system closely matches what you want and is closely analogous, go for it. If its a stretch at best (my predecessor thought posting coupons was logically similar to posting articles, and thereby slammed his head against a brick wall instead of making genuine progress), I've yet to find any point in reinventing someone else's wheel.




Theme © iAndrew 2016 - Forum software by © MyBB