CodeIgniter Forums

Full Version: Introduction to CodeIgniter 4 Blog Posts
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
Since it looks like I'll be doing a handful of blog posts over the coming weeks about CodeIgniter 4, I thought I'd pull them all together in one thread so it's easier to keep track of, and feels less spammy.

So, here they are in the order they were written. If you have any topics you want me to talk about, and the code is to a point where I can talk about it, leave me a comment below.

1. Requests and Responses
2. Content Negotiation
3. Dependency Injection and Services
4. Routing
5. Modules
6. Database Basics
7. HTTP Client
8. Getting Started with CodeIgniter 4
9. Using Entities
10. Better Entities
11. Upgrading the Parser
Hello, Lonnie! It is excellent! It will be interesting to read the article about the new routing.
I just added a new article to the list on Dependency Injection and Services.

And - condor - that sounds like a great topic. Will likely do that one next. Not sure exactly when it will happen, though. Likely in a week or so.
Hey Condor -

Just added the overview of the new routing situation for you. Figured I'd get it knocked out before leaving for the rest of the week tomorrow.
Hi there, very nice, thank you and congratulations!
This is excellent, Lonnie! It's really a lot of interesting. Many thanks for the work done.

I think that it would be good if the CodeIgniter site has blog system where you can quote the threads from your site

It will be good if all the helpful information can be found inside the CI website. With correct links to the original thread.
And may be in future even other really helpful outer threads can be listed there with credentials to the writers..

Big +++ for the threads Smile
(03-03-2016, 10:19 PM)kilishan Wrote: [ -> ]...

1. Requests and Responses
2. Content Negotiation
3. Dependency Injection and Services
4. Routing

So far I've not been all that thrilled about anything presented in these 4 blog posts. Routing seems the nicest new change for CI4.

The "DI" is a little odd to me. If I want a db connection in my model, which I pretty much always do, I don't really want to inject it the way your example shows, every single time. I wouldn't even call it DI, and you haven't, as you're managing everything through a class called "Services". It really is a service locator, right? Sure to turn up the noses of many. Personally, I don't care if it's a service locator, but I think I'd need to wait and see how you tie everything together and make CI4 as easy to use as the CI I've been using since 2009. If it's really just a service locator, why not just pass around the "container"? There's really no need to answer these questions. I'm just typing what I'm thinking.

Requests and Responses, and Content Negotiation ... not anything for me to get excited about. I guess I found the force_https() function nice, and hope that it includes a way to give a 404 if I'd prefer not to redirect to the https. For instance, force_https(FALSE);. Sometimes redirecting to the https page is not in the best interest of the website.

Obviously you're still a long ways away from a launch date, so we're likely to see things change drastically. I'm looking forward to seeing more blog posts, and although you've got a repo that can be peeked at, I do like that I don't have to go there to find out what's going on. One thing I'm more interested to see is how you plan to allow class extensions. That's probably just handled in Config/Services, yes?

No need to break out the flame thrower, as these are just my first impressions and thoughts.

Thanks for your time, and the hard work.
Hey skunkbad, thanks for your comments. Just like CI has always been, it's still extremely flexible, and in some ways more than ever. I think a lot of that doesn't come through until you start playing with it. So a lot of what has been seen in the articles isn't on the "exciting" front that you might see in a new features brochure, but should really help in the long run.

As for DI and needing to inject the database dependency - there's no need to do that if you don't want. The way it currently stands, you can always grab an instance of the database by doing

$db = Services::database('default');

If you choose to use DI in your own libraries, then you can inject that instance when you create new objects if you want. Or you can pull another instance (or a shared instance) within the library. It's all up to you.

As for DI/versus Service Locator, that topic always brings up a lot of debate. Smile After all of the reading that I've done on the topic, the best description I've seen says that the only difference between a DI Container and a Service Locator is whether it's used from within the class that is using it or outside with the instance passed in. It should be noted that actual DI is completely separate from a DI container. So, the current solution, if used in the controller and the instance passed into the libraries, is acting as a DI container. If you using the current solution inside one of your objects, it's acting as a Service Locator. And the primary reason that people get up and arms about all of this is for testability.

But, yes, we use it internally as a DI container everywhere. Well, I think there's one place that I have to fix in the IncomingRequest class, but that won't be there for much longer.

Redirects: if you don't want a function to be forced to redirect, then don't call the force_https() method. Calling the method immediately does a redirect, so that would be up to your app design to correctly. There's several different ways to restrict things (globally, per-controller, or using the force_https method manually), so no worries there.

And, yes, usability is a big concern, so I definitely appreciate seeing where people are concerned about it. Things will continue to improve in those areas, and a lot of times the things you might be concerned about are shown in their most flexible state, not the easiest, because the blogs are, in part, trying to show the flexibility and power available. I'll try and keep the simplicity in mind while writing the articles, too, so that it doesn't seem like it's growing that much more difficult. Because the 3 mantras I've tried to keep in mind have been simplicity, flexibility, and speed.
(03-10-2016, 09:55 AM)kilishan Wrote: [ -> ]...
I think a lot of that doesn't come through until you start playing with it.

Yes, and I have not done that. I've had some issues with installing PHP7, and just haven't taken the time to deal with it. Looking forward to playing around.
Pages: 1 2 3