Application structure question

[eluser]Colin Williams[/eluser]
[quote author="wiredesignz" date="1216823165"]You are allowed to agree with some things Colin. :lol:[/quote]

Sort of.

[eluser]beemr[/eluser]
[quote author="wiredesignz" date="1216820187"]A library loading views?... This sounds suspiciously like a controller to me.[/quote]
Yes. It's a bit of a bastardization, but it is tidy. All of my auth code exists in the auth library. If I need global access to another discreet "module", it will live in its own separate library. Models and views are still separated CI-style. Call it MVLibrary.

Micheal Wales was describing what is often called a "Super Controller" pattern, but the tradeoff is that there is only one parent controller. If you are running many different such "modules" through your Super-controller, you will have a monolithic entity that holds disparate functions. While the Super-controller is passing down an auth module, it might also be passing down a cart and a messaging cue.

Super-controller: Would you like a shopping cart, messaging, and advertisements with that context-nav?

MVLibrary: what controller?

[eluser]beemr[/eluser]
While we are on the topic,

Haven't I read somewhere here that EE 2.0 will be a library for CI 2.0? If so, then that would be MVLibrary in the extreme.

[eluser]Randy Casburn[/eluser]
@Colin --

This one could stand a little debating too then my friend...

Much better than relying on the client to load it. Much, much better.

I respect your opinion, but it is just that. We all have opinions about these things. As I am in complete disagreement with you.

Use of the client to make page requests or making requests for a particular "resource" is natural on the web. That is what they do after all. Request resources referenced by URIs located at URLs.

@shaffick -- I think using the client to request resources from the server is a completely acceptable way to accomplish your task. In CI terms that means you are calling a controller method from the client and returning a view partial directly to the client. That makes folks nervous here. Since you're doing so with JavaScript, we'll catch all kinds of flack because only between 96.7%-99.6% of all internet users today have JavaScript turned on. But I'm with you on this. You and I can be the rebels ;-)

Client/Server architectures out date all of us here. We live in a client server architecture.

I still like you Colin %-P

Randy

[eluser]beemr[/eluser]
[quote author="Randy Casburn" date="1216853358"]Use of the client to make page requests or making requests for a particular "resource" is natural on the web. That is what they do after all. Request resources referenced by URIs located at URLs.[/quote]

In this case, however, the client has already made a request; that would be the URL in the address bar. The OP is piggy-backing an Ajax request on top of the URL. That is what makes this approach a little schlocky.

Ajax is best and safest when it is an enhancement rather than an enabler.

[eluser]Randy Casburn[/eluser]
beemr -- That is one way of seeing things...

That would require one to completely segregate the client capabilities and separate them with distinction and treat them with disregard (maybe disrepute) with respect to thinking of the software we are building in terms of an architecture.

Another way, a way I would suggest is equally deserving of rational consideration is...

Treating the architecture as a whole and capitalizing on the components of the architecture in a way that makes sense for our software development goals. That means utilizing the client where necessary and the server where necessary and all the parts and pieces in between.

===
I thought you did a good job of capturing some of this in the other thread.

PHP controller -> MYSQL model -> PHP view which creates a browser event controller (read javascript) -> XHTML model -> CSS view. Both of these halves are connected by an Apache controller -> HTTP model -> POST or GET view.

There are proxies, and caches, and firewalls, and all sorts of things in between, but we get the general idea.

====

The client capabilities are much more than just some made up thing called "Ajax".

Randy

[eluser]Rick Jolly[/eluser]
[quote author="beemr" date="1216818578"]Have your library's methods return views, and you will keep the impact on your controllers down to one or two lines.

Code:

$this->load->view('header');
$this->load->my_library;
$this->my_library->user_status();
$this->load->view('footer');

[/quote]

Beating a dead horse here. That code could also be in the view, with a couple minor mods:

Code:

<?php $this->load->view('header'); ?>
<?=module('my_library','user_status');>
<?php $this->load->view('footer'); ?>

Where the module() method is a helper that just loads libraries and calls methods. That's HMVC if you think of the library as "controller-like" interface between a view partial and (optionally) models.

[eluser]beemr[/eluser]
Exactly. You could also keep your variables at the controller level. In fact, it might be necessary depending on how much context scope you need.

Code:

$data['method'] = 'user_status';
$this->load->view('template',$data);

Then in view/template.php:

Code:

<?php $this->load->view('header'); ?>
<?=module('my_library',$method);>
<?php $this->load->view('footer'); ?>

[eluser]shaffick[/eluser]
[quote author="beemr" date="1216818578"][quote author="Colin Williams" date="1216809540"]2 cheers for accessibility! Sheesh...[/quote]

I second the sentiment.[/quote]
You guys missed the "temporary workaround" part, right?

Appreciate the discussion that followed. Gave me some ideas to plan for the future.

cheers

[eluser]Sixer[/eluser]
[quote author="Michael Wales" date="1216632824"]Or, you could make a class that extends Controller - place all of your code shared across controllers in it - then extend your normal Controller class off of this one.[/quote]

Where would this Super Controller be defined, and when/where would it be loaded ? Would I put it in a library of some sort?


.. to answer my own question:

Put it in application/libraries/MY_Controller.php