I've started working with Yii for a month (great Framework) and I am now going to build an application, ERP style.
The goal is to have a main application and then, according to user's roles and permissions, have the possibility to navigate (through single sign-on) to the other applications in the ERP.
I read about modules on Yii's docs and although I got the idea, I was left with some doubts.
Surely it is an advantage to have a One Big application with all the branch applications the company needs as modules but what are the limitations?
Or is it preferable to create seperate entire applications instead of modules inside the main App and then navigate through sub-domains?
Its better and preferred to have modules rather than developing separate applications. With modules you can have totally different look and feel just like a separate application. You must have used Gii tool, well that is also a module within your application.
The main advantage with modules is that you wont have to deploy it separately, it is a self contained application in your website. But again that could be a disadvantage if you need to have total separation of these applications.
To learn more about modules see http://www.yiiframework.com/doc/guide/1.1/en/basics.module
Related
When should we use multi-module structure (instead simple structure) in php Phalcon?
I have found some multi-module skeleton, such as:
https://github.com/ovr/phalcon-module-skeleton,
https://github.com/phalcon/mvc/tree/master/multiple.
But I don't know should i use this multi-module structure in a project instead use multi projects.
Something i can think about it is: more complex configuration, complex folder structure, my web url be longer (/[module]/[controller]/[action]) and , importantly, performance will be low (for more loading things than).
However, I think that there are something interesting with it (so many ITer had used it). Is there Someone can give me advantages, disadvantages and criterias for selection.
P/s: the same problem with Zend2 Module!
If you are building a single purpose application as an API that does not use Views, you should rather use single module structure. If it will be a realy simple API of for example storing/logging, micro app will do aswell.
Multi module application structure is useful if you are willing to build more complex solutions. For example an public application with public content, but with admin panel. This one would be handy to write in multi-module to separate administrative controllers/views from those public ones.
My habit is to use multi-module structure, because mostly I have to build applications that are CRM's with their API and an public accessible content part (eg. docs). For such purpose it's just handy to create such modules as:
frontend - for controllers accessible by everyone
backend - for controllers accessible after authentication and authorisation like administrative things
API - for API purposes ;)
common - a part I rather am willing not to implement, but in one project I'm forced to put here some abstract controllers that will be extended in other modules.
This way you can keep separate services configuration for each module, what saves you from cutting off things that you are using at purpose of module A, but not on module B. Like authentication part - important for backend, but useless for frontend part. Or Database configuration - slaves for frontend, master for backend, etc. So this may be also a performance-wise solution for big projects.
Update
Sometimes "multi-project" is an option including "multi-module" project ;) It strongly depends on what you are trying to achieve. Eg. if you take API apart, it may be easier to scale it over multiple instances, but at first it costs you an efford to configure separate project.
If system is supposed to be single-server instance or every istance should be absolutely independed on other instances, single multi-module project will be enough - lets say a standar CMS, blog platform, even simple browser game or homepage of mobile app including API for it. But if you are building a whole universum of apps like an internal API to privide content, CRM to manage it and a couple of web pages to serve it, keeping these as separate projects will be easier to manage later.
Well for example I in my application im splitting every functionnality - for example i have model Link - it's splitted to seperate module to have nice application structure where each funtionality is seperated module. It's like less classes to load in loader. Beacause you only need models and routes from each module to load for whole app, and you load other things like librarys/controllers/helpers/services in module.
We're in the process of building an application entirely based on ZF2. The application is split into 3 main divisions namely a Core, API and Front End section / division.
At some point, we want to open the system up for people to develop 3rd party modules which will go on offer for inclusion in the different profiles customers have. These 3rd party modules would either extend functionality or be able to enhance existing processes by hooking into events fired from the Core Level.
These 3rd party modules could use the API, however, the current API is outward focused and does not lend itself to enhancing and extending the system from this perspective.
So, the alternative would be to allow access to the Core directly, which we feel might not be desirable as we must have a means to control access to these vital components and underlying data.
I am considering building a separate API aimed at trying to manage access from a module level within the Application life cycle, however, I am not entirely sure how something like this would look like.
The folder structure would look something like the following:
-config
-data
-AppCore
--Core
--CoreForms
--CoreContacts
-AppAPI
--APIForms
--APIContacts
-APPFront (This fodler will be into a seperate instance of ZF2 installation and communicate via the APPApi)
--FrontForms
--FrontContacts
-3rdPartyModules
-public
-vendor
Developed modules would reside within the 3rdPartyModules folder within the entire structure.
The question is, how would one go about limiting access to Core resources, for instance, any 3rd party modules must not be able to consume the standard database adapter. In this case, db_adapter (Zend\Db\Adapter\Adapter).
These modules will have a separate database setup where data should be stored specific to these modules, so something like db_adapter_3rdparty would be made available instead.
I have considered using interfaces to be implemented within these 3rd party modules and then have a check performed by any of the core module classes and functions, however, this would be cumbersome and inefficient.
Currently, the API functionality is only accessible via REST, so that would not be option for hooking into the system as keys would become involved and be an admin nightmare.
So the question is then, allowing modules to be installed within the overall application, would you be able to limit access to application resources, if so, what would be the most efficient way of implementing such control and whether it is a good idea to allow this to take place?
I've done quite a bit searching and could not find anything close along the lines of what is required, apart from actually installing modules, configuring them etc.
Many thanks in advance!
An existing 8+ year old application is being migrated from a self-contained website to a webservice-oriented architecture to allow among other things, external parties access to the calculations and data within the application.
The application allows visitors to access insurance-related information, calculate price quotes and contact agents.
The original logic of the application has been extracted from the main application to a SOAP service - so far, so good.
Based on in-house knowledge of Zend FW, the choice was made to drop the legacy code with many downsides and move to a more robust and community-backed framework - Zend.
An initial Zend FW app has been built that consumes the WSDL and allows searching and displaying of customers. After that was finished we wanted to integrate external applications/modules for components such as a basic (!) cms, mass-mailings, polls etc.
As we consider those components essential for the end-product but not our own core-product, we thus want to use external applications for this.
However - looking at e.g. tomatocms and digitalus etc., they seem to require us to build our product into theirs - and we want it the other way around. CMS pages are the exception, and not the rule.
Integrating authentication among these applications seems very difficult, as each seems to want to be 'the' application.
TL;DR:
What would be the best solutions to integrate a CMS or other apps into an existing/in progress zend FW app?
I think the best solution for you is to create a structure for Modules/Plugins where you set a pattern of use and you will make your application understand these modules created following the specifications above.
With this you allow anyone to be creating or developing models desaclopados their application.
I think this is a good example with your Wordpress plugins. Anyone can create and embed its functionality within the application page, but of course you can make in its API limitations, controlling what you want.
As our company starts using Zend Framework as the base framework for most of our projects, we want to share some common elements across all our projects. I talk about things like:
An implementation of a model (based on doctrine2)
RBAC for the model, including user, group, role models
A xml-based templating engine for ajax backend interfaces
(you name it) ...
Basically, all things to put "zend on rails" and get going. What is the best way to package these components? I see two possibilities:
As modules
We include the necessary functions as separate modules into the modules folder.
Pro:
We can set routes and execute code, which is good for many modules (imaginary example: a paypal module needs some kind of callback url. If our module can set it up on its own, no configuration from the "project developer" is needed).
We can provide real functionality (like the user administration) out of the box
We have a bootstrap to set up autoloading and doctrine etc.
Con:
Bad place? Interferes with the users project
A little harder to share between projects (git submodules instead of classpath)
In the library folder
We put it in the library folder and point the classpath to it.
Pro:
Clean solution
Sharing across projects
Con:
Bootstrap has to be explicitly called
No direct routing or actions - everything has to be proxied through the concrete project
So, how do you solve this? Where do you put your reusable, general purpose stuff in zf?
I think you should use both approaches.
When developing "library-like" code, as in kind of "infrastructure" classes and other things that are reusable (like ZF's own components, Doctrine 2's components etc.), you can put them into the library directory. (or its own entirely separate project)
When developing actual ZF modules (like an auth module for example), then format the code around the ZF module structure.
I think by using this kind of approach you get all the benfits you listed, and pretty much none of the cons :)
As one additional idea, if you develop your architecture parts as "services", you could even keep them running as their own web service endpoints.
I have to develop frontend/backend application using cakephp.
can you give me advice how should i develop them, using same cakephp library?
or I have to develop them using separate cakephp libraries?
I am confused - cakePHP would be used to implement both.
PHP would be used to implement the server-side backend. The same "project" would also contain HTML, JS, CSS, etc that will be used to render the front-end within the browser. Any PHP "views" will also execute code on the back-end, although any HTML output will be rendered on the frontend.
Does that help at all? Or am I missing something?
If by frontend/backend, you mean an application with a user interface (frontend) and an administration interface (backend), then you want to refer to the Prefix Routing section of the manual. This will allow you to have separate flow and interfaces (controller/view) for each type of user while sharing the same data (models).
If by frontend/backend, you mean an application (frontend) that communicates with another server application (backend) using web services, then you want to look at the Additional Class Paths section of the manual. This will allow you to share common classes with two (or more) separate applications.
Note: the above links are for CakePHP 3.x, though these features have existed in one form or another since v1.2.
Not quite sure if I understood you correct, but if I did:
You can set up multiple projects using the same cake-core files. The core files don't even need to be placed in the webroot folder..
http://book.cakephp.org/view/35/Advanced-Installation
For your own sanity, you should regard the backend management as part of the same project as the frontend.
The systems I have built generally use view-type methods for the public view and crud-type methods for the admin view. How you lock down the admin is your choice. Personally I don't like the default admin prefix way. I use login and ACL - Mark Story's tutorial on http://book.cakephp.org/ is superb. With that you can password protect methods.
CakePHP is very flexible and extensible and you can make the administration as simple or as flexible as you like.