Usually I work with Zend Framework and now I'm developing an application on CakePHP and trying to understand the framework, in particular how to modularize an application.
In ZF there are modules. Every logical subdivision of an application can (and should) be packed to a separate module. It allows to keep the application structure clear.
There are no modules in CakePHP -- instead the framework provides plugins and I firstly thougth, plugins are the "modules" in CakePHP. But a plugin in CakePHP seems to be something more, than a ZF's module -- "behaving much like it would if it were an application on its own". Plugins should apparently be used for bigger things like a blog or a forum, that have characteristics of an independent apllication. So logical units like User, Order, Payment, or CustomerFeedback, that only make sense within the application, are probably not suitable as plugins.
Is there a recommended way / What is the recommended way in CakePHP to separate an application into small and well manageable logical parts and so to build a modularized application?
CakePHP plugins and ZF modules have a little bit in common, both can contain MVC logic, library code, configuration, assets, tests, etc., and can pretty much behave like applications on their own.
However there's no need for such "whole application on its own" level of complexity in order for plugins to be the recommended way of managing logic. Of course they can also be used for less complex stuff like splitting your application into logical (and reusable) units.
A payment plugin, a user management plugin, an order processing plugin, a feedback plugin, that all makes sense, and it's neither wrong nor discouraged to use plugins in such a manner.
If you need some inspiration, check out Croogo for example, it's a CakePHP based CMS that manages its different parts using plugins.
Related
I will develop a business project. Should I use cakephp 2 or cakephp 3?
I am expert in cakephp2 and launched many websites using it.
CakePHP 3 has a lot of better features than Cakephp2:
What’s new in version 3 of CakePHP?
This review is based on the alpha release of CakePHP 3.0, which incorporates a number of new features and enhancements including:
Better performance. Version 3 incorporates performance improvements to the bootstrap process, the routing process, and several parts of process for generating helper templates.
Enhanced components and helpers. Version 3 provides enhanced support for “flash messages” with its new FlashHelper and FlashComponent. In addition, the CookieComponent has been enhanced, making it easier to separate the configuration of cookie namespaces and the handling of cookie data.
Improved session management. Session management has always been a static class in CakePHP which has proven to be problematic in a number of ways. With version 3, you can now access the session from the request object $this->request->session(). This change also makes the session easier to test, and enables CakePHP to use PHPUnit 4.x.
Improved consistency of conventions. The application skeleton and plugin skeletons have been updated to use the same directory structure in order to be more consistent with one another.
Themes and plugins merged. A key goal of CakePHP 3 was to make themes more powerful and robust. Working toward that goal, it became apparent that what was really needed was for themes to provide the same capabilities as plugins. Accordingly, any plugin may now be used as a theme, which also simplifies packaging and redistribution.
ORM Improvements. Several API changes have been made to the ORM (Object-relational mapping). Most notably, it’s now simpler to specify deep associations for saving operations, and a couple of conventions have been changed to reduce the learning curve and confusion among new adopters.
In addition, there are a few additional features that are also planned to be incorporated into the beta release of version 3.0. Most importantly:
Internationalization and localization (i18n and L10n) feature enhancements
A replacement for CacheHelper based on Edge Side Includes
A new routing API for simpler and faster route declaration
Indeed, version 3 represents a significant upgrade beyond prior
versions of CakePHP.
Checkout this link
And even if you are an expert in CakePHP 2, shifting to CakePHP 3 won't take much efforts!
I am from a microsoft background where I always used to keep server and client applications in separate projects.
Now I am writing a client-server application with express as back-end and react js as front-end. Since i am totally a newbie to these two tools, I would like to know..
what is the general practice?:
keeping the express(server) code base and react(client) code base as separate projects? or keeping the server and client code bases together in the same project? I could not think of any pros & cons of either of these approaches.
Your valuable recommendations are welcome!.
PS: please do not mark this question as opinionated.. i believe have a valid reason to ask for recommendations.
I would prefer keeping the server and client as separate projects because that way we can easily manage their dependencies, dev dependencies and unit tests files.
Also if in case we need to move to a different framework for front end at later point we can do that without disturbing the server.
In my opinion, it's probably best to have separate projects here. But you made me think a little about the "why" for something that seems obvious at first glance, but maybe is not.
My expectation is that a project should be mostly organized one-to-one on building a single type of target, whether that be a website, a mobile app, a backend service. Projects are usually an expression of all the dependencies needed to build or otherwise output one functioning, standalone software component. Build and testing tools in the software development ecosystem are organized around this convention, as are industry expectations.
Even if you could make the argument that there are advantages to monolithic projects that generate multiple software components, you are going against people's expectations and that creates the need for more learning and communication. So all things being equal, it's better to go with a more popular choice.
Other common disadvantages of monolithic projects:
greater tendency for design to become tightly coupled and brittle
longer build times (if using one "build everything" script)
takes longer to figure out what the heck all this code in the project is!
It's also quite possible to make macro-projects that work with multiple sub-projects, and in a way have the benefits of both approaches. This is basically just some kind of build script that grabs the output of sub-project builds and does something useful with them in a combination, e.g. deploy to a server environment, run automated tests.
Finally, all devs should be equipped with tools that let them hop between discreet projects easily. If there are pains to doing this, it's best to solve them without resorting to a monolothic project structure.
Some examples of practices that help with developing React/Node-based software that relies on multiple projects:
The IDE easily supports editing multiple projects. And not in some cumbersome "one project loaded at a time" way.
Projects are deployed to a repository that can be easily used by npm or yarn to load in software components as dependencies.
Use "npm link" to work with editable local versions of sub-projects all at once. More generally, don't require a full publish and deploy action to have access to sub-projects you are developing along with your main React-based project.
Use automated build systems like Jenkins to handle macro tasks like building projects together, deploying, or running automated tests.
Use versioning scrupulously in package.json. Let each software component have it's own version# and follow the semver convention which indicates when changes may break compatibility.
If you have a single team (developer) working on front and back end software, then set the dependency versions in package.json to always get the latest versions of sub-projects (packages).
If you have separate teams working on front and backend software, you may want to relax the dependency version to be major version#s only with semver range in package.json. (Basically, you want some protection from breaking changes.)
How is it possible to have folder in controller?
For example this scenario: We have multiples clients and each clients might have different package that share the common controller or different controller based on their own request. So I was thinking to separate them by directory in the controller.
Any Expert in Architecture can help this?
This is probably possible, but is certainly not the way you should do things with Cake (or MVC in general, probably).
I suggest that you have a separate app for each client. If you have any specific questions regarding this, or would like to add more information to your question about what you're trying to do, I can try to give you a more in-depth answer.
Without knowing more it is hard to say.
I assume you have one app that is used by multiple clients through subdomains or something else to make a difference between who is using it.
You can have a plugin per client that extends the base apps controllers as needed. You also can have different models and views then. Use routes to make the different named controllers match always the same URLno matter what client is logged in.
I would prefer a one app solution over multiple applications because it reduces the maintenance overhead a lot. But if you want to for multiple apps I would build the core of the application that is shared by all sites as a plugin itself. Using git and submodules you can then even control what version of the core module each site is using.
I'm evaluating Backbone.js for keeping data and UI synchronized in my web app. However, much of Backbone's value seems to lie in its use of RESTful interfaces. Though I may add server-side backup in the future, my primary use case involves storing all data offline using HTML5 local storage.
Is Backbone overkill for such a use case? If so, is there a better solution, focused solely on updating UI when data changes, and vice versa? (I'm also looking into Knockout and Javascript MVC.)
EDIT: I'm also now looking into Angular.js and jQuery Data Link.
Backbone.js works just as well with local storage as it does with RESTful queries.
I'm a learn-by-example kind of guy so here are some links to get you started:
Todos, a todo application
that uses local storage and
backbone.js, check out the annotated
source to see how it works.
The localStorage adapter is
all you need to get started, take a
look at the annotated source of
that too.
In the past weeks I have evaluated different solution for a scenario close to yours; being a project done in my personal free time and not being a good Javascript programmer, all I needed was something easy to learn to avoid starting from scratch.
Not surprisingly, I had the same candidate: Backbone.js, Javascript MVC and Knockout.js.
Backbone.js won:
I wasn't be required to follow conventions or replace what was already in place
I've easly hacked in its codebase to understand what wasn't clear from the documentation
I've successfully ignored a large amount of its features that was not interesting for me
It gave acceptable performance on busy pages
It works
Backbone.js is lightweight and relatively magic-free; you will probably use a small subset of its feature but it provieds a solid base to develop your solution.
I know it's been a while but you may want to check out backbone-offline project on github: https://github.com/Ask11/backbone.offline
You can also take a look at AFrameJS. I have created a bare-bones proof of concept note-taking app that works offline using HTML5 WebSQL spec, but also want to create an adapter that uses localStorage as well. My personal opinion (and I am biased) is that using an MVC library of any sorts is going to help you in the long run - the value of libraries such as Backbone, Knockout, and AFrame lie in their ability to reduce the cognitive load of the developer by enforcing a good separation of concerns. Data related functionality reside in models, displaying that data resides in Views, and the glue is kept in Controllers. Separating these three concepts might seem pedantic at first, but the end result is code that is easier to develop, easier to test, easier to maintain, and easier to reuse. A basic tutorial on using AFrameJS can be found on my site at: http://www.shanetomlinson.com/2011/aframejs-tutorial-for-noobs/
When developing for the Zend Framework is it common for developers to have to build a custom backend admin area for each unique app? Or is there a popular 3rd party backend tool people are using to manipulate your app's database?
I'm thinking of learning ZF but what stands out is how do you keep an eye on what users are doing with your app?
You have two basic choices:
Create two modules: frontend and admin. All your controllers live within
Within each module have an admin controller within the module to adminstrate it
In either case, I use a Front Controller plugin to swap the layout to admin.phtml so I have a different look and feel for my administration system. This is of course, optional :)
I tend to create an 'AdminController' specific to the application if there are too many administrative functions, or an Admin Module if there are (or there is a real possibility for the number of administrative functions to increase).
Well, in general I consider it enough to manipulate my db with let's say phpmyadmin or directly in my IDE (Aptana).
For the tasks I want to allow certain administrators to perform online I write an admin controller. Such tasks are mostly so specific, complex, dynamic that some kind of generic generator system wouldn't probably help a lot.
Still, there is at least one so called 3rd party tool I know of which falls into the category you're mentioning in your question.
DataGrid for Zend Framework
ZendFramework is not a Toolkit to create specific Application with users and, lets say articles etc. So there can't be such a 3rd party tool. I would create a admin module, not a controller, because that means you have just 1 File for all admintasks.