ZF2 "dispatch.pre"

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

ZF2 "dispatch.pre"

dolphin
Will there be in zf2 an event "dispatch.pre"?
I try to explain the meaning of the question. The fact is that when the controller performs "forward", then the main controller can be obtained as a target only after the additional is executed. However, in real-time as first will executed the main controller. That is, the chain of events does not correspond to the actual execution time.
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 "dispatch.pre"

galvao
There are actually 2 events that occur before the dispatch. See:
http://framework.zend.com/manual/2.2/en/modules/zend.mvc.mvc-event.html#order-of-events

Er Galvão Abbott

P.S.: Sorry, dolphin, replied directly to you by mistake)

On 01/24/2014 08:33 AM, dolphin wrote:

> Will there be in zf2 an event "dispatch.pre"?
> I try to explain the meaning of the question. The fact is that when the
> controller performs "forward", then the main controller can be obtained as a
> target only after the additional is executed. However, in real-time as first
> will executed the main controller. That is, the chain of events does not
> correspond to the actual execution time.
>
>
>
> --
> View this message in context:http://zend-framework-community.634137.n4.nabble.com/ZF2-dispatch-pre-tp4661523.html
> Sent from the Zend Framework mailing list archive at Nabble.com.
>


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 "dispatch.pre"

Antoine Hedgecock-2
You can always attach a callback with a higher priority!


On 24 Jan 2014, at 12:10, Er Galvao Abbott <[hidden email]> wrote:

> There are actually 2 events that occur before the dispatch. See: http://framework.zend.com/manual/2.2/en/modules/zend.mvc.mvc-event.html#order-of-events
>
> Er Galvão Abbott
>
> P.S.: Sorry, dolphin, replied directly to you by mistake)
>
> On 01/24/2014 08:33 AM, dolphin wrote:
>> Will there be in zf2 an event "dispatch.pre"?
>> I try to explain the meaning of the question. The fact is that when the
>> controller performs "forward", then the main controller can be obtained as a
>> target only after the additional is executed. However, in real-time as first
>> will executed the main controller. That is, the chain of events does not
>> correspond to the actual execution time.
>>
>>
>>
>> --
>> View this message in context:http://zend-framework-community.634137.n4.nabble.com/ZF2-dispatch-pre-tp4661523.html
>> Sent from the Zend Framework mailing list archive at Nabble.com.
>>
>
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 "dispatch.pre"

dolphin
In reply to this post by galvao
Yes, thank you , I know these events . But I meant something else.
At these events, another "target" - Application.
As I've said , "dispatch" in reality works as "dispatch.post".
So I have to create a "capture" method  for the event MvcEvent :: EVENT_ROUTE.
This method uses RouteMatch and ControllerManager  to pre-load the main controller .
So I can emulate event "dispatch.pre".
That is, my code does the same job as the framework. As a result - wet code, tangled code , low productivity .
It looks just awful. Events are designed to avoid this .
This is the reason for my interest.
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 "dispatch.pre"

Marco Pivetta
Can you please explain your use case? Why would you need another `.pre`
event? We already assured that it's a bad idea to have `.pre` and `.post`
events when we have priorities and can throw logic at a stack of listeners
instead...

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/


On 24 January 2014 13:20, dolphin <[hidden email]> wrote:

> Yes, thank you , I know these events . But I meant something else.
> At these events, another "target" - Application.
> As I've said , "dispatch" in reality works as "dispatch.post".
> So I have to create a "capture" method  for the event MvcEvent ::
> EVENT_ROUTE.
> This method uses RouteMatch and ControllerManager  to pre-load the main
> controller .
> So I can emulate event "dispatch.pre".
> That is, my code does the same job as the framework. As a result - wet
> code,
> tangled code , low productivity .
> It looks just awful. Events are designed to avoid this .
> This is the reason for my interest.
>
>
>
> --
> View this message in context:
> http://zend-framework-community.634137.n4.nabble.com/ZF2-dispatch-pre-tp4661523p4661525.html
> Sent from the Zend Framework mailing list archive at Nabble.com.
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 "dispatch.pre"

dolphin
My particular case is part of the business logic of my application. I do not know English well enough to explain how it works and why it is needed. But it is a very real case.
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 "dispatch.pre"

Marco Pivetta
Test case or it didn't happen. No english needed at all :-)

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/


On 24 January 2014 13:43, dolphin <[hidden email]> wrote:

> My particular case is part of the business logic of my application. I do
> not
> know English well enough to explain how it works and why it is needed. But
> it is a very real case.
>
>
>
> --
> View this message in context:
> http://zend-framework-community.634137.n4.nabble.com/ZF2-dispatch-pre-tp4661523p4661527.html
> Sent from the Zend Framework mailing list archive at Nabble.com.
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 "dispatch.pre"

dolphin
What do you think, I just like to come up with events that could exist in zf2?
I think if someone asks a question, this is necessary.
I would not be surprised if at some godforsaken forum hear "you do not need it." If you want me to not use zf2, say so now.
As for my case:
https://github.com/dphn/ScContent

Regardless of whether you like this code or not, it's part of the business logic of my system.


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 "dispatch.pre"

Marco Pivetta
On 24 January 2014 14:01, dolphin <[hidden email]> wrote:

> What do you think, I just like to come up with events that could exist in
> zf2?
>

No, I'm just asking for a more precise reason why such an event would exist.


> I think if someone asks a question, this is necessary.
> I would not be surprised if at some godforsaken forum hear "you do not need
> it."


Telling people YAGNI is pretty much 50% of my Github activity. I reject a
lot of pull requests, patches and feature requests because of that, and it
is a very important thing to do. Not everything should be accepted without
a good use case for it.


> If you want me to not use zf2, say so now.
>

Never said that, don't be so "defensive" - I'm just trying to destabilize
your theory that a new event is needed to see if you can actually see a
workaround to it


> As for my case:
> https://github.com/dphn/ScContent
>

Can you point me to the exact location where/why you'd need the event?


>
> Regardless of whether you like this code or not, it's part of the business

logic of my system.
>

It's not a matter of "liking" it or not. I just push my thought forward and
say "heeeyyy, wait a sec - maybe you can just re-think something?".


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 "dispatch.pre"

dolphin
I will try obsnit short sentences . So it will be clearer. Imagine that you are building a dynamic layout . Not like in zf1 (with helpers), but using "dispatch". You are using a theme. But not a single module , and a set . As Drupal . You have a theme for frontend .  You have a theme for the backend . And you have a theme for installation. Additionally there are modules widgets. Them too much.
Question: how to determine what as theme should be use at the moment?
I am repelled by the system that offers zf2 . It is ViewModel . It is "dispatch" method.
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 "dispatch.pre"

Marco Pivetta
The "Theme" would be the so-called layout, as far as I get it.
You can handle layout changes by either listening to the `dispatch` event
with very low priority (since theming should happen _AFTER_ dispatching) or
in the `render` event (with very high priority).

EdpModuleLayouts is a nice example of how that flexibility comes into place.

So now I'm wondering why you'd handle theming _before_ `dispatch` (in a
`dispatch.pre`)



Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/


On 24 January 2014 14:31, dolphin <[hidden email]> wrote:

> I will try obsnit short sentences . So it will be clearer. Imagine that you
> are building a dynamic layout . Not like in zf1 (with helpers), but using
> "dispatch". You are using a theme. But not a single module , and a set . As
> Drupal . You have a theme for frontend .  You have a theme for the backend
> .
> And you have a theme for installation. Additionally there are modules
> widgets. Them too much.
> Question: how to determine what as theme should be use at the moment?
> I am repelled by the system that offers zf2 . It is ViewModel . It is
> "dispatch" method.
>
>
>
> --
> View this message in context:
> http://zend-framework-community.634137.n4.nabble.com/ZF2-dispatch-pre-tp4661523p4661531.html
> Sent from the Zend Framework mailing list archive at Nabble.com.
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 "dispatch.pre"

dolphin
"Content" gives the main controller. He attaches the child model to Layout ViewModel as "content". Then automatically generated widgets. With the help of "forward". Theme detector should detect "dispatch" of main controller. All other "forward" - is the formation of widgets. The detector should only work once, for the main controller. And apply the theme. Backend theme. Or frontend theme...

But the biggest problems do not begin when the layout is generated automatically. They start when the main controller itself for any purpose carries "forward". This was not at all like to think ...
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 "dispatch.pre"

Marco Pivetta
On 24 January 2014 15:19, dolphin <[hidden email]> wrote:

> "Content" gives the main controller. He attaches the child model to Layout
> ViewModel as "content". Then automatically generated widgets. With the help
> of "forward". Theme detector should detect "dispatch" of main controller.
> All other "forward" - is the formation of widgets. The detector should only
> work once, for the main controller. And apply the theme. Backend theme. Or
> frontend theme...
>
> But the biggest problems do not begin when the layout is generated
> automatically. They start when the main controller itself for any purpose
> carries "forward". This was not at all like to think ...
>

 If I get it correctly, you are misusing "forward" to assemble a complex
view model. Doesn't seem like that's the right way to do it.

Also, can you provide some context/links to current code? It is really
really hard to follow your train of thought without some actual code
reference to who/what is doing things...

What exactly is the unexpected behavior that you are experiencing when
using the forward plugin? (also, I avoid it like the pest in most cases,
since it does a lot of pretty much useless magic)
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 "dispatch.pre"

franz de leon
@dolphin are you talking about this line of code when you are trying to
switch themes/templates if someone is an admin ?
https://github.com/dphn/ScContent/blob/master/src/ScContent/Listener/ConfigListenerAggregate.php#L98



On Fri, Jan 24, 2014 at 9:27 AM, Marco Pivetta <[hidden email]> wrote:

> On 24 January 2014 15:19, dolphin <[hidden email]> wrote:
>
> > "Content" gives the main controller. He attaches the child model to
> Layout
> > ViewModel as "content". Then automatically generated widgets. With the
> help
> > of "forward". Theme detector should detect "dispatch" of main controller.
> > All other "forward" - is the formation of widgets. The detector should
> only
> > work once, for the main controller. And apply the theme. Backend theme.
> Or
> > frontend theme...
> >
> > But the biggest problems do not begin when the layout is generated
> > automatically. They start when the main controller itself for any purpose
> > carries "forward". This was not at all like to think ...
> >
>
>  If I get it correctly, you are misusing "forward" to assemble a complex
> view model. Doesn't seem like that's the right way to do it.
>
> Also, can you provide some context/links to current code? It is really
> really hard to follow your train of thought without some actual code
> reference to who/what is doing things...
>
> What exactly is the unexpected behavior that you are experiencing when
> using the forward plugin? (also, I avoid it like the pest in most cases,
> since it does a lot of pretty much useless magic)
>
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 "dispatch.pre"

dolphin
This post was updated on .
No, absolutely not. This kind of hack for zfcuser. You can talk a lot about the advantages and disadvantages of any method. Just try to install it with the help of composer and you will be able to see a what I seek (and which has already achieved). Do you disappear all the questions. With the helper can not do this.

https://github.com/dphn/ScWidgets

P.S.: Do not be offended, but static layouts is high time to forget, like a bad dream. Who wants half a year to learn a complex code to display a static layout? Who will assess your RESTFUL application if it can not even what can wordpress? If the system does not have enough flexibility, it is impossible to sell. People are spoiled for WordPress, Joomla, Drupal, etc. Especially because zf2 has everything you need.

P.S.2: As for use case:
https://github.com/dphn/ScContent/blob/master/src/ScContent/Listener/Theme/ThemeContext.php#L39
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 "dispatch.pre"

Stefano Torresi
In reply to this post by Antoine Hedgecock-2
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 "dispatch.pre"

dolphin
This post was updated on .
Thank you, I believe any information useful.
Of course, it is better to see once than hear a hundred times. But in short, is not a choice layout, but choice of strategy.
The strategy includes
- Choice of theme
- Choice of template
- Choice of layout
- Forming regions depending on the chosen theme
- Formation of widgets depending on the chosen theme
Because the module uses nested sets, it allows to inherit some of the parameters for widgets depending on specified content and the chosen theme

Regarding the use of VM + HMVC ... This works rather well :)
I would say, compared to zf1, zf2 solves it brilliantly. Although it seems this decision is not yet very popular.

@Stefano Torresi
Thank you for your help. I came to the conclusion that for these purposes it is better to use SharedListenerAggregateInterface and slightly changed the principle of "target capture". Yes, indeed, if you use a higher priority and Shared Manager, it works similarly to "dispatch.pre". This is a good solution for VM + HMVC. Thanks again.