I'm trying to allow an user to do something like response()->yaml(['their content']), but I don't understand how I'd go on injecting my YAML method to the response() (ResponseFactory) facade.
Is there any guide that would explain on how to do this? Or maybe a quick description from someone? This is the first time I'm trying to build a package for Laravel and it will also be open source!
I checked out this question, but unfortunately I don't see its use case and I don't think it focuses on adding an additional method which would be called via response().
You can you use Response Macros to achieve your aim.
In the boot method of your AppServiceProvider (or in the package ServiceProvider) add the following:
Response::macro('yaml', function ($content) {
return yaml_whatever($content); //Use your implementaion here
});
Now, you can use return response()->yaml($content);
Related
please can anyone help me understand what a macro is in Laravel Macroable trait, reading this documentation https://laravel.com/api/5.4/Illuminate/Support/Traits/Macroable.html only tells me how to use but why do I use it, what is it meant for.
It is for adding functionality to a class dynamically at run time.
use Illuminate\Support\Collection;
Collection::macro('someMethod', function ($arg1 = 1, $arg2 = 1) {
return $this->count() + $arg1 + $arg2;
});
$coll = new Collection([1, 2, 3]);
echo $coll->someMethod(1, 2);
// 6 = 3 + (1 + 2)
echo $coll->someMethod();
// 5 = 3 + (1 + 1)
We have 'macroed' some functionality to the Collection class under the name someMethod. We can now call this method on the Collection class and use its functionality.
We just added a method to the class that didn't exist before without having to touch any source files.
For more detail of what is going on, please check out my article on Macros in Laravel:
asklagbox - blog - Laravel Macros
It allows you to add new functions. One call to ::macro adds one new function. This can be done on those of the internal framework classes which are Macroable.
This action of adding the function to the class is done at run time. Note there was/is an already existing perfectly good name for this action, which isn't the word "macro", which I'll explain at the end of this post.
Q. Why would you do this?
A. If you find yourself juggling with these internal classes, like
request & response, adding a function to them might make your code more
readable.
But as always there is a complexity cost in any
abstraction, so only do it if you feel pain.
This article contains a list of the classes you can add functions to using the static call "::macro"
Try not to swallow the word macro though, if you read that article - if you're like me it will give you big indigestion.
So, let's now add one extra function to an internal framework class. Here is the example I have just implemented:
RedirectResponse::macro('withoutQuery', function() {
return redirect()->to(explode('?', url()->previous())[0]);
});
This enables me in a controller to do this:
redirect()->back()->withoutQuery();
(You can just do back() but I added redirect() to make it clear).
This example is to redirect back and where the previous route was something like:
http://myapp.com/home?something=something-else
this function removes the part after '?', to redirect to simply:
http://myapp.com/home
I did not have to code it this way. Indeed another other way to achieve this is for me to put the following function in the base class which all controllers inherit from (App\Http\Controllers\Controller).
public function redirectBackWithoutQuery()
{
return redirect()->to(explode('?',url()->previous())[0]);
}
That means I can in any controller do this:
return $this->redirectBackWithoutQuery();
So in this case the "macro" lets you pretend that your new function is part of an internal framework class, in this case the Illuminate/RedirectResponse class.
Personally I like you found it hard to grasp "laravel macros". I thought that because of the name they were something mysterious.
The first point is you may not need them often.
The second point is the choice of the name ::macro to mean "add a function to a class"
What is a real macro?
A true macro is a concept unique to Lisp. A macro is like a function but it builds and returns actual code which is then executed. It is possible to write a function in other languages which returns a string which you then execute as if it was code, and that would be pretty much the same thing. However if you think about it you have all of the syntax to deal with when you do that. Lisp code is actually structured in lists. A comparison might be imagine if javascript was all written as actual json. Then you could write javascript, which was json, which returned json, which the macro would then just execute. But lisp is a lot simpler than json in terms of its syntax so it is a lot easier than what you just imagined. So, a true lisp macro is one of the most beautiful and amazing things you can encounter.
So why are these add-a-function things in laravel called macros?
That's unknown to me I'm afraid, you'd have to ask the author, but I asked myself what they really do and is there already a name for that.
Monkey Patches
TL;DR laravel's ::macro could more accurately be described as monkey patch
So if using laravel ::macro calls, I personally decided to create a MonkeyPatchServiceProvider and put them all there, to reduce unnecessary confusion for myself.
I realise the name might sound a bit derogatory, but that's not intended at all.
It's simply because there's already a name for this, and we have so much terminology to deal with why not use an existing name.
In general there are ActionController, Repositories, Models und Views in TYPO3 Flows domain driven MVC system. In our project we use a general File model that contains the Ressource.
Now we need a special "expert" php script like an action controller that doesn't listen to certain url actions. It should get such a File object, do something internal like logging stuff or manipulate the object after a special procedure and give back an information / return falue.
What mvc thing I need for that? An interface? A manager? How you call that and how do I initialise it in TYPO3 Flow? Or is the FileController (action controller) exact the thing I have to use for that?
This "expert" shouldn't listen to url actions but should be used like an action controller like
$expertyThing = new ../../Expertything();
$expertyThing->doCoolStuff($file);
and should can use thinks like the PersistenceManager (by injection or anyhow).
Thanks for any input for that.
I would say Service but I'm not sure if I understood you correctly.
I guess you have some FileController and you have createFileAction there, which creates new File model from uploaded resource, do some validation, transformations, renaming and save it using injected FileRepository.. And you want something in middle.
So I create FileService for that My/FileManager/Domain/Service/FileService.php - inject repository and other services there. And in action or command controllers I inject those services and they do "expert" stuff (and I don't have to duplicate code), like that:
// FileController
public function createFileAction(Resource $resource) {
try {
$file = $this->fileService->processAndSaveFile($resource);
} catch (\Exception $e) {
$this->addFlashMessage($e->getMessage(), '', Message::SEVERITY_ERROR);
$this->forwardToReferringRequest();
}
$this->addFlashMessage('File created');
$this->redirect('fileList');
}
So for me FileService do expert stuff for File - it creates new File model (maybe using FileFactory), do transformations using other services like ImageService, has repository and logger injected (but you can use Aspects for cases like logging).. and if something goes wrong it throws some FileException.
And of course FileService may implement some FileServiceInterface, and you can inject this interface to your controller and define in Objects.yaml which service should be used (it makes it more flexible, so someone else could implement it and replace your FileService not touching it).
This "Service" approach may be a little bit outdated, so maybe someone will suggest better solution.. If you want follow Flow rules, just check how they handle stuff like that in official packages.
I'm trying to use $input->all() as opposed to Input::all() in Laravel-5, however it doesn't seem to like it, even though I am passing the Input reference to the function, like so:
/**
* Search for a specified resource.
*
* #return Response
*/
public function search(Booking $booking, Input $input)
{
dd($input->all()); // this doesn't work
dd(Input::all()); // this DOES work
}
The error I get is:
Call to undefined method Illuminate\Support\Facades\Input::all()
Does anyone have a solution to this problem?
I don't think you're supposed to inject Facades into your Controllers. Input is a facade for Illuminate\Http\Request and it's service container binding is request. So according to the documentation, in Laravel 5 you can do Request::all() and in Laravel 5.1 you can do $request->all()
http://laravel.com/docs/5.0/requests#retrieving-input
http://laravel.com/docs/5.1/requests#retrieving-input
EDIT: This post gives some more in-depth information: https://stackoverflow.com/a/29961400/2433843
EDIT3: I think it would be great if someone could explain WHY exactly you can't inject Facades into your Controllers. I understand DI and Facades are two different things entirely, and L5+ is pushing the developers towards DI. I just don't exactly understand why injecting a facade wouldn't work, since it points towards another class, and it works when you do not inject it. Not to forget Facades and Aliases are two seperate things too. I hope someone can elaborate on this.
One more important thing about using Request or Input to access the User Input is the version of Laravel that you are using.
In the Laravel 4.2 and prior, you could have access the Input::all(), Input::get() but from Laravel 5 onwards, it's been suggested to use the Input via Request facade
Ref: https://laravel.com/docs/5.2/requests
In case if you want to make use of Input in Laravel 5.0 and onwards, then you need to add this facade in the config/app.php file under the aliases section as 'Input' => Illuminate\Support\Facades\Input::class
Once you add the facade under alias, you should start using the 'Input::all()'
Hope this helps some others, who are having the confusion as whether to use 'Input' or 'Request' for Laravel 5.0 onwards.
Rather than using controller/action/key1/value1/key2/value2 as my URL, I'd like to use controller/action/value1/value2. I think I could do this by defining a custom route in my Bootstrap class, but I want my entire application to behave this way, so adding a custom route for each action is out of the question.
Is this possible? If so, how would I then access valueN? I'd like to be able to define the parameters in my action method's signature. e.x.:
// PostsController.php
public function view($postID) {
echo 'post ID: ' . $postID;
}
I'm using Zend Framework 1.9.3
Thanks!
While I don't think it's possible with the current router to allow N values (a fixed number would work) you could write a custom router that would do it for you.
I would question this approach, however, and suggest that actually listing all of your routes won't take long and will be easier in the long run. A route designed as you've suggested would mean that either your named parameters are always in the same order, i.e.
/controller/action/id/title/colour
or that they are almost anonymous
/controller/action/value1/value2/value3
With code like
$this->getRequest()->getParam('value2'); //fairly meaningless
Does it have to be N or can you say some finite value? For instance can you imagine that you'll never need more than say 5 params? If so you can set up a route:
/:controller/:action/:param0/:param1/:param2/:param3/:param4
Which will work even if you don't specify all 5 params for every action. If you ever need 6 somewhere else you can just add another /:paramN onto the route.
Another solution I've worked with before is to write a plugin which parses the REQUEST_URI and puts all the extra params in the request object in the dispatchLoopStartup() method. I like the first method better as it makes it more obvious where the params are coming from.
I'm making an AJAX call in my symfony project, so it has an sf_format of 'js'. In the actionSuccess.js.php view, I call get_partial to update the content on the page. By default it looks for the partial in 'js' format since the sf_format is still set as 'js'. Is it possible to override the sf_format so that it uses the regular 'html' partial that I already have (so that I don't have to have two identical partials)?
I have had a similar issue.
I looked through the code, and get_partial doesn't give you any scope to change the format looked for ... guess you could modify the code to make that possible if you needed to.
I instead went for switching the request format - also not ideal in my opinion. But better than editing the symfony files.
To do this in the controller:
$request->setRequestFormat('html');
or in the view
$sf_context->getRequest()->setRequestFormat('html');
In both cases, if you want to set this back afterwards, you can retrieve the existing value using getRequestFormat().
if your looking for a more sustainable solution, you could listen to the view.configure_format and set the sfPHPView extension in your appflication configuration.
// in apps/api/config/apiConfiguration.class.php
public function configure() {
$this->dispatcher->connect('view.configure_format', array($this, 'configure_formats'));
}
public function configure_formats(sfEvent $event) {
// change extension, so our module templates and partials
// for xml do not need the .xml.php extension
$event->getSubject()->setExtension('.php');
}