Gaufrette
Gaufrette copied to clipboard
Get Filesystem root dir
It is often useful to be able to get root dir (Local and FTP adapters, directory property), but now it is possible only through Reflection API. What do you think guys, if I implement this? Maybe add a method getRootDir to Adapter interface and return null in adapters where root dir is unknown or is not relevant. Or add this method only to adapters where this makes sense (Local and FTP).
@wysow What do you think?
I would love to see this implemented. Any workaround?
+1.
A $adapter->getDirectory() would be great for the Local adapter at least. I need the directory where the file is being saved in my controller, but the path is set in config.yml. As far as I know, there's no other way to get the directory via the bundle? This is a easy thing to implement, but would it be merged quickly? There are 30 PR's waiting...
Edit: I'm using this via the KnpGaufretteBundle, hence the config.yml.
@akd3vs: I'm using reflection as a workaround for now:
$adapter = $filesystem->getAdapter();
$reflection = new \ReflectionClass($adapter);
$directory = $reflection->getProperty('directory');
$directory->setAccessible(true);
$path = $directory->getValue($adapter)
@akd3vs I also use reflection for this at the moment.
Thank you guys for the solution, I had to configure a parameter and I didn't like that.
@umpirsky What do you think?
@MAXakaWIZARD I am wondering what is the use case?
This will probably mean changing adapter interface which means new version, not sure.
So, what is the use case?
For me, I use it to get the path for the upload folder (which I set dynamically for different environments). I need the path in the controller to do operations on the image.
There are off course different ways to do this, but I like the idea of using the adapter, as that ensures me that the path I get is the same that the adapter uses.
@andreaslarssen If you use Symfony you can use kernel parameters for this, similar for other frameworks.
What do you think @akovalyov @docteurklein?
IMHO, you know the base directory of the local adapter, since you have to pass it in constructor already. So I don't see why introspection is needed here. Also, having this in the public API makes it quite a leaky abstraction.
Basically, you're asking:
$directory = '/base/path';
$local = new Gaufrette\Adapter\Local($directory);
// what is $directory?
So as @umpirsky says, you know the value already, otherwise you wouldn't be able to instanciate the local adapter.
Now I understand that having a getDirectory() method seems handy, but I'm not sure it worth polluting the API for the above reasons.
@umpirsky @docteurklein There definitely was a use case. Sorry, but I forgot exact details. I will try to dig it and come back. Thanks for your feedback!
@umpirsky. Not sure what you mean, do you have an example? I set the adapters in my config file, so don't have to set the directory every time I'm using it in my controllers.
@andreaslarssen If you put:
path.images: '%kernel.root_dir%/../web/media/image'
in parameters.yml, and you have:
knp_gaufrette:
adapters:
my_image:
local:
directory: %path.images%
in onfig.yml, you can do:
$this->getContainer()->getParameter('path.images');
in your controller to get base path instead getting it from adapter.
@umpirsky
Yes, I could off course do that and get the correct parameter based on the environment parameter. But it's a bit more hassle, a bit more code for every time I need it, and it also seems not to be "the correct" way to do it. I just think it would make more sense to get the path from the horses mouth aka. the adapter.
@andreaslarssen I see your point, it can be handy sometimes. But as @docteurklein said: "I'm not sure it is worth it".
@umpirsky. Ok, I've just glanced through the code. I can see that i takes some time if you need / want to add the method in the interface, but does all adapters even have a directory? My guess is no (haven't read through them), so adding a method to the local adapter returning $this->directory should do it? Am I missing something?
Anyways, it's not a must-have, but a really big nice-to-have. Either way, the lib is great.
@andreaslarssen Making it adapter specific (not part of adapter interface) is I am afraid not very useful, since it breaks the concept of filesystem abstraction. This means you are not working with abstraction any more, but concrete file system.
@umpirsky I see your point, and if that's something you want for the adapter, then I can see why you won't implement it.
@umpirsky I need to use it with LiipImagineBundle, having a dynamic way of getting the relative file path prevents me from changing different files if I thought the need to change the directory is important. Now Liipimagine filters need a relative path, so suggest a way I can prevent
- Changing directory path in multiple twig files
- Getting the filtered image from LiipImagineBundle, I sure need this more importantly
I hope you suggest a easy way. I don't have much time left to develop my Symfony site. And I get it, that this doesn't seem to be the SymfonyBundle repo to which my question is related, but I want this feature or there has to be a way to support third party libraries, abstraction or not.
@deviprsd21 I am afraid I didn't understand issue you are facing, but I guess you can keep filesystem root directory as parameter with the technique I described in https://github.com/KnpLabs/Gaufrette/issues/332#issuecomment-197744707.
LiipImagineBundle is the Image Processing bundle, and it works something like this {{ relative/path/to/img | imagine_filetr('thumbnail') }}, now I'm using one-up uploader for uploading and that bundle doesn't have a dynamic way of getting the relative path, so i made my own twig helper. Either way, there was the need for the exposure of the directory. Ofcourse we can use the parameter and all,but it is difficult with so much differences in so many bundles.
@deviprsd21 Hm, https://github.com/sylius/sylius/ uses Gaufrette and LiipImagineBundle, you can see how it is solved here without custom extension.
I'm not able to find the solution you suggested, can you show me exactly where it is in the project?
@deviprsd21 Both are used as you can see in https://github.com/Sylius/Sylius/blob/master/composer.json#L46-L49, and configured as you can see in https://github.com/Sylius/Sylius/blob/69848b37582f069d0f107b357db7fad6c896f140/src/Sylius/Bundle/CoreBundle/Resources/config/app/main.yml#L19-L43.
Imagine filters are used like in https://github.com/Sylius/Sylius/blob/d9533076fe607e11bc8da78ec189365f62149cb3/src/Sylius/Bundle/WebBundle/Resources/views/Frontend/Product/latestSidebar.html.twig#L7.
I don't see any issues.
I'm sorry, I was finding the exact solution, you gave it to me. And I got what has been done, the directories for both the bundle has been kept same.
Okay, after some testing and other stuff, I came to a conclusion that the way you suggested doesn't work for me, because Sylius has only one filesystem, adapter, etc. And I have multiple. What File object returns when getName() is called is the relative path to the root of the FileSystem.
So, if you want to maintain Abstraction, is there a way I can change the FileSystem of the current file so that I get the relative path according to the new FileSystem.
Like, with respect to OneupUploader, I have one FIleSystem at say %kernel.root_dir%/../web/ and another one at %kernel.root_dir%/../web/assets/img. Now, my LiipImagine is configured to %kernel.root_dir%/../web/, so it will require relative path to web directory but my FileSystem with the img directory as root will give relative path with respective to img directory. So, If I were able to change the current FileSystem to a Parent FileSystem, I guess it will solve my problem, also the probably the problem of not losing abstraction. What do you think @umpirsky?
@deviprsd21 You can have more then one Gaufrette filesystem and more then one imagine loader. That can solve your problem. One pair filesystem + loader per directory, right?
Looks like they support Gaufrette too, http://symfony.com/doc/master/bundles/LiipImagineBundle/data-loader/stream.html :smile:, Yeah now this solves a lot of problems, do you think this is worth documenting? Also, my suggestion was for request of exposing the directory, what do you think on that?
Something like this has been issued, https://github.com/liip/LiipImagineBundle/issues/592
@deviprsd21 I'm glad we solved your problem. :dart:
do you think this is worth documenting?
I think it is documented. :)
Also, my suggestion was for request of exposing the directory, what do you think on that?
Out of scope of this issue. :)