This repo seems to be the next monolithic library.

[Maks3w]

It's good to provide support for the most common/popular third party implementations but I think each one of them should be developed on individual packages.

[danizord]

:+1:

[codeliner]

:+1:

A decision for this request will influence config approach discussed here

[weierophinney]

I need way more detail. What exactly do you feel is becoming monolithic? How do you propose changing the situation?

We have a number of implementations by default to (a) reduce dependencies, and (b) provide something that works out-of-the-box. We do not plan on adding more and more to these; they are mainly present to achieve those two objectives, as well as provide a blue-print for how others may develop conforming implementations. In point of fact, the proposed installer already allows you to provide alternate packages for each dependency.

I've even created a separate package myself: https://github.com/phly/phly-expressive-mustache

So, knowing that: what do you feel needs to change at this time?

[Maks3w]

My feelings are the same as ZF2 discussion of components plus the discussion about zend-validator split.

Different components will improve the development release cycle (We are seeing the effect on various ZF components reaching 2.6 and more)

Prevent things like #129 (well, only prevent for to discuss it here)

Allow to quickly deprecate third party libraries and reduce the maintenance over the adapter.

At least I expect to split out those libraries before this project become stable.

[harikt]

@weierophinney I don't know you like my idea. I did proposed one earlier. This is what I feel currently seeing the issue.

1. Move template / dependency injection container to separate bundles.
   • This will bring something like zend-expressive-twig, zend-expressive-plates etc.
2. This brings another question of how do you handle the configuration
   • What about keeping a class somewhat similar to how Aura.Di is doing? http://auraphp.com/blog/2014/04/07/two-stage-config/ . This will reduce the code people need to copy and paste.

Thoughts?

I know you do love to move somewhat similar but it is due to getting things harder to test and maintain.

[Maks3w]

Also, develop sub components on external repo make us to feel the same sand as the "great unknown developer" which fight to create his own extension but with the limitations of not change nothing in the parent project.

[codeliner]

:+1: for @Maks3w reasoning

:+1: for @harikt point 1, :-1: for point 2

We (at prooph) integrate third party packages exactly the way proposed here. The main package (zend-expressive in your case) should only provide the required interfaces like RouterInterface, TemplateInterface or even ContainerInterface which is itself a third party dependency but a very small meta package with a clear focus.

Besides the reasons already mentioned another one is that you can run travis-ci builds against different versions of third party packages for example against the most widely used version, current stable and current development version.

Problems:

• more effort required to coordinate changes across the packages. Imagine you want to change the TemplateInterface (add a new method for example). You add the method in the current develop branch and start to adjust the bridge-packages (or sub packages) providing the glue code to marry zend-expressive (interface) with third party implementation. When you are done, you have to release new major versions for zend-expressive as well as all sub packages effected of the change. Ideally, you release all new versions at the same time. Doable, but only with a good overview of the entire ecosystem.
• second problem (was already mentioned) system set up and configuration: I would not introduce a config class like suggested by @harikt . This would bring us back to the Module.php of ZF2 and the problem that a lot of classes are invoked at application start up (in PHP unfortunately on every request).

What we currently do is we provide simple config skeletons (default php array config) like you can find in a lot of ZF2 modules. We ask the user to take this config skeleton, modify it (if needed) and merge it into the application config either by hand or by using a helper like Zend\Config::fromFiles(...). Sure, the user has a bit of work but it is also a good entry point to learn a bit more about the package. And the user can set up a config cache and skip the heavy merging in production mode.

A well structured php array config with some comments can at least reduce documentation. And looking at puli the config merge can be automated in the future when application libraries like zend-expressive provide puli support. We're really looking forward to something like that.

[bakura10]

I agree with this and I had the same feeling when looking that there was more and more integrations.

The answer of config really seems to be Puli. As I told mwop I started to play with it and I encourage anyone to play with it. It's pretty complex (I wanted to do a PR but puli is really complex project), but from my early tests I can definitely see it IS the solution we all need to replace module manager and solve nicely the config issue.

Each package can have its own puli.json file with some metadata bout where is the config, and everything can then be retrieved by expressive to create a container and having everything configured.

Somebody should try to explore that, and once we have that, splitting this repo will be way easier.

[harikt]

@codeliner does loading classes take that much time? I feel it will be very little. Probably we should use some sort of caching once the load is done.

[harikt]

@bakura10 puli... I had a hard time to working on it. Not so font of it :-/ .

[codeliner]

@harikt Loading the classes is not the only issue, but again we are not talking about 5 config classes but maybe 30 and more.

Further Problems

• People tend to put logic into bootstrap and config classes. That is the real problem why bootstrapping becomes a slow operation. Well, we could say hey don't do that. But people will do it and other people will use these bad packages and think zend-expressive is slow as hell. I know it is wrong, but this is the reality. Unfortunately, creating popular open source projects today is a hard job. One wrong decision and people will use alternatives.
• A config class would couple the package with zend-expressive. But we don't want to write expressive modules. We want to write independent packages which can be used in any framework. So everything that is not native PHP or a (de facto) standard is a blocker for us and forces us to create a bridge package. We had hard dependencies to ZF2 in the past and people moved on to other packages because of this dependencies. Since we removed the dependencies things are looking better for us :). Puli on the other hand is not a real dependency. The puli.json can be shipped with the package and if the user does not use puli then it is fine because he/she can merge config by hand.

Conclusion I absolutely agree with @bakura10. TBH I only read the docs of puli a bit but what I saw was really good stuff and when @bakura10 tried it and think it is a good choice, well then puli cannot be that bad ;) When someone has a hard time working with a package the best thing is to give the maintainer of the package some feedback. You don't need to send PRs just open an issue and describe what is your problem. This is the best help you can do. Puli is a great idea, zend-expressive is also a great idea but please don't reinvent the wheel again. We don't need the 5 millions web framework doing the same stuff over and over again. Use high quality third party packages whenever possible but of course with loose coupling to be able to exchange dependencies when needed.

[harikt]

@codeliner I have got a suggestion ie only load the config if it is depending on something. Eg : Consider a blog package, you don't need to load the blog package config until you know this route is going to check something related to blog. So we can add in the pipe to load that particular config.

$app->pipe('/blog', $blogConfig);

[bakura10]

@harikt , that's a bit what Expressive do with lazy middlewares. However there is a possible issue: let's say your Blog middleware using event manager and contains a listener that listen to a specific event triggered "elsewhere" (possibly by another middleware).

The blog endpoints may not be used, but its listener may need to react, so it would need to be bootstrapped. I'm not sure how to tackle this, I think the EVM lazy listeners will likely solve this issue.

[Maks3w]

I think we should split the conversation by topics on different issues for to discuss the best options/alternatives for each one.

[Maks3w]

In resume.

• There are concerns about automatic link of configs provided by the extensions.
• There are concerns about the bootstrap

[geerteltink]

The reason that there are factory and other classes for templating and routing is that there is no container-interop for those. If there was a router-interop and template-interop there wouldn't be this discussion.

But I do think that you need to give a choice for several reasons.

• It makes zend-expressive developers figure out a way on how to make specific type of packages (like routers) work nicely in the same way.
• It gives end-users an example of what can be achieved and how.
• It gives the end-users the choice of what packages to use.

Especially the last one is very important. If you don't give a choice, zend-expressive is just like any other middleware framework. Besides that, it wouldn't work anyway. You still need at least 1 router built in.

Having said that, it doesn't matter where factories and wrappers are kept. It might be in the zend-expressive repo or create 6 extra packages for the template and router files. Either way, they have to be maintained.

[codeliner]

@Maks3w Agreed. We should focus on the sub packages topic here. Package integration can be discussed after decision is made.

@harikt Additional to what @bakura10 said. You'll have a lot of dependencies which don't operate on a specific path only - nearly everything that is related to infrastructure like database connection authentication, authorization, session handling, ....

@xtreamwayz --

The reason that there are factory and other classes for templating and routing is that there is no container-interop for those. If there was a router-interop and template-interop there wouldn't be this discussion.

Agreed. But we cannot create a *-interop for everything. This would take years. Look at the progess of FIG regarding PSR-6 or PSR-11. The time we would loose in discussing these standards the time would be used by other platforms like JS to create awesome stuff so when the standards would be out nobody except us would need them :smile: Just saying ... You will always need to define project specific interfaces and provide glue code to integrate third party. That is the main reason for interfaces in general.

But I do think that you need to give a choice

I also agree on that, except:

You still need at least 1 router built in.

Why a built in router? Expressive need a router ok, but also only when you define routes. As long as you would only pipe middleware the router would not be required but yeah then you can use zend-stratigility only. However, telling the user - you MUST install a router but don't worry we already did the integration work for you: here are your choices - is a great way to combine both worlds.

it doesn't matter where factories and wrappers are kept.

Absolutely disagree due to the reasons already mentioned by @Maks3w and myself.

Either way, they have to be maintained.

Yes, but you can give interested people fine grained access to only these integration packages. These packages can be maintained by others not you as the main package maintainer. Your job is to coordinate development work and make sure that everybody is on the same page when new releases are planned and new features should be added. It is a huge difference between the both suggested options, not everything related to the code itself but also organisational topics.

[Maks3w]

For me even most important than the administrative organization is that taking development of extensions outside of the main project helps to the project owner to feel so much hard or so much easy is to extend as he/she was thinking.

Also individual repos helps are useful as skeleton projects to third party developers.

[weierophinney]

What if the selected module uses code from your blog module? Now the configuration isn't loaded, and execution fails it works in unexpected and unintended ways.

It's easy to say "lazy load!" But in practice, it's often not as simple as it seems. This is why the zf2 module manager existed. It's actually quite light weight; the bigger overhead is the EM and SM – both of which we're actively addressing now.

Bootstrapping can be expensive, but typically only when using serialized configuration formats and/or marshalling a lot of objects early. PHP arrays and/or configuration caching since the first, DI solves the second. On Sep 15, 2015 3:45 AM, "Hari K T" notifications@github.com wrote:

@codeliner https://github.com/codeliner I have got a suggestion ie only load the config if it is depending on something. Eg : Consider a blog package, you don't need to load the blog package config until you know this route is going to check something related to blog. So we can add in the pipe to load that particular config.

$app->pipe('/blog', $blogConfig);

— Reply to this email directly or view it on GitHub https://github.com/zendframework/zend-expressive/issues/131#issuecomment-140324627 .

[harikt]

What if the selected module uses code from your blog module?

You as an application developer knows which part need what configuration. So I feel that will not be a problem. Some of you may disagree.

[bakura10]

Just as a side note to give some more points to this thread: I wanted to upgrade to use develop branch of service manager (v3), but got stuck because.... Zend\Mvc requires SM2, as well as Zend\View... so we cannot actually upgrade until all those components are upgraded too :/.

[Maks3w]

If composer its the problem you can use the inline alias for disguise the develop branch as any 2.x version.

[akrabat]

FWiW, I think that it's generally fine. We're not talking about a lot of files here.