Hi tamcy,
I read your email some time ago about this problem. I'm
aware that the
current solution is not perfect. Here is my thoughts about
your solution:
- I like your solution with a first, middle and last
position (as we
already have the same concept for ordering javascripts and
stylesheets).
No need to add  before (hmm, ah ok, only we don't
implement dependencies)
- I don't like the > and < (because of performance
impact - just an
intuition here, complexity in the core to deal with it, and
dependence
between filters)
- If the order is not the same for the 2 filter chains
(beforeExecution
and beforeRendering), it means you will have to register
your filter 2
times? So, we need yet another parameter in the filter.yml
configuration
file. I think it is better to have 2 filters then.
I have introduced some time ago the concept of
beforeExecution and
beforeRendering just as a mean to clarify/simplify how to
register
filters before execution and after execution (before
rendering). I want
to remove these 2 methods now and revert to a single
execute() method
because it is unnecessary, thanks to the way chaining works:
Here is how filters are executed:
In Filter chain:
- Filter 1:
- ->execute()
- some code (filter 1)
- $filterChain->execute()
- Filter 2:
- ->execute()
- some code (filter 2)
- $filterChain->execute()
- some code (filter 2)
- some code (filter 1)
If symfony register the rendering filter as the very first
filter and
execution filter as the very last filter, a filter can do
some things
before execution by providing code before the
$filterChain->execute()
call and do some other things before rendering after this
call:
In Filter chain:
- Filter 1:
- ->execute()
- some code (filter 1 - before execution)
- $filterChain->execute()
- Filter 2:
- ->execute()
- some code (filter 2 - before execution)
- $filterChain->execute()
- some code (filter 2 - before rendering)
- some code (filter 1 - before rendering)
I think it explains more clearly why filters are executed in
reverse
after execution.
Fabien
tamcy wrote:
> Hi devs,
>
> Two weeks before I asked about the intention of the way
filtechain
> currently works and got no answer. I want to further
elaborate the
> issue and hope there will be feedback.
>
> My last post said I am concerned because I have a
filter that need to
> add javascript/stylesheet inclusion in
onBeforeRendering, which is
> essential because I have to get the rendered page. But
I found it to
> be executed after sfCommonFilter, which is where the
sfResponse got
> initialized.
>
> This problem, coupled with another already fixed but
filter-chain
> order related issue makes me think if there is any
better way. I come
> up with a sfFilterChain that keeps two linklists - the
"execution"
> linklist and the "render" (or before_render)
linklist. Unlike the
> current solution, the ordering of two linklists are
independent. Each
> linklist is orgainzed into three (virtual) sections:
> [ first ] [ middle ] [ last ]
>
> When no specific ordering information is specified, all
filter will go
> to the "middle" section by default. To
maximize BC (although I don't
> think there's a need), append filter after the last
filter in the
> middle section in "execute" mode, and put the
filter before the first
> filter in the section in "render" mode.
>
> Programmer can enforce the position of a filter by (in
filters.yml)
>
> myFilter:
> class: myFilterClass
> position: first
>
> This makes the filter be appear at the [first] section.
Also,
> {position: last} makes the filter executed lastly.
Although they are
> not neccessary the "firstmost" or the, uh,
"lastmost" to be executed,
> this seperates them from the filters at [middle]
section.
>
> And filter position can also be determined relatively.
For example,
> {position: <myAnotherFilter} makes myFilter executes
before
> myAnotherFilter, and {position: >myAnotherFilter}
makes myFilter
> executes after myAnotherFilter. As of first and
last, this doesn't
> guarentee myFilter to be neccessary immediately before
or after
> myAnotherFilter.
>
> I am curious about the thoughts of people here. If the
devs are
> already working on a better idea, please tell me.
>
> Almost immediately I think of the performance impact
with this idea,
> although no stats can be given. Making it a plugin is a
good idea, but
> under the curren project status, this implies copying
many codes from
> the forward method in sfController just to rename a
class name, and
> maybe some lines of code.
>
> Please don't hesistate to tell me if this is really bad
>
> Tamcy
>
> --
> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
> For additional commands, e-mail: dev-helpsymfony-project.com
>
>
>
--
To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
For additional commands, e-mail: dev-helpsymfony-project.com
|