On Mon, Aug 20, 2012 at 9:33 AM, Matthew Weier O'Phinney
<
[hidden email]> wrote:
> Documenting array arguments is hard, and validating them introduces a
> lot of complexity. Having an explicit argument for the identifier is
> necessary here so that (a) it's self-documenting, (b) it's
> self-validating, and (c) it ensures differentiation between regular EM
> and SEM usage -- this latter helps you identify errors easier (missing
> arguments when using the SEM).
I agree explicit is always better. I have previously asked considering
moving the identifier to the end of the method argument list.
In regards to differentiation between a regular EM and an SEM, that's
where I cannot change the implementation of the SEM because of its
Interface.
What if I do want to emulate a regular EM as an SEM? You're telling me it can't.
I must be the only one it seems to just want a simple interface that
would require little to no explanation.
Anyhow...
>
> It's not, though. The CallbackHandler does not store the identifier, and
> should not, as it can be attached separately to multiple events and
> identifiers. As such, the signature on the SEM requires having an
> identifier -- and, again, this helps you with contextual debugging.
I apologize if I'm just an idiot, especially as I'm stalling from
running the code, however:
$listeners[] = $this->identifiers[$id]->attach($event, $callback, $priority)
For each identifier a new CallbackHandler is being created and
assigned to a particular identifier.
Couldn't spl_object_hash of this new CallbackHandler could be used to
determine which identifier it was attached to?
>
>> Otherwise I think I would like to see an Event Manager that can pull
>> event listeners (or aggregates) from a service locator based on the
>> event 'name' being the service listener alias, by default in ZF2?
>
> Sorry, don't quite understand what you're requesting. Can you show me
> some pseudo-code indicating what you'd like to do?
$em->trigger('member.create');
This in effect could replace a concrete service method entirely. All
the default listeners would be pulled from the service locator config.
For example
public function bootstrap()
{
$serviceManager = $this->serviceManager;
$events = $this->getEventManager();
//$events->attach($serviceManager->get('RouteListener'));
//$events->attach($serviceManager->get('DispatchListener'));
//$events->attach($serviceManager->get('ViewManager'));
// Setup MVC Event
$this->event = $event = new MvcEvent();
$event->setTarget($this);
$event->setApplication($this)
->setRequest($this->getRequest())
->setResponse($this->getResponse())
->setRouter($serviceManager->get('Router'));
// Trigger bootstrap events
$events->trigger(MvcEvent::EVENT_BOOTSTRAP, $event);
return $this;
}
E.g
$em = $this->getEventManager() //whatever this means.
$em->trigger('mvc.bootstrap', $event);
The Event Manager will pull all the listeners for 'mvc.bootstrap' and
trigger them. There would be no need to attachDefaultListeners(), and
it would be easy to add, remove or manage their priority via
configuration files and the EM would not need to be pre-initialized in
order to do so?
Basically I might like to have service object that with a concrete
method that would just trigger the event:
MemberService::createMember($member)
{
$em = $this->getEventManager(); //This is a shared event manager..
because it means less boiler plate code, e.g setEventManager +
identifiers.
$em->trigger('member.create', $member);
}
Otherwise, its seems, you're forcing us to worry about identifiers,
when for the most part I don't want or need to (and others will
definitely not care), and really forcing one particular type of
implementation of a Shared Manager - Why couldn't a regular EM be used
as an SEM and let the developer have the opportunity to handle their
own implementation for integration with the ServiceManager (unless its
in Zend by default)?
--
Greg
Locked
