I'm using basic MVC pattern (customised version of https://github.com/panique/php-mvc) for my PHP application.
I'm not sure what is the right way to handle scenario like this:
Lets say my app will be used by 2 different companies. Each company wants to have specific functionalities. There will be some core functionalities shared by companies.
Also I need to manage user privileges in each company (admin, employee, etc.).
My goal is to have "modules" (specific functionality - dashboard, profile page, ...) and have them loaded conditionally for each company + affected by user privileges.
Also I need to somehow load different layout for each company. (Not totally different, slight changes only.)
I've googled it a bit and found stuff like ACL and Decorator, but I think they aren't what I'm looking for.
What is the best way for this case?
Thanks in advance.
I assume (sorry, no time to check) this framework is really MVC-like with single point entry (bootsrtap).
Whole bussiness logic and request proccessing stays the same for each company, only config is different.
For start You need to add one domain top-level url part (main folder or subdomain), then extract it as company name/alias/id from url request ($_GET) and use it as a variable to load proper config - db entry (at least), maybe activated modules (if not stored in db), personalized view (file prefix/folder name) etc. It all comes to small .htaccess & framework enhancement in (app) config loading part (variable path). The rest is just writing full working app for one hypothetical company with all modules activated:)
Your homepage (domain only url) would serve only as a dispatcher to concrete company then (It doesn't have to be framework based - even plain html with links would do), but it would be simpler than having another common database to serve as an automatic dispatcher to other dbs (not that hard thing to do, but I'd leave it for later developement).
Related
I'm building an application in Symfony which can be identified by two distinct portions.
The first is a portion that handles front facing information to users
The second is the heart of the application that is driven by a number of CRUDs, management interfaces and controls to manage the front end
Currently, the two components sit with the following domains structure
Front end interface: www.example.com
Backend admin interface: www.example.com/app
Ideally, it would be nice to address the admin interface as admin.example.com.
I've thought about using vhost configs to create a reverse proxy from admin.example.com to www.example.com/app however I feel like this is a messy approach.
I've also explored the host option in the #Route annotation within Symfony, however this is also very messy as I need to define this (and a number of supporting default and requirement options) in each controller.
The core reason behind running the same application is that I'd like to have both halves of the application driven by the same database and the same Symfony entities. I understand that I can build two separate applications and this would solve my issue, however this would then create two separate sets of entities between the two projects and ultimately the potential for errors down the track. I would like to avoid having separate applications if I can.
Thanks in advance!
I've come up with a solution to something with this kind issue. Posting my own response in case any one comes across a similar issue and would like to know how I went about it.
As I mentioned there will be an admin control interface and a front end interface. They will both look very different however one will be more application based (admin) and one will be more information centric (front end website).
I have opted to use two separate applications. However making using of the FOSRestBundle I am exposing basic information in the form of a simple API that will be driven to drive a snappy and responsive front end using information from the back end component of the application. The front end doesn't need to be a Symfony application, just something that can render content from the API (either generated server side, or a secondary request post page load via JavaScript - whichever is more fitting).
While this isn't exactly what I was initially envisioning at first, I realise this is the better approach as it would have made the application much more bloated and difficult to maintain over time as the application grew. It will also be rather easy to create a number of simple tests to assure that the data provided by the API is as the front end expects, to avoid any issues as the back end is developed.
Hope this helps anyone!
Background:
I currently have a web application based on MVC Kohana PHP framework, that allows users to sell ebooks to their customers.
The code behind the webapp is all wired together and everything but API-centric.
It is running pure MVC and then using mustache for template system.
What I would like to do:
I would like to integrate various accounting services (from bigger nordic providers like e-conomic.com) but also own integrations that will let users to optimize their selling and so on.
What I would like to archieve is to make something, call it an engine, that allows functionality integrate (flexibely) into parts of the webapplication, whether its in the view-part or controller/logic.
Based on the background and looking at the technical point of view, which ways are there to do this?
My thoughts is that I need some kind of placeholders all over in different areas of the webapplication. Then I need these placeholders to work together with a "engine" that then checks integrations wants to "run" in these areas?
Would that even work? What would you do?
Update trying to make it more clear:
So what I would like to accomplish is to have separate functionality that would integrate into the existing main webapplication.
Let's just say I have a folder called integrations/ and in here there is two different integrations that affect different parts of the system.
The first is a Kashflow (accounting software) integration, that grabs some data from our system and send to Kashflow (API way, fine) but also inside my webapp under "orders" states whether it has synced to Kashflow yet or not. (this is the part the question is about)
Another integration could be a "Featured Ebook" integration. This simply lets you pick what product should be featured and then on the ebook store, the featured product will be highlighted with a orange border around it and some bigger text. (this is the part the question is about)
How are the bold marked working? A webshop provider like Shopify has Apps which does this, and all other SaaS with Apps have this technical solution.
I wonder is it? How can I allow separate functionality affect a base webapp?
I hope it got more clear now.
New update:
What I look for answer is an answer based on the above stated background, how I can implement a solution that would allow this from where I am now.
A good answer would be one that also in text / pseudo way could give a description on how one of the example plugin/integrations i mentioned could be implemented.
So how does the integration communicate with the main application, what does the main application have in order to accept/allow functionality.
Let me start from the very beginning.
What you are looking for is called a service layer which should be implemented in your applcaition. What it does is
Defines an application's boundary with a layer of services that
establishes a set of available operations and coordinates the
application's response in each operation.
Enterprise applications typically require different kinds of
interfaces to the data they store and the logic they implement: data
loaders, user interfaces, integration gateways, and others. Despite
their different purposes, these interfaces often need common
interactions with the application to access and manipulate its data
and invoke its business logic. The interactions may be complex,
involv-ing transactions across multiple resources and the coordination
of several responses to an action. Encoding the logic of the
interactions separately in each interface causes a lot of duplication.
A Service Layer defines an application's boundary [Cockburn PloP] and
its set of available operations from the perspective of interfacing
client layers. It encapsulates the application's business logic,
controlling transactions and coor-dinating responses in the
implementation of its operations.
Let me explain it simple terms so you can understand. What you 1st have to do is define a service layer in your application. Since you are going with MVC, this could be another controllers handling all the requests related to this specific task. You can have separate controllers for each couple of operations. At the end your engine will be these set of controllers.
If you are willing to go to next level you can handle all these integration via an ESB(Enterprise Service Bus).
An enterprise service bus (ESB) is a software architecture model used
for designing and implementing communication between mutually
interacting software applications in a service-oriented architecture
(SOA). As a software architectural model for distributed computing it
is a specialty variant of the more general client server model and
promotes agility and flexibility with regard to communication between
applications. Its primary use is in enterprise application integration
(EAI) of heterogeneous and complex landscapes.
If you need more information let me know.
Update
There are well documented blog posts. Please see the links below.
How essential is it to make a service layer?
Service Layer Guidelines
Based on your update, I think you describe a good case for a web application that needs to become modular. You want to be able to easily add new modules (plugins) that give you different functionalities without having to change the application core each time.
Below is a possible solution to your challenge from conceptual point of view. My intention is to help you grasp on the idea and get you started. Keep in mind that it can be simplified further or become much more complex, depending on your needs.
The theoretical side of things
Plugins/Modules
Each plugin will enable a set of specific features and must be able to work independently from other plugins that are enabled at the moment. All plugins will have to follow a common set of rules and conventions in order to be recognised by your application. This will simplify future maintenance and extension immensely. For example, each plugin should:
Have its own subdirectory under the Plugins/Modules folder that follows a predefined structure (e.g. Backend/Portlets/InstallScripts, etc.)
Use separate storage sandbox in your database, dedicated only to this plugin. Take Kashflow – all tables that are used by the plugin can start with a ksflw_ prefix.
Bring its own partial Frontend view presentation(s) (along with underlying controller logic and model) that implement specific sets of functionality (for example, display pre-selected books in orange border)
Bring its own partial Backend view presentation(s) (along with underlying controller and model) that handle in the site backend (in the case of Kashflow you have portlet visualization that maybe renders a button to manually do synchronization, enables you to schedule one and displays the datetime of the last synchronization made)
Have an installer script, that creates tables, inserts menu items, and initialises hook subscriptions (see next bullet)
Initialize Hooks subscriptions – All subscribed Plugin functions get called whenever a registered event occurs somewhere in the system.
Core functionality changes
You will need new functionality in your existing application in order to start supporting plugins.
Plugin manager – GUI that allows you to install, remove, enable/disable plugins and allow access to them for your clients.
Partial views manager – allows users to select which partial views of which plugins get displayed in what existing placeholders (this will work in conjunction with hooks)
Placeholders for partial views on pages in the places you want to enable your users to display plugin UI and information
Hooks throughout the application – Whenever "interesting" event happens, the system checks if any plugins are currently subscribed to this event and calls/notifies them, then displays the result. Some examples of events that deserve Hooks might be:
Placeholder rendering – this will trigger all subscribed functionalities to display a frontend/backend partial view
Specific business events – e.g. Whenever new book is being added to the catalogue or is being sold
Administration menu rendering – On this event each installed plugin will select all menu items in the PLUGINNAME_AdminPluginMenu table (the plugin should have created this table at install time) and return all them to the hook for displaying.
I'm sure you'll think of other relevant events, as you know your case best of all.
The practical side of things (based on the second update of the question)
1. Leveraging HMVC for visualisation of partial views (widgets) inside of existing views
As I already stated earlier, Kohana supports HMVC or Hierarchical Model View Controller pattern. This means that you can have a hierarchy of controllers like so (already described in the following question):
Now, this enables you to easily call controllers from other controllers and even directly from your views! And it works wonders when you need to embed widgets.
You can make a slight modification to boostrap.ini in order to enable Routes like widget_controller/controller_action/action_parameter (this is described in detail in the tutorial I'm giving you below). Then you can have the following code inside your main view template where you want to render your orange book box:
<div class="widget_sidebar">
<?php echo Request::factory('widget_orangebook/display/3')->execute(); ?>
</div>
When executed, this acts as a hook and will invoke the widget_orangebook controller's action_display method with parameter 3 - e.g. you want to show 3 books.
The controller's action will look something like this:
public function action_display ($number_of_books){...}
As a result inside the <div>, you will see the content of the template set by the widget_orangebook controller after execution of the action.
In a sense it gives the illusion of an AJAX partial rendering, but its being executed on the server without the extra call. It is pretty powerful, and I think this is the way to go for the cases you described.
You can see this tutorial to see a detailed description on all the modifications you need to do. It's a bit fancier - it's about rendering multiple widgets in a widget section, but it follows the same logic.
Note that if you insist on using mustache and logicless templates, you can also do this kind of Request call in the controller, set the result to a variable and then pass that variable to your mustache template.
2. Kohana Modules
Kohana supports modules, that allow you to pack up your plugins in an organized way. As you implement more complex plugins this will become important. You can see more on Kohana Modules here.
We are building a intranet web application in PHP with CakePHP.
However we have barely experience with CakePHP
Our Intranet will have two user portals.
Employee portal
Client portal
Both portals will use the same data but have their own user interface.
Employees can see other data than clients and vice versa.
We want to build a central core for both portals. For example, a single authentication system, a contact form, a notification functionality, same footer information, etc. We want to use this central core as much as possible so we don't have to rewrite code.
We use Git to manage our code. We want to make a branch for both portals and one for the shared core.
We hope you can give us some advise about how setting this up with CakePHP.
Is building multiple app's a good idea?
Or should we just run CakePHP and our core on two web servers? (one for each portal)
Or should we use plug-ins for the core functionalities?
Or should we use single controllers with multiple views (one for employee and one for client?)
Or something totally different?
Thanks for any advice
Eventually, you'll start noticing similarities between the 2 portals, and the code-base. If they are sharing same data, why don't you have a single code-base and have permissions around what users can see based on roles? We had to do this recently when we merged 3 pages into 1. 1 page was for admin, and the other 2 was for other roles. Then users started requesting features on page 2 that page 1 already has etc etc. it became a mess and we decided to consolidate these pages into 1, and have permissions around what each users can see based on their roles. Also read more about helpers as it will come handy, so you dont make your view bloated.
In my experience a portal is typically a very thin layer on top of some CRUD framework. I think the opportunity for code sharing between these two applications is very limited. You can share the authorization and authentication .. and that's about it and I don't know if sharing this part is a good idea (probably not).
If most of your code goes into building the HTML views you'll likely end up with two completely separate views for employee and client.
As Ayo mentioned... the permissions alone will separate the two user groups and you can take advantage of CakePHP's layout or the themes feature to give a totally two different look for each user group.
You may also want to take a look at CakePHP plugins feature. It allows you to easily add new functionalists to an existing app, without messing with the existing code base.
I have a multilingual project,
the project is fully compatible with HE/EN languages.
In one case it's going to be uploaded as a subfolder in a big israeli project,
in another it's going to be used as a full site on it's own .com domain in english.
I currently have an SVN setup for the israeli project,
I haven't yet created an SVN for the .com, is this the right way to go, keeping 2 depo's for this ? I will then have to make sure that the code written on the israeli project is always copied manually to the .com folder,
Can this be managed more efficiently ?
Yes, this can definitely be managed more efficiently. This statement right here is the main problem:
I will then have to make sure that the code written on the israeli project is always copied manually to the .com folder.
That process is not only inefficient, it's highly error-prone. And it absolutely doesn't scale at all. Basically you're doubling your development/testing/deployment/etc. efforts. If you ever need to deploy another instance of the application, you'll have tripled efforts. And so on.
What you'll want to do is isolate the components that are different between the instances of the application. Is it just the language content? Is it the whole UI? If it's the whole UI then you'll want that UI to be as thin and light-weight as possible. (Well, you want that anyway.) Then all you'd have to double is the UI work. The rest of the logic (business logic, data access, services, etc.) can be constant across all instances of the application.
If it's just text content, then maybe you can re-factor that text to be pulled from the database. Every label, every article, every menu item, etc. There are CMS systems which do this pretty well, though I have no specific recommendations. But the overall idea is to have the UI be an empty wrapper populated by data specific to that application instance. Then each instance would control its "language" (its content in general) by simply managing that data.
You definitely don't want multiple code repositories for this. After all, if you have two repositories of code, which one is the correct one? If a change is made in one repository but not the other, which one is right? Your code should have a single "source of truth." Multiple sources of truth means no truth.
I see many MVC implementations for websites have a single-entry point such as an index.php file and then parses the URL to determine which controller to run. This seems rather odd to me because it involves having to rewrite the URL using Apache rewrites and with enough pages that single file will become bloated.
Why not instead just to have the individual pages be the controllers? What I mean is if you have a page on your site that lists all the registered members then the members.php page users navigate to will be the controller for the members. This php file will query the members model for the list of members from the database and pass it in to the members view.
I might be missing something because I have only recently discovered MVC but this one issue has been bugging me. Wouldn't this kind of design be preferable because instead of having one bloated entry-file that all pages unintuitively call the models and views for a specific page are contained, encapsulated, and called from its respective page?
From my experience, having a single-entry point has a couple of notorious advantages:
It eases centralized tasks such as resource loading (connecting to the db or to a memcache server, logging execution times, session handling, etc). If you want to add or remove a centralized task, you just have to change a singe file, which is the index.php.
Parsing the URL in PHP makes the "virtual URL" decoupled from the physical file layout on your webserver. That means that you can easily change your URL system (for example, for SEO purposes, or for site internationalization) without having to actually change the location of your scripts in the server.
However, sometimes having a singe-entry point can be a waste of server resouces. That applies obviously to static content, but also when you have a set of requests that have a very specific purpose and just need a very little set of your resorces (maybe they don't need DB access for instance). Then you should consider having more than one entry point. I have done that for the site I am working on. It has an entry point for all the "standard" dynamic contents and another one for the calls to the public API, which need much less resources and have a completely different URL system.
And a final note: if the site is well-implemented, your index.php doesn't have to become necessarily bloated :)
it is all about being DRY, if you have many php files handling requests you will have duplicated code. That just makes for a maintenance nightmare.
Have a look at the 'main' index page for CakePHP, https://github.com/cakephp/cakephp/blob/master/app/webroot/index.php
no matter how big the app gets, i have never needed to modify that. so how can it get bloated?
When deeplinking directly into the controllers when using an MVC framework it eliminates the possibility of implementing controller plugins or filters, depending on the framework you are using. Having a single point of entry standardizes the bootstrapping of the application and modules and executing previously mentioned plugins before a controller is accessed.
Also Zend Framework uses its own URL rewriting in the form of Routing. In the applications that use Zend Framework I work on have an .htaccess file of maybe 6 lines of rewriterules and conditions.
A single entry point certainly has its advantages, but you can get pretty much the same benefit from a central required file at the top of every single page that handles database connections, sessions, etc. It's not bloated, it conforms to DRY principles (except for that one require line), it seperates logic and presentation and if you change file locations, a simple search and replace will fix it.
I've used both and I can't say one is drastically better or worse for my purposes.
Software engineers are influencing the single point of entry paradigm. "Why not instead just to have the individual pages be the controllers?"
Individual pages are already Controllers, in a sense.
In PHP, there is going to be some boilerplate code that loads for every HTTP request: autoloader require statement (PSR-4), error handler code, sessions, and if you are wise, wrapping the core of your code in a try/catch with Throwable as the top exception to catch. By centralizing code, you only need to make changes in one place!
True, the centralized PHP will use at least one require statement (to load the autoloader code), but even if you have many require statements they will all be in one file, the index.php (not spread out over a galaxy of files on under the document root).
If you are writing code with security in mind, again, you may have certain encoding checks/sanitizing/validating that happens with every request. Using values in $_SERVER or filter_input_array()? Then you might as well centralize that.
The bottom line is this. The more you do on every page, the more you have a good reason to centralize that code.
Note, that this way of thinking leads one down the path of looking at your website as a web application. From the web application perspective, a single point of entry is justifiable because a problem solved once should only need to be modified in one place.