FuelPHP Forums

Muzikman

Greetings, Is it possible, with the existing core framework, to initiate an external HTTP Get Request as a Client using the standard Request and/or Response objects? I know I saw some mention of Curl in the API reference but I am looking for something that is more native to Fuel. Any such luck? Matt

Peter

Hi Matt, I think you want this:

$url = 'http://www.mywebsite.com/mypage.html';
$data = \Request::forge($url, 'curl')->execute()->response();

You are correct that this is not in the docs.

Harro

I've created an issue on github for the missing documentation.

Muzikman

Indeed I do! Thanks. Been trying to figure out how to do initiate this. I have a PHP wrapper for theonlineMovieDB.com. Question while I have you here. Since I'm quite new to the implementation of frameworks, should I keep these native PHP wrappers, well, native.

and build a module with them? I don't think they'll be of any use to anyone on here unless they plan to build a movie review site. However, portable to me.

Muzikman

How is this piece code above different from the Fuel\Core\ \Request\Curl driver?

Harro

Which piece of code? \Request::forge($url, 'curl') loads the Request_Curl driver class...

Muzikman

Yes, that one.

Muzikman

Oh, I just figured it was a sub-class of sorts. Ok, so now I get it.

Harro

A lot of the core classes with with driver classes behind the scenes, either to create instances in a multiton pattern, or to provide the correct driver based on config or the parameters of the forge request. Session, File and Config are similar in setup to Request.

Muzikman

While I was browsing through the core driver class curl, I didn't see many options to configure the curt parameters. Would those be included in a curl.php config file or something?

Muzikman

Let me see if I understand this correctly. namespace Fuel\Core //The Request class has a driver named 'curl' which is a parameter to the forge() method. $response = \Request::forge($url, 'curl', optional method)->execute()->response(); So, my response object is populated with the JSON string from the API call. I am not going to need to forge a view because the user will never interact with this part of the application. It's basically to make concurrent requests and pre-populate the database. Question is this, how do I access the http_status_code via curl and/or any exception handing?
Now, is there a way that I can run this application via CLI with OIL?

Harro

Correct. reponse() will return a standard FuelPHP Response object. You can access the status using $response->status, you can get any HTTP headers returned using $response->get_headers(), and the response payload using $response->body(). You have to enclose the call in a try/catch block if you want to handle any exceptions generated by the request. You can run this through Oil using the console (you type the command in interactively), or through a task you run of the commandline. If you have code that you need both in a task and in a controller, create a separate class for it that you call from both.

Muzikman

Ahh.... Makes perfect sense. How would I go about adding curl constant, etc? Through an array of params?

Harro

Muzikman wrote on Sunday 15th of July 2012:

Ahh.... Makes perfect sense. How would I go about adding curl constant, etc? Through an array of params?

One instantiated you can use set_option() to define curl options:

// example from the login method
$this->set_option(CURLOPT_USERPWD, $username . ':' . $password);

alternatively, you can use set_options() to pass an array of options all at once, and use options() to retrieve set options.

Harro

Muzikman wrote on Sunday 15th of July 2012:

I am new to the concept of a "driver" when it comes to frameworks. Can you give me a definition in your own words that would help clarify it a bit for me?

In normal circumstances a forge() returns an instance of itself. In the case of drivers the main class has driver classes, and based on the configuration you pass when you forge an instance you'll get an instance of a specific driver class returned instead of the main class. Take for example Session. It has driver classes for File, DB, Memcached, Redis and cookies, to support the different session storage backend through a unified API.

Muzikman

I gotcha. That's why I need to pass the "driver" name of the main class as a parameter to forge. Basically, "forge" an instance of the 'curl" via the main class calling "forge" directly?

Muzikman

Maybe a good "first" project with Fuel would be to use the Fuel core to build the API calls instead of wrapping this native PHP class. Question: When developing a third party driver or module, is it good practice to get the module operational before implementing the separate controller and model?

Harro

Muzikman wrote on Sunday 15th of July 2012:

I gotcha. That's why I need to pass the "driver" name of the main class as a parameter to forge. Basically, "forge" an instance of the 'curl" via the main class calling "forge" directly?

Correct. And as Curl and Soap support were a bit of an afterthought they were bolted on later, and the second parameter is "mis-used" to indicate the driver name. This will be addressed in 2.0, we can't change the API of 1.x.

Harro

Muzikman wrote on Sunday 15th of July 2012:

Maybe a good "first" project with Fuel would be to use the Fuel core to build the API calls instead of wrapping this native PHP class.

Not sure what you mean by this.

Muzikman wrote on Sunday 15th of July 2012:

Question: When developing a third party driver or module, is it good practice to get the module operational before implementing the separate controller and model?

Same here. A module is a (logical separate) part of the application, which contains "front-end" code, like controllers, models and views. A driver is more of a back-end concept for libraries or core classes.

Muzikman

I couldn't resist and had to poke under the hood into the core classes. I should learn to leave well enough alone and allow the encapsulation serve it's purpose. I didn't notice that the driver classes are abstract which explains a lot.

Muzikman

I have a set of PHP classes in order to interact with one online movie provider. People offer their libraries for other's to use. Anyway, should I implement it as is or take the native PHP libraries and extend Fuel? Make sense? Here's the problem I'm encountering. It's difficult to differentiate when to use raw PHP or Fuel implementations because Fuel has already dealt with the core PHP aspect in so many words. So, if I build my own class, will it be utilizing pure PHP or Fuel PHP? Mix and match?

Muzikman

It is my understanding that a driver is a way to encapsulate a specific native PHP feature into the framework core. Is this correct? Even though Curl is it's own request class, they all extended the abstract driver class. The parent request class just extends the namespace in many cases to offer the lazy loading I would imagine. I mean, something needs to be extended on startup or nothing will load.

Muzikman

I'm starting to understand the Framework. The main Request (request.php) object is always loaded and because of this, we can load anything within the name space by "forging" an instance so to speak. The Request_Curl class is one of the few that has an actual contstructor. This class has the basic curl settings in order for it to function. If the user decides to add more functionality to it, they need to pass the appropriate config params, etc.... The encapsulation allows the developer to pass on generic/forged parameters to it such by using CURL_ (append generic string), etc...... It would be nice to remove any mention of curl in the forge request, etc... I'm sure you're aware of that.

Muzikman

While implementing my Movie Mashing API with Fuel, I wanted some direction in the actual design not implementation. For instance, here's the scenario: 1. I will be pre-populating a local DB with data from several online movie API providers. MovieDB, IMDB, Netflix, etc..... This is where the abstraction needs to come into play. 2. Each of these "Provider" objects has a different API technology. MovieDB utilizes REST/JSON, Netflix uses oData/Atom, etc.... 3. Each provider will have their own initial configuration params such as URI, Endpoint (depending on the service), API KEY and some require you to pass an base 64 encoded hash in the URL. I'm not using oAuth because I do not need to log in as another user, etc... In all actuality, I could implement a pure/generic client API abstraction layer which would cover the mashing of any type of provider API but I don't have the time for that. So, for this project, it will be mashing several APIs, different technologies, same "Provider" type of Movie Provider.
Should I just build a completely separate web application with Fuel which will cater to this aspect? Create a package, module? I'm looking more for guidance on work flow and biz logic. Keep in mind, that there is the possibility that I could have the need to use this with another PHP based framework.

Harro

If it has to be framework agnostic I would suggest making it PSR-0/PSR-1 compliant, and don't create any dependencies to the framework other then through a driver class/DiC (so you can abstract the framework specifics).

Muzikman

That's what I figured. The driver is an abstract "interface" so to speak into the framework core, correct?

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.

Howdy, Stranger!

Categories

In this Discussion