+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: Archived Discussions (https://forum.codeigniter.com/forumdisplay.php?fid=20)
+--- Forum: Archived General Discussion (https://forum.codeigniter.com/forumdisplay.php?fid=21)
+--- Thread: Approach to larger application architecture (/showthread.php?tid=17650)
Approach to larger application architecture - El Forum - 04-11-2009
[eluser]janroald[/eluser]
Hi guys,
I spent the better part of the week trying to explore the CodeIgniter framework. However, I do miss examples of larger architecture than the ones made available in the videos. I've also watched the one at http://video.derekallard.com/
Personally i don't like splitting my application views into header, footer, etc. I prefer having a master template(or several) which i then inject content to. Typically - an application of a larger size only changes the content on one or two parts of the total page when something is clicked. I don't intend to duplicate my skeleton-code for each action in my application that changes the view. In D. Allard's application he creates a function in his main controller for each action on the page, then duplicates his header/footer calls in each function. If we multiply the actions available in the application with a houndred, I would like to see an approach that doesn't involve very large controller files, and that doesnt require the constant rebuilding of a standard view.
Can someone provide an example or point to one that provides such architecture with CodeIgniter? Or is CodeIgniter just suited to make "prettier" versions of the scaffolding-feature?
Approach to larger application architecture - El Forum - 04-11-2009
[eluser]jedd[/eluser]
[quote author="janroald" date="1239462958"]I spent the better part of the week trying to explore the CodeIgniter framework. However, I do miss examples of larger architecture than the ones made available in the videos. I've also watched the one at http://video.derekallard.com/[/quote]
Is Bamboo Invoice insufficiently large an example for you?
Quote:Personally i don't like splitting my application views into header, footer, etc. I prefer having a master template(or several) which i then inject content to.
Quote:Typically - an application of a larger size only changes the content on one or two parts of the total page when something is clicked. I don't intend to duplicate my skeleton-code for each action in my application that changes the view.
You appear to be contradicting yourself here.
I agree that applications, of any size, tend to change only parts of the page - others are fairly consistent. That's why people usually adopt the approach of having headers and footers generated separately, as they are the bits that tend to not change very often (between pages).
I'm not quite sure what it is that you're trying to achieve, that you feel you can not.
I do think it's unfair to take a tutorial example and cite that as bad practice for large scale applications - clearly the tutorial was designed to get across certain aspects of the framework - not provide the basis for massive application architecture decisions.
Approach to larger application architecture - El Forum - 04-11-2009
[eluser]janroald[/eluser]
First of all, thank you for answering, Jedd.
[quote author="jedd" date="1239467417"]
Is Bamboo Invoice insufficiently large an example for you?
[/quote]
Thank you. Will look into that one.
[quote author="jedd" date="1239467417"]
Quote:Personally i don't like splitting my application views into header, footer, etc. I prefer having a master template(or several) which i then inject content to.
Quote:Typically - an application of a larger size only changes the content on one or two parts of the total page when something is clicked. I don't intend to duplicate my skeleton-code for each action in my application that changes the view.
You appear to be contradicting yourself here.
[/quote]
I'm sorry, I've tried, but cannot see the contradiction you are referring to, even at best will.
[quote author="jedd" date="1239467417"]
I do think it's unfair to take a tutorial example and cite that as bad practice for large scale applications - clearly the tutorial was designed to get across certain aspects of the framework - not provide the basis for massive application architecture decisions.[/quote]
[/quote]
That was not my intention at all. It was more of a "I see how this one is done, but how would one approach it if the application was substantially larger? Apparently this approach would not suffice."
[quote author="jedd" date="1239467417"]
I agree that applications, of any size, tend to change only parts of the page - others are fairly consistent. That's why people usually adopt the approach of having headers and footers generated separately, as they are the bits that tend to not change very often (between pages).
I'm not quite sure what it is that you're trying to achieve, that you feel you can not.
[/quote]
Spearating the page into parts like that often leads to needing logic to decide which parts are "compatible". A certain header needs a certain footer, etc etc. (think about changing the entire page layout substantially) But this is a sidetrack from my topic, and really a preference issue.
What my question really is :
Say the page is divided into a header division, a left column, a center column, a right column and a footer. say /blog/123/ and /article/123/ only changes the content of the center column. I want the logic to run through the exact same code during the outer parts, then ofc. differ at the center column logic.
Approach to larger application architecture - El Forum - 04-14-2009
[eluser]gyo[/eluser]
What I do is to create the main view (template.php) that contains all the parts directly in it plus a $content variable.
Then from the controllers you can just pass the $content to the template to replace that part.
Anyway, you can always use whatever template engine to suits your needs.
Hope it helps!
Approach to larger application architecture - El Forum - 04-14-2009
[eluser]jedd[/eluser]
[quote author="jedd" date="1239467417"]
Quote:Personally i don't like splitting my application views into header, footer, etc. I prefer having a master template(or several) which i then inject content to.
Quote:Typically - an application of a larger size only changes the content on one or two parts of the total page when something is clicked. I don't intend to duplicate my skeleton-code for each action in my application that changes the view.
I'm sorry, I've tried, but cannot see the contradiction you are referring to, even at best will.
[/quote]
Okay, I'm probably diving too far into the nuances of what I interpret you to be saying -- so let me say how I understand your problem and intention.
Rather than having separate functions within your application that service separate physical components (areas) of your page that are generated on most pages, you prefer to have skeleton code that generates the separate physical components of your web page.
The distinction is perhaps too subtle for me - whether the skeleton code generates the areas as one job lot, or as the header, footer, etc areas.
It seems to me that you're saying that, basically, you want to avoid code duplication. But you don't want to use functions to generate common areas of your web page, or you don't want areas of your web page to be generated by dedicated functions.
Quote:That was not my intention at all. It was more of a "I see how this one is done, but how would one approach it if the application was substantially larger? Apparently this approach would not suffice."
Ah, yes, well, those kinds of tutorials are perhaps lacking - but it's such a nebulous area, once you get out of the here's how you create a basic blog app in twenty minutes subject area.
Everyone will have their own ways of developing applications, and their own understanding of MVC, combined with an understanding of CI - all developed from experience developing smaller applications, using that methodology and that framework.
Pondering on it, I can't see how you could actually give anything other than really broad suggestions on how to design something mammoth. Document your project with phpdoc (or similar). Be consistent with your coding style. Use sub-directories for views and perhaps controllers. Don't wear spots and stripes. That kind of thing.
Quote:What my question really is :
Say the page is divided into a header division, a left column, a center column, a right column and a footer. say /blog/123/ and /article/123/ only changes the content of the center column. I want the logic to run through the exact same code during the outer parts, then ofc. differ at the center column logic.
The tradeoff here, as it always will be, is how early can you introduce significant application logic compared to how early you can spawn off frequent tasks - or from another angle, how much wasted work are you willing to have occur in order to have your logic somewhere convenient.
If you are willing for the header, left, center, right, and footer sections always get generated, even if there's a small chance they won't be utilised on a given page - then the answer is pretty easy. (I'd [url="http://localhost/devel/ci_user_guide/general/core_classes.html"]extend the Controller class[/url].) If you don't want to risk ever producing view-code that might not get used, then you necessarily have to pull that function further down into your controllers - at which point you will necessarily be repeating yourself for all the cases that you do want it produced.
Hence the trade-off.
Of course you can get tricky and try to set flags and have some logic up high to determine what to do, but in my view this introduces its own risks. Frequently displayed bits of near-static data are likely to be cached in any case.
Approach to larger application architecture - El Forum - 04-15-2009
[eluser]janroald[/eluser]
Thx for a very good post, Jedd. Think we're on the right track now :-)
I saw the way BambooInvoice extended the Controller Class, and it made sense. I've got an idea how to avoid too much logical repetition now.
I'm pondering the thought of having multiple controllers, fired by a "director" class on top. The controllers (as many as you want) would then control separate content areas, or logical areas. And then a render function would sow it all together at the end. How do you think that sounds? (sorry if I'm spinning away from CI)
Approach to larger application architecture - El Forum - 04-15-2009
[eluser]gyo[/eluser]
For me this is getting far more complex than it actually is.
Approach to larger application architecture - El Forum - 04-15-2009
[eluser]jedd[/eluser]
Quote:I'm pondering the thought of having multiple controllers, fired by a "director" class on top. The controllers (as many as you want) would then control separate content areas, or logical areas. And then a render function would sow it all together at the end. How do you think that sounds? (sorry if I'm spinning away from CI)
I don't come from an OO background, so the idea of lots of extra levels of inheritance is something I've never found attractive - the second level of inheritance here (extending the controller class) is about as excited as I can get on the subject. Beyond that change, I think I'd just confuse myself. But not many people are me, of course.
And given the way a controller maps to a URL (caveats apply, but you know what I mean) I can't see that it'll make the design any easier to complicate things thus. If you end up with a really bloated MY_Controller class, then you'd probably want to re-visit the way you were attempting to achieve your goals .. but the same could be said for any edge case.
Also, really, 'multiple controllers, fired by a 'director' class on top' -- pretty much sums up the way that the CI framework works out of the box - the director being the CI glue, and the multiple controllers being all those things you put in the ./application/controllers/ directory.