Hi everyone,

When I wrote the refactor of the event manager for ZF3, the shared event manager was the point that prevented me of doing more heavy optimizations, because of all the merging and sorting involved because of the shared manager.

Then, I've looked at a lot of other PHP implementations, and none of them had such a concept. I also have a deeper look about how other languages native event implementation worked. More specifically about C++ and C# (because I knew them). The result is that none of those languages have a concept of shared event manager.

I'm not saying shared event manager, but rather try to open a discussion about why we may be wrong.

If you look at it, the main reasons of a shared event manager is:

• To allow attach listeners to objects that are not created yet.
• Allow to attach listeners to a set of events that may come from different sources using identifiers.

However, I think that most of those problems could be alleviated. The current way of registering events is, most often, attaching listeners in the Module class:

public function bootstrap(Event $event)
{
    $sm  = $event->getTarget()->getServiceManager();
    $evm = $event->getTarget()->getEventManager();

    $listenerAggregate = $sm->get('Application\Listener\UserListener');
    $evm->attach($listenerAggregate);
}

This means we are creating a listener aggregate, and attach it to a shared event manager because the user service does not exist yet (and may never depending on the request). We are doing useless binding of events in some cases, and the fact that the shared event manager is slow make it even harder.

A more correct way would be, to my opinion, to bind the 'Application\Listener\UserListener' ONCE the UserService is instantiated. Because the UserService is instantiated, listeners can be directly attached to the event manager of the user service, hence removing the need of a shared event manager completely.

One naïve solution (that works in some case) was to say: "attach events in the user service factory":

class UserServiceFactory implements FactoryInterface
{
    public function createService($sm)
    {
        $listener    = $sm->get('Application\Listener\UserListener');
        $userService = new UserService();
        $eventManager = $userService->getEventManager();
        $eventManager->attach($listener);

        return $userService;
    }
}

However, this does not scale well because it ties your code to other modules. Therefore, I thought about another way to tackle this problem: using listeners configuration.

Config of the above example:

return [
    'listeners' => [
        'User\Service\UserService' => [
            // If it is a listener aggregate, then binding to events is done in the attachListeners
            'Application\Listener\UserListener',

            // Otherwise we can attach methods if not aggregate
            'user.created' => [
                ['Application\Job\CreateRole', 'createRole']
            ]
        ]
    ]
];

Basically, instead of creating the listeners in the Module.php, listeners are just specified in a config file and NOT created until really needed. We could thought about an annotation syntax too:

If ListenerAggregate:

/**
 * @Listener(class="User\Service\UserService")
 */
class UserListener implements ListenerAggregate

Now the question is: how would the mapping be done? Well, the solution would be to provide a trait that would extract the listeners from config, and add them:

trait AttachListenerTrait
{
    public function attachListeners($evm, $sm)
    {
        // We would likely have a ZF3 service that would extract events from
        // annotation and config. All the listeners would be fetched from the
        // service manager, and attach to the EVM
    }
}

Then, our factory of the UserService would become:

class UserServiceFactory implements FactoryInterface
{
    use AttachListenerTrait;

    public function createService($sm)
    {
        $userService = new UserService();
        $this->attachListeners($userService->getEventManager(), $sm);

        return $userService;
    }
}

What do you think?

Heya people

After a rather interesting discussion in #5156 many people tend to agree that having the AbstractController implement the ServiceLocatorAwareInterface is a bad idea since it allows for poor practise.

Yes, it can be convenient at times but it's used far too carelessly. Removing the ServiceLocatorAwareInterface we can "enforce" better practise among our users ?

Hi everyone,

After filter and input filter components, I'm starting this PR about hydrator. As we don't have any formal discussion board for ZF3, I open PR for that (@ocramius told me to do so to). I hope it does not bother you @weierophinney.

NOTE : the code is not working yet, it's just a draft for new ideas.

Hydrators

Like Input Filters, I think Hydrators were without any doubt the best addition to ZF2 and one of the most useful component. It would be good to see if we could discuss about it to make them even better.

There are several points where I think hydrators could be improved and where we should focus our attention: performance and clarity.

Own namespace

First of all, I created a new namespace, Zend\Hydrator. In ZF2 it was lost inside Zend\Stdlib, but as it is an essential component, I think this is no longer correct to let it live in Stdlib namespace. Does everyone agree with that?

Performance

When I reviewed input filter component, I realized one thing: all of those critical component has received TONS of new features since they were introduced in ZF 2.0. Hydrators received strategies, filters, class methods hydrator has gained a lot of features…

As a consequence, they are now pretty slow and contains a lot of features that often cover edge cases or very application specific problematic.

I don't know what you guys/girls are thinking about it, but I think we should make sure that those critical components stay as small and efficient as possible. I've been able to have a nearly 10x performance speed-up for input filters by rewriting them and removing some very edge-cases parts.

I'm think here about the ClassMethods hydrator. This hydrator covers now a lot of different cases, but maybe we should just make more assumptions, for example that attributes are camelCased (which is the convetnion in PHP), that getters are always prefixed by get or is, and so on… In the refactor I've started, ClassMethods now does a lot less things.

We should ask people that have specific needs to extends and create their own hydrators instead of adding features to the core hydrators. What do you think about it?

Use of traits

Hydrators seems a good place to use traits. I now replaced the StrategyEnabledInterface and FilterEnabledInterface by two "ProvidesStrategies" and "ProvidesFilters". This way, any hydrators can quickly benefits those two features by using the traits.

Of course, all the standard hydrators use those two traits by default.

Changes in interface

As we are allowed to BC in ZF3, I've changed the StrategyInterface interface, so that now extract and hydrate methods have a context. This was already done in ZF2.2 but the interface couldn't be changed. It's now done.

Changes in ClassMethods

As I said, ClassMethods became really bloated. It did a lot of string manipulations, handled a lot of very specific cases, handled underscore_separated and camelCased (with string transform everywhere…). I think we should keep this hydrator very simple and make some assumptions about its usage.

I removed completely the underscore_separatd thing, so now it only assumes camelCase (it makes no sense to have getMy_Property method, and most people had to overwrite the default setting).

New features

There are a few things that I'd like to add in hydrator component: a way to have recursive hydrators. I'm not sure yet about how to implement it yet but maybe we could do it efficiently using RecursiveIteratorIterator.

This is useful because often, an object is made of other objects, and there are a lot of cases where it is useful to also hydrate/extract the children objects.

Another case is when using a REST api : we often need to hydrate/extract values, and recursively convert an object to an array (optionally with a max depth recursion).

Questions

While Marco and I were working on ZfrRest, we stumbled upon an interesting case: we are using hydrators a lot in REST context to take the POST data, convert it to array, hydrate an object, and at the opposite, taking an object, extract it and return the data.

Often, there is some needs of normalizing data. For instance, some JS library may return data formatted in a given way, and receive data in a very specified way too.

In a sense, the underscore_separated option in ClassMethods was trying to solve this by transforming underscore_separated keys (most likely that would come from JSON) to camelCase (another reason to remove this things from ClassMethods hydrator, I think it's not the right place).

However, we could not come with a nice solution. Do you think this is something that could fit into a Hydrator component or not at all.

Anything else

If you have any feature requests, things you think should be removed/added, or whatever, this is the place =).

This is an RFC for a simplification that would help a lot in building ZF applications considering non-cacheable configurations.

Problem

Some configurations rely on closures, service instances and generally non-serializable data that may break the application when config is merged and then cached

Current solution (ZF2)

In order to solve the problem, ZF2 introduced a series of interfaces that allow developers can implement in their Module classes to add configured services programmatically:

• Zend\ModuleManager\Feature\ControllerPluginProviderInterface
• Zend\ModuleManager\Feature\ControllerProviderInterface
• Zend\ModuleManager\Feature\FilterProviderInterface
• Zend\ModuleManager\Feature\FormElementProviderInterface
• Zend\ModuleManager\Feature\HydratorProviderInterface
• Zend\ModuleManager\Feature\InputFilterProviderInterface
• Zend\ModuleManager\Feature\RouteProviderInterface
• Zend\ModuleManager\Feature\SerializerProviderInterface
• Zend\ModuleManager\Feature\ServiceProviderInterface
• Zend\ModuleManager\Feature\ValidatorProviderInterface
• Zend\ModuleManager\Feature\ViewHelperProviderInterface

These configurations basically merge data to the already merged config AFTER it is cached. They all act in the same way, just with different naming and providing different config keys. That's a lot of duplicated code, triggered events and inconsistencies. Additionally, we never suggest usage of those methods if not strictly needed, which makes their existence very confusing for those who don't know that.

Suggestion (ZF3)

I hereby suggest removing (deprecating?) all the interfaces mentioned above, and instead introduce something like Zend\ModuleManager\Feature\UnCacheableConfigProviderInterface (suggestions on the name, please!):

namespace Example;

use Zend\ModuleManager\Feature\ConfigProviderInterface;
use Zend\ModuleManager\Feature\UnCacheableConfigProviderInterface;

class Module implements ConfigProviderInterface, UnCacheableConfigProviderInterface
{
    public function getConfig()
    {
        return [/* like before, nothing to see here! */];
    }

    public function getUnCacheableConfig()
    {
        return [
            // replaces `getViewHelperConfig()`
            'view_helpers' => [
                'services' => ['foo' => new SomeHelper()],
                'factories' => [
                    'bar' => function () {/* can't cache this! */},
                ],
            ],
        ];
    }
}

Bonus

With this approach, we can also get rid of Zend\ModuleManager\Feature\LocatorRegisteredInterface, which allows us to have modules like EdpMarkdown register the module as a service:

namespace Example;

use Zend\ModuleManager\Feature\UnCacheableConfigProviderInterface;

class Module implements UnCacheableConfigProviderInterface
{
    public function getUnCacheableConfig()
    {
        return [
            'service_manager' => [
                'services' => [__CLASS__ => $this],
            ],
        ];
    }
}

Benefits

• we get rid of a lot of triggered events during module loading
• we get rid of a lot of documentation related to those get([A-Z][A-Za-z]+)Config methods
• we get rid of Zend\ModuleManager\Feature\LocatorRegisteredInterface
• we get a minor performance improvement
• we get a clear understanding of what getUnCacheableConfig does. The name says it for itself
• we don't need to add more methods in case more plugin managers are added in future

ZF2 BC compatibility

In order to keep BC with ZF2, we can create a Zend\ModuleManager\Listener\Zf2CompatibilityListener, which emulates the same logic of all the current get([A-Z][A-Za-z]+)Config methods. It can be either on by default or opt-in, but that has to be decided

Drawbacks

None so far

TODO

• [x] discuss naming of getUnCacheableConfig
• [x] discuss naming of Zend\ModuleManager\Feature\UnCacheableConfigProviderInterface
• [x] find possible drawbacks
• [x] get positive or negative feedback (positive feedback gained)
• [x] discuss Zend\ModuleManager\Listener\Zf2CompatibilityListener being turned on or off by default
• [ ] provide pull request

Conclusions

• get([A-Z][A-Za-z]+)Config will be removed from the module classes. getConfig will be used
• Using un-cacheable config will simply be penalized, avoid that. That's it, nothing more
• We will simply build a listener that verifies if config can be cached safely before attempting caching. That would allow us to throw meaningful exceptions
• We will provide a listener for ZF2.x compatibility, so that get([A-Z][A-Za-z]+)Config can still be used

That's it, only removal of of methods, and that's perfectly fine. I'll work on a PR as soon as possible.

Hi everyone,

This is a branch I'm working on on my free time, to refactor the input filter component for ZF 3. I mostly push this for people who want to see the code and help.

It is not yet usable because it relies on some refactoring I'm doing in both Validator and Filter components. It completely embraces the service manager, so now we should not have the VERY annoying problem of adding custom validators/filters, and not being able to use them using the short name because it uses plugin managers that were not fetched from SM.

Under the hood, the component is completely rewritten and now uses SPL RecursiveFilter. From my first experiments, this allow an around x5-8 performance improvements and a memory consumption divided by 13 for complex input filters (magic happen here: https://github.com/bakura10/zf2/blob/943abe025ed578c4068cf19df079b34726d449a3/library/Zend/InputFilter/BaseInputFilter.php#L274-L300)

What I've seen is that the input filter component got more and more bloated, and it is now slow as hell. Checking the isValid method as it is now makes it quite clear where the problem is.

Therefore, for ZF3, I suggest that the base input filter to stay as simple as possible, and people wanting to have custom behaviors to extend the class and override the isValid for their use-cases (as a more general rule, I'd like this for most components too).

To help this, it also uses internally SPL RecursiveFilter. Basically, it allows to have very powerful validation group rules. For instance, this branch features a ValidationGroupRegex filter, and usage would be as follow:

$inputFilter = new InputFilter();
// … populate the input filter with lot of fields

// You can use the as-usual validation group:
$inputFilter->setValidationGroup(array('username', 'email'));

// But also some more complex rules. Here it only validate fields that contain 'registration-'
// in their names
$validationGroupRegex = new ValidationGroupRegexFilter($inputFilter, '/registration-/i')
$inputFilter->setValidationGroupFilter($validationGroupRegex);

Those filters are really easy to write. They must extend AbstractValidationGroupFilter and implements the "accept" method (like this: https://github.com/bakura10/zf2/blob/943abe025ed578c4068cf19df079b34726d449a3/library/Zend/InputFilter/Filter/ValidationGroupRegexFilter.php)

What do you think ? :)

NOTE : not all features have been back ported yet.

There, I said it.

Why?

Because it's about time, and composer denies upgrades to versions that aren't supported by our own composer.json specification.

PHP 5.3 is not maintained as of 2014-08-15, and therefore we shouldn't have to deal with it anymore.

Some companies (hint hint) still support extra-LTS <=5.3 releases, but that's paid support, and we are not paid to do that.

Off with it's head: thoughts?

@ocramius and I talked about the future of this project and the split of framework is an idea to manage in the best way single component. In my opinion these are the hardest structural problems:

• hard dependencies
• difficult to decouple single component Considering that we think that the possibility to split the framework could help us to manage this criticality.

Goal: Split framework and its history in diferent indipendent repositories (component + your tests).

Positive

• Different maintainers for different components..
• ZF2 project is a simple list of dependencies and every components follow its time
• ...

Negative

• Difficulties in mantainance and orchestration
• History consistency
• ...

I'm working for this split but the way is long and I'm not a git ninja :) This is my first tests but there are more problems

• Merge is not a good flow.. The history is incomplete.
• Rebase is not a good choose because the history is useless.
• Subsplit works with only one prefix path an this is not a good solution
• Maybe this script too easy.. What is your opinion about this proposal and is there a git ninja?! :)

Hi everyone,

Again another PR/issue for ZF3. I promise, this is the last one I will make (ok, maybe Forms too :D...).

This one is another lower-level component, but I need this one to correctly finish the InputFilter one.

As for filter, the main changes will be: some performance optimizations we can make with PHP 5.4, cleaning some code, homogenize options by using underscore_separated... The only real change I've made for now is to make the ValidatorChain exactly the same as FilterChain (I was always bothered that those classes didn't have the same method names or underlying implementation).

HOWEVER, there is a change @ocramius and I discussed on IRC and I'd love to have your opinion on that. The InputFilter refactor made the component completely stateless. It opened interesting optimizations, and the idea came to make validators also stateless.

To stay simple, the following code:

$validator = new Boolean();
if ($validator->isValid(true)) {
   // Do something
} else {
  $error = $validator->getErrorMessages();
}

Will be transformed to:

$validator = new Boolean();
$validationResult = $validator->validate($value);

if ($validationResult->isValid()) {
   // Do something
} else {
   $error = $validationResult->getErrorMessages();
}

As for input filters, validationResult instances are serializable and can be transformed to JSON.

Translation would still be handled by the validators themselves: they will translate the error messages and pass them to the validation result.

What do you think of this idea? Is there any drawback that you may see from it?

EDIT : Credit for the idea to George (https://gist.github.com/texdc/5929229#file-validationresultinterface-php)

The Zend\Mvc\Service\ModuleManagerFactory defines all the service and plugin managers. It only passes the correct configuration key as the second parameter to the Zend\ModuleManager\Listener\ServiceListener::addServiceManager() method. Typos in the configuration of module.config.php files like view_helper or `formelements' are not checked. This leads to much frustrations for beginners when they get no feedback due to this.

I would suggest to add a little check for typical typos in the configuration and throw a notice or a warning so people get an advise to correct their typos.

Any comments? I would suggest to add this to the 3.0.0 milestone.

Composer as primary autoloader

Just a suggestion, but I think that composer pretty much took over the autoloading-related problems in all of PHP.

This is a good time to dismiss Zend\Loader.

EDIT: the git submodule update --init approach could also finally die :-)

Compatibility

Almost every module that is on github currently provides a composer.json file. The BC break would be only for most in-house modules that still rely on Module#getAutoloaderConfig().

We can get rid of getAutoloaderConfig() or provide a small compat layer that just merges the fetched configuration into the already existing Composer\Autoload\ClassLoader.

Advantages

One less component to maintain, nuff said.

Problems

The only issue with composer-first autoloading is security, but I think that can be dealt with until this issue becomes a PR.

Additionally, composer can be used without packagist and as a pure autoloader (composer.phar dump-autoload).

while i'm using session_start() in other application which is native $_SESSION, and I back to app based on ZF2, I got error exception :

Passed variable is not an array or object, using empty array instead

found the exception in Zend/Session/SessionManager.php(95) and suddenly I logged off from my app based on ZF2.

Hi guys, I have been searching for a zend functionality that prevents the session from timing out if the user is still active for example clicking things.

I would rather use a zend implementation if available than write custom code. However, I am not sure this feature is available.

Hi guys!

I'm here with this issue: https://stackoverflow.com/questions/49572417/zf2-error-handling-for-a-specific-module-only (please also note the issue which mentioned there: https://stackoverflow.com/questions/17948543/zf2-how-to-attach-module-specific-listener-for-dispatch-error).

Actually, I found out, that the issue could be fixed by changing DispatchListener.php. It gets EventManager like this: $events = $application->getEventManager();

But if controller exists $events could be overridden with: $events = $controller->getEventManager();

And then the issue with module-specific error handlers would be solved.

Does anyone know solutions without fixing of core files?

And is it actually a bug (that custom module can listen to "dispatch" for example, but cannot listen to "dispatch.error")?

The PHP-function each() has been deprecated as of PHP 7.2.0 (https://wiki.php.net/rfc/deprecations_php_7_2#each), but is still used in ZF 2.4:

library/Zend/XmlRpc/AbstractValue.php: list($type, $value) = each($xmlAsArray);
library/Zend/XmlRpc/AbstractValue.php: list($type, $value) = each($namespaceXml);

tests/ZendTest/Db/Sql/Platform/Mysql/MysqlTest.php: list($type, $decorator) = each($decorators);
tests/ZendTest/Db/Sql/Platform/SqlServer/SqlServerTest.php: list($type, $decorator) = each($decorators);
tests/ZendTest/Form/View/Helper/FormSelectTest.php: list($value, $label) = each($options);
tests/ZendTest/ServiceManager/TestAsset/FooInitializer.php: list($key, $value) = each($this->var);
tests/ZendTest/XmlRpc/RequestTest.php: while (list(, $node) = each($result)) {
tests/ZendTest/XmlRpc/RequestTest.php: while (list(, $node) = each($result)) {

So each() should be replaced by foreach() which is also 10 times faster.

Hi,

the current ZF2.4.13-release not support the TLD ".gmbh", although the domain is listed on "http://www.iana.org/domains/root/db/".

Temporary solution is to write a wrapper-class. Can this be fixed in the 2.4.14-release?

Thanks and many regards, patric

Hi,

Current version 3.0.0 is quite old now.

What are the plan for a newer version allowing some more recent components ?

Especially zend-stratigility 2.x.

Hello everyone.

When i want to use Prompt/Select class, if my array options has more than 9 options, i can not select the 10th options with '10', it'll display 'a', 'b'... To select it, i would like to write 10 but when i write 1, it submit the select 1.

If we check the code, we can see those lines : // Retrieve a single character $response = parent::show();

There is a possibility to display 10 options and selected the 10th ?