• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Starting with CodeIgniter setup: suggestions & best practices

#21
[eluser]Unknown[/eluser]
Is there anyone that can help me with a website coded in CodeIgniter?
I have a website I purchased and the formatting (CSS) is not loading. Should be easy. I would be glad to share with anyone interested in taking a look at it. Email me mjbiggs at gmail.com

Regards,
MJB

#22
[eluser]Xaris[/eluser]
Just starting with CI and this posts pointed me in the right direction. Thank you all for your time putting your tips together

#23
[eluser]dmorin[/eluser]
Great list and I wanted to respond with some things that have helped me.
Quote:You’ll learn soon the value of putting the data-access in models, the logic in controllers and the visuals in views.

When I started, I put a lot of logic in my controllers which I found to be a huge mistake. I now try to follow these rules:
- If it's output, it should be in a view. However, you should try to keep as much logic as possible OUT of the views and instead put it in a helper (or if the formatting logic is more complex and deserves a class, continue down this list).
- If it involves any kind of data access (database, apis, etc), it should be in a model.
- If it's logic that could potentially be used in multiple applications (api access, generic classes), it should be a library.
- If it's logic that is application specific (some call this business logic) and it could potentially be used more than once in your application, it should be in a model.
- Only if the logic will, without a doubt, only be used once should you ever consider putting it in a controller since this is the part of CI that cannot be reused.

This kind of follows the DRY principal (Don't Repeat Yourself). Some will probably disagree which is ok, this is just my current best practice.

The only other thing I wanted to mention is related to your error reporting constant. I do a similar thing by setting a config item var called "is_production". If it's set to true (which I do at deploy time) it automatically turns off errors (including hiding errors in the default error views that CI ships with), turns on caching, and other things. That way, I can reference it anywhere in my app to make sure the production version runs with the correct options. You could also doing something like "app_state" and set it to dev/test/prod instead to have more granular control. That said, because it's in the config, it runs after CI initialization so I also disable errors in the index.php to make sure none are shown in case one happens before it processes the config.

#24
[eluser]Jelmer[/eluser]
The statement you referred to is of course a simplification of how things work. In essense you'll need logic everywhere in your application, even in your views. It's indeed the function specific logic that's not to be reused in other function that should be in the Controller, the other kinds of logic should be in libraries/models/helpers.

While I agree with most of what you said I have some notes:
Quote:If it’s output, it should be in a view. However, you should try to keep as much logic as possible OUT of the views and instead put it in a helper (or if the formatting logic is more complex and deserves a class, continue down this list).
Yes and no. While you shouldn't have any data-access and such in the view, you might need some post-processing of your data specific to your layout - that kind of logic should be in the view in my opinion. And helpers should only be involved when the functionality is needed in more then the one view, creating functions for just one view is just clutter and would be better within the view it is used in.

Quote:- If it’s logic that could potentially be used in multiple applications (api access, generic classes), it should be a library.
- If it’s logic that is application specific (some call this business logic) and it could potentially be used more than once in your application, it should be in a model.
This part of your list I don't get: models are for data-access and pretty much data-access only. Libraries are for functionality/logic to be shared among controllers, and if that involves data-access as well then you need both a library and a model for the "right" solution.
But functionality to be shared among applications? That's also something where libraries are good for, but not native CI functionality and probably not good for a generic list for beginners. How do you load libraries in multiple applications? Do you put that in the system/libraries folder? Or have you written an extention of the load->library() function? (the second being the preferable solution)

About the error reporting solution: That's more of a suggestion then a best practice, it's just how I like to do it but I can imagine there are many other ways.

#25
[eluser]dmorin[/eluser]
I think we're on the same page and in agreement on the views portion. I think most people just don't realize how much logic they put in their views. For example, I've seen apps where logic to do table stripping is re-written every time someone has a table they want to stripe which is a great example of something that should be re-factored out to keep the code DRY.

Models are not just for data access. Here is a snippit from wikipedia:

Quote:The model is the domain-specific representation of the data upon which the application operates. Domain logic adds meaning to raw data (for example, calculating whether today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items).

Domain Logic == Application Logic == Business Logic. So models aren't just for data access, but also manipulation, computation, and other concepts required to make the data usable to the application. Also note this following line from wikipedia:

Quote:When a model changes its state, it notifies its associated views so they can be refreshed.

In real MVC, the data from the models don't pass through the controller, they are sent straight to the view, so the controller can't implement any of the complex logic required. This isn't how views work in CI, but it still means that for MVC, most of the applications logic should be in Models and not in Controllers. I think this is one place where the CI user guide does a bit of disservice by conveying that the models are really only used for data access which is incorrect.

For libraries, I wasn't referring to the ability to have one file on a file system and re-use it for all of your CI apps. Instead, I ment that you should be able to copy a library from one CI Application/Libraries folder to another and be able to use it. That's the idea behind libraries, they're not application specific.

Lastly, I would argue that knowing if your application is running in Dev, Test, or Production is a best practice and not merely a suggestion since virtually every other framework out there supports it natively as a way to limit error messages and tune operations. That said, I understand why you wouldn't consider it needed on a beginners list.

EDIT:
An even better quote from wikipedia:
Quote:MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the model. Models are not data access objects; however, in very simple apps that have little domain logic there is no real distinction to be made.

#26
[eluser]Jelmer[/eluser]
This is in part about the way EllisLab implemented the MVC pattern, dealing with PHP that doesn't act like a normal application that keeps going but a scripting language that needs an entirely new process on each pageload.

That being said: As I learned it models are or contain instances of objects that represent the data you're working with. And as such models are never abstract and always deal with a specific object or list of objects on which they perform CRUD operations or other manipulations (like you mentioned).

While it is sometimes a good thing to keep libraries non-application specific, libraries are in essense toolboxes that deal with specific functionality and quite often with instances of models. Because of that you'll sometimes need to make your library application specific (or at least dependent on specific models) and there's nothing wrong with that.

The main difference is that models are for logic pertaining to 1 specific type of object representing actual information in your system, while libraries are meant to work with one or multiple objects together. An auth library for instance will work with specific users (a user model) and specific acl rules (an acl model) and aswer the question if access is allowed for a certain input.

EDIT: All of what I said is compatible with your quotes from wikipedia. That's what's meant by "the model is the domain-specific representation of the data".

#27
[eluser]dmorin[/eluser]
Your description of models is very similar to what an ORM is which isn't exactly what models are supposed to be, but that's ok. You're using libraries for things that I would put in the model. The real idea that I wanted to point out originally is that business logic does not belong in the controller which both of our solutions achieve! Unfortunately, this isn't represented in your original post where you say logic should be in the controller. Maybe that could be updated?

From wikipedia:
Quote:The controller receives input and initiates a response by making calls on model objects.

#28
[eluser]Jelmer[/eluser]
Your interpretation of MVC is a very strict one, and not neccesarily the best to use within CodeIgniter - though I have no doubt both interpretations work just as well. It's more about dividing up what you put where.

Quote:Your description of models is very similar to what an ORM is which isn’t exactly what models are supposed to be, but that’s ok.
What something is "supposed to be" is open to interpretation, MVC is a pattern and it's how a pattern is implemented that defines how it's "supposed to be used" - patterns are more like guidelines than cut-in-stone rules. In it's basic abstract form MVC has no concept of libraries, but there's also no concept of a configuration and no concept of some other things that are part of how you implement the basic idea into a workable system.
My models work with an ORM as their data access layer. The models are the rules and logic for working with the objects after the ORM has retrieved them or how & when to update, create or delete. The models work with the ORM's output, the model's aren't the ORM.

On the orignal posts: I'll think about expanding that part, but like I mentioned: it's a simplification meant to summarize but not meant to teach. That part of the post isn't meant to teach the reader what MVC is but to push the reader towards learning more about it, and no summary will satisfy every constraint. The basic premise of the sentense isn't that ALL logic should be in the controller, as all programming involves logic I would consider that to be self-evident.

#29
[eluser]dmorin[/eluser]
I'm not advocating a "strict" adherence to MVC at all. I just know that when I started with CI, I put most of my logic in my controllers and it has been a pain in the rear since then to re-write and re-factor it out of the controllers so I that I'm not repeating myself in every new controller. It's the kind of thing that I wish someone had mentioned when I was starting so when I saw you advocating the very thing that screwed me, I wanted to mention my point of view. And while you say your best practices list isn't supposed to teach, it seems like it should at least mention the "best practices". Anyway, I didn't mean for this to become an MVC debate, just trying to help new-comers avoid the stumbling blocks that I fell over, same as you.

#30
[eluser]Jelmer[/eluser]
Wow, you're getting me completely wrong.

Quote: I just know that when I started with CI, I put most of my logic in my controllers and it has been a pain in the rear since then to re-write and re-factor it out of the controllers so I that I’m not repeating myself in every new controller.
Which is something I fully understand and know about from my own experience.

Quote:And while you say your best practices list isn’t supposed to teach, it seems like it should at least mention the “best practices”.
Now that's taking my distinction (between teaching and pushing in the right direction) and going overboard with it.
I meant that I tried to write up a list that mentioned all, and because I tried to touch upon everything I had to limit the amount of information and summarize for each topic. Summaries are always a bit too short, a bit to simplistic (otherwise they wouldn't be summeries) and I hope that anyone reading it understands that I can't explain the whole of MVC in one sentence - which is why that whole paragraph is about reading more about MVC and has in total 7 links to other resources and tells the reader to read more about the subject.
There's too many possible bumps in the road to learning MVC and better programming to mention them all - the article is about helping the reader understand which topics are most important to read up on. It's meant as a start-off point, you can't expect to learn all in under 12000 characters (it's 2 posts with max 6000 characters each Wink).

And again, I'll think about some better wording but people should learn more on their own by using the links I've already posted and certainly not expecting that a one-sentence summary teaches all. Such summaries are about pointing in the right direction, but can never contain the whole truth and constrain every possible misinterpretation or over-interpretation.

EDIT: I've added a bit to the original posts, also included the DRY principle in 2 places - this should clear up what's meant by the sentence you take issue with.


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


Users browsing this thread:
1 Guest(s)


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2017 MyBB Group.