You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey @makasim, I'm just dropping a huge load of my re-factoring in favor of a more elegant version. Let me describe, what I'm up to, and let me know, what you think about it.
I was going through the configuration options of this bundle, and was thinking how to have a more dynamic way of describing its content. Many options have been added from time to time and are bound to a specific implementation of some part of the bundle (e.g. web_root for the WebPathResolver, data_root for the FilesystemLoader etc.). This will be cleaned up later on.
The configuration shows clearly that there are actually two parts to describe: a FilterSet and a Filter.
A FilterSet is described by those attributes:
its id (a unique name/identifier)
a Liip\ImagineBundle\Imagine\Data\Loader\LoaderInterface
a Liip\ImagineBundle\Imagine\Cache\Resolver\ResolverInterface
a Filter
A Filter in regards to the FilterSet is described by:
its id (a unique name/identifier)
a set of specific options (key-value)
an actual filter to apply Imagine\Filter\FilterInterface
The filter is bound to an imagine filter, which is fine as this filter is just working as a controller on it.
Imagine provides the Imagine\Filter\Transformation, a similar implementation would be required to have a collection of Filter be used as a Filter itself within the FilterSet.
The Filter extends the Imagine\Filter\FilterInterface with the configuration step (similar to the current Liip\ImagineBundle\Imagine\Filter\Loader\LoaderInterface). However I want to remove the requirement of a loader for filters without options, like the Imagine\Filter\Basic\Strip.
The text was updated successfully, but these errors were encountered:
I read it briefly and dont understand it much. I would try to reread it today in the evening, you think you could re-phrase it somehow it would be good.
The former FilterSet now is a Liip\ImagineBundle\Model\Filter\Configuration.
The filter loader have been moved into Liip\ImagineBundle\Imagine\Filter namespace and implement the Liip\ImagineBundle\Model\Filter\ConfigurableFilterInterface. All basic Imagine filter (applicable without configuration) can be used as it.
Hope the code tells it a bit better than my initial description :)
see #288
Hey @makasim, I'm just dropping a huge load of my re-factoring in favor of a more elegant version. Let me describe, what I'm up to, and let me know, what you think about it.
I was going through the configuration options of this bundle, and was thinking how to have a more dynamic way of describing its content. Many options have been added from time to time and are bound to a specific implementation of some part of the bundle (e.g.
web_root
for theWebPathResolver
,data_root
for theFilesystemLoader
etc.). This will be cleaned up later on.The configuration shows clearly that there are actually two parts to describe: a
FilterSet
and aFilter
.A
FilterSet
is described by those attributes:Liip\ImagineBundle\Imagine\Data\Loader\LoaderInterface
Liip\ImagineBundle\Imagine\Cache\Resolver\ResolverInterface
Filter
A
Filter
in regards to theFilterSet
is described by:Imagine\Filter\FilterInterface
The filter is bound to an imagine filter, which is fine as this filter is just working as a controller on it.
Imagine provides the
Imagine\Filter\Transformation
, a similar implementation would be required to have a collection ofFilter
be used as aFilter
itself within theFilterSet
.The
Filter
extends theImagine\Filter\FilterInterface
with the configuration step (similar to the currentLiip\ImagineBundle\Imagine\Filter\Loader\LoaderInterface
). However I want to remove the requirement of a loader for filters without options, like theImagine\Filter\Basic\Strip
.The text was updated successfully, but these errors were encountered: