Do you have it as a separate Module, or just one separate Controller, or multiple Controllers without any logical separation from Frontend (except for Auth ofcourse), or something else?
Assuming that backend is reasonably complicated, i.e. something more than review/confirm/delete comments for your BLOG.
Definatly belongs in a new module then it is easy to create a separate layout in my opinion.
In a recent project a colleague created a separate admin controller in each module with the layout defined in an admin module. This way he could drop in/remove modules from the project with the main admin module autodetecting which modules are installed and creating menus based on the admin controller found in each pluggable module.
I have explained that poorly, but it's a good system.
I would create a separate module. Otherwise you might run into context issues because the ArticleController in the frontend should have other/limited functionalities then the administrative ArticleController and you end up implementing mixed controller classes (bad idea!) or prefix the administrative class.
So having multiple modules makes it easier to separate different concerns.
(Plus it will make it easier for you to implement an ACL and handle the corresponding resource/role definitions.)
Related
I can't seem to grasp the modules of dagger.
Should I create a new instance of a module each time I want to inject stuff?
Should I create only one instance of a module? If so where should I do it?
Is there a more complex example of fragments and activities used with dagger?
Thanks
You should think more about #Component than #Module. Modules just create objects that need further initialization. The actual work happens in Components, which modules are part of.
Should I create a new instance of a module each time I want to inject stuff?
You should create your module when you create the Component it is part of, since only this component is going to need it. If you find yourself creating the same module multiple times, you are most likely doing something wrong.
A module uses additional arguments (pass them in via the constructor) to create more complex objects. So if you were to have e.g. a UserModule you'd pass in the a user to create user dependent objects from the resulting component. If the user changes lose the old component and create a new module and a new component—the old objects should not be used anymore.
Keep the component where / when appropriate and be sure to use Scopes, since they determine the lifetime of your component.
Should I create only one instance of a module? If so where should I do it?
You most likely will just create a single instance of #Singleton annotated Components and Modules. In android you'd most likely keep the reference to the component (not the module!) in the Application or some real 'singleton'.
Is there a more complex example of fragments and activities used with dagger?
Try googling. There are lots of high quality tutorials with linked github repositories that go into much more depth and detail as would be possible here on SO. e.g. see Tasting dagger 2 on android.
How can I manipulate other modules without editing them ? very the same thing that wordpress modules do .
They add functionality to core system without changing the core code and they work together like a charm.
I always wanted to know how to implement this in my own modular application
A long time ago I wrote the blog post "Use 3rd party modules in Zend Framework 2" specifically about extending Zend Framework 2 modules. The answer from Bez is technically correct, it could be a bit more specific about the framework.
Read the full post at https://juriansluiman.nl/article/117/use-3rd-party-modules-in-zend-framework-2, but it gives you a clue about:
Changing a route from a module (say, you want to have the url /account/login instead of /user/login)
Overriding a view script, so you can completely modify the page's rendering
Changing a form object, so you could add new form fields or mark some required field as not required anymore.
This is a long topic, but here is a short gist.
Extensibility in Zend Framework 2 heavily relies on the premise that components can be interchanged, added, and/or substituted.
Read up on SOLID principles: http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
Modules typically consists of objects working together as a well-oiled machinery, designed to accomplish one thing or a bunch of related things, whatever that may be. These objects are called services, and managed by the service locator/service manager.
A big part of making your module truly extensible is to expect your developers to extend a class or implement a certain interface, which the developer register as services. You should provide a mode of definition wherein the developers can specify which things he wants to substitute, and/or add their own services to -- and this is where the application configuration comes in.
Given the application configuration, you should construct your machinery a.k.a. module services according to options the developer has specified i.e., use the developer defined Foo\Bar\UserService service as the YourModule\UserServiceInterface within your module, etc. (This is usually delegated to service factories, which has the opportunity to read the application configuration, and constructs the appropriate object given a particular set of configuration values.)
EDIT:
To add, a lot can be accomplished by leveraging Zend's Zend\EventManager component. This allows you to give developers the freedom to hook and listen to certain operations of your module and act accordingly (See: http://en.wikipedia.org/wiki/Observer_pattern)
Coming from ZendFramework 1 to ZendFramework 2 I'm a bit confused as to the functionality of the modules. In ZF1 a module was a sub-application, so you'd have a 'default' module and maybe an 'admin' module that would handle the administration section of the system and there'd be models, views, and controllers underneath each of those modules.
It seems that in ZF2 a module is more fine-grained? In the tutorial project they created an "Album" module which seems like it is only configured for a single controller. What if you wanted to maintain users and they each had a bunch of albums? Would you create another module for 'Users' with it's own controllers/views/models, or would you create a 'UserController' inside of the 'Album' module?
What if you wanted to provide an api endpoint into those controllers? Is that yet more modules, or do you provide a route in the album controller pointing to '/api/album' which specifies a rest style controller?
Zend 2 takes a modular approach to everything. It is really up to you how fine grained you want your modules to be. If album and user are decoupled and could be reusable then it makes sense to have them in separate modules. Since an album may not ALWAYS have users and vice versa. However if you write the code in such a way that user and album are tightly coupled they might as well be in the same module. zf2 is very flexible and this is really a design decision you need to make
With regard to your API question I would say you would have the Rest controller and the controller in the same modulle and use the module config routing as you say
I did implement a Catalyst authentication application (captchas, password reminders, access logs, etc...).
How am I supposed to re-use it in different Catalyst applications? I.e.:
Or - more generally - how am I supposed to let two applications talk each other?
You're basically asking : I have build two airplanes, how do I let them talk to each other?
Maybe see Catalyst::Plugin::Authentication (and module that use it) and make one yourself,
or something else entirely, like a radio
You can abstract common components in your local catalystX namespace and extend your controllers and models from that namespace .
I'm a bit puzzled about Zend Framework modules.
I mean - I understand that you would usually want to have frontend and backend module... right?
But - What else would you separate out into modules?
can someone who uses Zend Framework professionally give an example of what modules they have in their application?
In the Zend MVC lingo a module is an independent part of your application. For example if you want to write a Content Management System you will probably have different modules like
Main application (user login, application bootstrap etc.)
Blog
News
Admin panel
Image gallery
Basically each of these modules could act as a separate application (although they will eventually be interconnected). The module approach also gives you an easy way for permission management (e.g. users can only pay for using certain modules).
As addition to Daffs answers we could try to figure out some guidelines for deciding between choosing a 'controller' or a 'module' to implement a certain bundle of functionality. Please help making this list comprehensive by commenting or editing:
When to use a 'controller':
when there is a considerable degree of dependency on different models of the same module
when there is a considerable degree of interaction with other controllers of the same module
when the functionality can be covered with a few methods/actions
when the functionality is clearly just a bundle of subordinated functionality of the given module
when the functionality can be easily maintained together with the rest of the code (versioning, deployment, ...)
When to use a 'module':
when there are no or almost no dependencies with the main modules controllers and models
when the bundle of functionality can be seen as a separate (sub)application
when the functionality can't be covered with a few methods/actions and thus has to be broken down into several controllers
when versioning and deployment needs independence from main module