stack of custom code). We should extend that to other components as
much as possible IF NEEDED elsewhere. Now that we have Composer,
>
>
>
> On Thu, May 30, 2013 at 11:43 AM, Marco Pivetta <
[hidden email]> wrote:
>>
>> Answers inline
>>
>> On 30 May 2013 18:22, Greg <
[hidden email]> wrote:
>>>
>>>
>>> I'd like to see support for a bare minimal setup, i.e where the usage of
>>> the module manager is optional:
>>>
>>> * One main configuration file, either application.config.php or
>>> global.php. Its not very cleary what application.config.php is really about,
>>> and its also very limited in its scope.. so far it seems its only purpose is
>>> to specify which modules are to be used.
>>>
>>
>> I don't get this one - what's the difference with a 0-module setup? :|
>
>
>
> The hardest part to overcome is the understanding of the service
> configurations, and the fact they you'll spin your wheels trying to specify
> the 'Application' class in the application.config.php, because of the way
> the that the rest of the bootstrap process is handled. This is even
> demonstrated in ZeffMu application, it first statically calls ZeffMu::init()
> but then you later on, in the module layer, specify the class name of the
> Application object. But shouldn't specifying any service object be easily
> achievable via the application.config.php?
>
> Basically the module manager is not much more than a glorified bootstrap
> handler, whereas for a 0-module setup, all of that can (or should) be
> skipped with a single config file (i.e. application.config.php).
>
> To get a better sense of this, you'd have to try and bootstrap the ZF2
> application, without modules, and to try and specify your own application
> service config. I do think ZF2 should provide support for running an
> application without requiring a module manager.
>
>
>>
>>
>>>
>>> In my (non-module) setup, only application.config.php is needed and
>>> support for environment specific overrides (dev, staging, etc), this meant
>>> having an 'MVC Bootstap Config'
>>>
https://github.com/zendframework/zf2/pull/4000.
>>>
>>> In my case, I ended up copying all the service config info into
>>> application.config.php.
>>>
>>
>> Also a non-module setup can use `config/autoload` - we could make the
>> config listener separate from the module manager (and inject it in the
>> module manager instead)
>
>
> The pull request does support config/autolod, there is the config_glob_paths
> setting for this. The point is that we can compile configurations without
> depending on the module manager. If I recall, the tricky part is the module
> events and (subsequent merging etc) .. hence they ultimately do the same
> thing, but one is not event driven.
>
>
>>
>>
>>
>>>
>>> * Using composer as the sole autoloader, honestly, it seemed a lot faster
>>> than the ZF2 one, and it also moves all of the autoloading config setup to
>>> the very front of the app initialization which is sufficient for a minimal
>>> (non-module) application setup and alleviates any session related
>>> serialization issues.
>>>
>>
>> Great +1 for this - composer was ditched because of some security related
>> discussions that were brought up in the past. People can disable packagist
>> usage if that's the problem.
>> For the "global installation path" I'd rather ask Seldaek - he may know a
>> better way of handling that.
>>
>>>
>>>
>>> * Renaming MVC\Application, I think it should be called MVC\Manager or
>>> MVC\MvcManager, instead of Application. The reason being is that currently
>>> getApplication() forces 'Application' to be a reserved word for the
>>> framework code, and removes it from the real application layer ... it may
>>> not be so bad, if the Application object was actually more easily extendable
>>> (currently it takes some understanding of why you can't just override the
>>> class name in the main 'application.config.php' file). Similar thoughts
>>> could be applied to say the event manager, e.g getMvcEventManger() .... i.e.
>>> the component name in the method name makes it a little more obvious.
>>
>>
>> It is an application though, so I'm -1 on this... The application
>> structure is quite flexible already, take a look at
>>
https://github.com/BinaryKitten/ZeffMu for reference.
>
>
> My point is that when saying, getApplication() the first thought is, which
> one? By renaming the core MVC one, it removes any ambiguity, and leaves the
> developer free to define what they want to mean by the term 'Application'.
> As said, it might be easier if it was more easily extendable without having
> to drop to the module layer before being able to define what it is.
>
>
>>
>>
>>>
>>>
>>> * Removing the word 'Controller' from template file paths (which are
>>> resolved by namespaces), e.g /application/member/controller/index is
>>> unnecessary, harder to explain and organize etc.
>>>
>>
>> That's going back to magic - it may be more interesting to just pass the
>> controller name to the view path resolver instead...
>
>
>
> Isn't that already happening? The controller's namespace constitutes part of
> the controller class name... What I'm getting at here is the PSR-0
> organization of a 0-module setup
>
> namespace Application\Member\Controller;
> Application/Member/Controller/IndexController.php
>
> namespace Application\Account\Controller;
> Application/Account/Controller/IndexController.php
>
>
> With composer's autoloader, and 0-module setup (there is only one template
> stack path), and a single config file, its efficient for a minimal
> application.
>
> --
> Greg
Locked
