I'm working on a task management application for use at my company. Part of the spec is to create a plugin system that lets users customize and extend the functionality as they need, or as their department requires. I'd love to do this in a really elegant and modularized way, but I'm having a hard time figuring out how.
Consider a view that's a task list: each iteration of the generating loop adds a pre_task() and post_task() call on either end, which builds the interactive pieces on either end of the task title (Complete checkbox, comments link, etc). Now, when the system detects and includes the plugin file plugin_time_tracking.php, the plugin should add functionality to post_task() - adding a "track time" button in addition to everything else.
What I'd like to accomplish is making the plugin "hook" onto pre_task() or post_task() - let it do all the legwork by attaching itself to the proper functions and extending them, instead of having the core sort plugins and herd their functions to the right places. Does PHP offer such functionality? Am I going about this the wrong way? Let me know if I need to clarify at all - thanks for the help!
The boys of Qafoo gave a talk about modularity on the 2012 edition of the PHPBenelux conference. They presented various options to create modular applications such as hooks, patching and inheritance.
You could check out the slides of that presentation here.
I think you should really use a framework that has a built in plugin infrastructure with capabilities to override/inherit. As an example, let's say Symfony2: in sf2 you could create FormType classes that build the form objects (which then pass certain data tot he view). So in this case to add fields another team would simply need to extend your FormType and modify the build to add new fields. Further the Form Api supports embedding subforms so if they want time track then then just need to embed that in the task form or "turn it on" through whatever configuration facilities you supply.
Similarly with render things, you can define override the view template simply by providing at a different level or referencing a different Bundle (a plugin of sorts).
Now Symfony2 is very complex and it has a high learning curve so it may or my not be the framework you should choose, but something along these lines would be more than appropriate. The WP/Drupal pattern of "hook" functions is incredibly annoying to work with, especially if they are building HTML strings on a deeper layer and not giving you the raw data to output as you see fit.
Related
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.
I have a large complex web site currently implemented using PHP and MySQL.
Some of the pages (about, contact us, etc) are largely static, but need to be updated from time to time. I'd like these updates to be able to be done by non technical admins, so I'm migrating the site to Joomla CMS. I've created a Joomla template to reproduce the banners, styling etc of my existing web site and have successfully reproduced the static pages by cutting and pasting into Joomla articles.
I'm now trying to embed my existing dyanamic php pages into the Joomla framework. I assume that I need to convert them into one or more Joomla components? I realize that I'll need to strip out the php code that currently generates banners, menus, etc, but I don't want to make major changes to these php pages, i.e. I don't want to re-implement them to follow an MVC pattern. I'm looking for a simple Joomla 3.2 hello world component tutorial. The tutorials that I've found are either too complex (i.e. MVC) or they're "too simple". By too simple I mean the component is not listed when I select Menu Item Type within the Menu Manager. Can anyone point me to any documentation that explains the minimal config that I need to include in a custom Joomla 3.2 component in order for the component to be listed when selecting Menu Item Type?
Also, should I create one big custom component to wrap my existing PHP application containing multiple pages("views"?)? Conceptually there the system could be considered as about 3 sub-systems, but there is some overlap between the MySQL tables used in these different sub-systems.
I don't need the implementation to be portable, i.e. I'm not trying to create a reusable component that others could use, I just need it to work on my site, using the least amount of work possible.
Thanks, Wayne.
I hope to clarify a bit and give you way out.
In response to your comment on #user3057084, the power of Joomla and its flexibility comes from it being MVC! If you want to wrap your existing code with little modifications, Wordpress will let you do all kind of nasty things! Nasty in the sense of mixing logic with data, i.e. copying and pasting your code and getting it to work quickly.
Joomla coding standards require that you separate models from views. And that you understand how the Joomla MVC implementation works. It will take longer, but you'll learn a useful skill that can and should be applied if you want to write portable maintainable code following Design Patterns.
Now about the way out.
Nothing keeps you from putting your raw php code in a Joomla view, including the database access. It's really ugly and I feel bad even suggesting this, but if it can be a small step towards using a great framework, then the end justifies the means.
The absolute easiest way for you in Joomla would be to create a template override (which you'll do from the admin with a few clicks in the template manager), then throw your code in, and it will run. Then, a little bit at a time, you might learn to separate the parsing of the input in the controller, store / retrieve the data in a model, and leave just the markup in the view.
But are you absolutely sure you need to code for this? There are thousands of (free) extensions out there that might do the job for you with no coding and little configuration, leaving you just a data migration to handle.
Have you had a look at Wordpress yet? In my experience, non-technical people find it easier to administer a wordpress website in comparison to a Joomla website.
When it comes to the menu structures,themes and contact forms and blogs - Wordpress takes the cake.
It would be worth your while to check it out? It might save you hours of frustration?
I am creating a web application in PHP. It is built with multiple independent modules. For the sake of example, let's say there is an email module and file explorer module. Each of them have physically separate folders with different libraries etc. However, in the frontend they both have the same interface (navigation is the same and content in the center is changing).
I want to centralize my interface in the backend. How could I create some kind of two step layout so whatever app is called on the backend, the content of it is merged with outer interface and then sent back.
I want to make this because if there is a change in the outer interface, I have to copy code in all of the modules.
Below is the example mockup to show you what I mean. Content interface is changing and static outer interface is always the same no matter the app that is chosen.
How could I achieve something this elegant?
It could be worthwhile spending some time seeing how likes of Laravel 4 and other similar frameworks achieve this (if you haven't already that is).
For example in Laravel 4 it is reasonably easy to separate an application's business logic into modules, and share certain parts of the views across these modules using layouts, eg. you can create a master layout template that includes the master static outer interface as you show above, and then each of the individual module templates can extend this with a simple
#extends('layouts.master')
at the top of each of the content interface views. More details here - http://laravel.com/docs/templates
I am not suggesting that you use Laravel, but it is likely that you can find the answer to your question in one of the existing php frameworks - even if you copy their solutions rather than adopting the framework it may be quicker than reinventing the wheel :-)
Glen
I have a background in .NET and Perl, but have found myself working on a project where the customer is mandating Joomla. They would like me to setup a web site that will allow them to enter rental properties, which would likely include a large description field and a number of smaller metadata fields. What is a good way to approach this problem using Joomla? Would I somehow add metadata fields to articles for entry of rental properties? Would I need to create something outside the realm of an article (I'm thinking maybe a component, based on some intro training videos that I have watched on Joomla)?
My HTML and CSS skills are pretty solid, and I have a little bit of experience with PHP, so I don't mind getting my hands dirty. However, I'd like to get an idea of how a Joomla veteran would approach the problem.
Trying to tack meta information on to the articles is almost certainly not the way to go - for a ton of reasons. You are on the right track with a component. Consider designing a component with a back-end database, admin capability and a few front-end data-entry/information screens. The Joomla framework is a little cumbersome to begin with, but ultimately the MVC implementation makes sense and is quite powerful.
This tutorial at the Joomla documentation wiki runs through pretty much everything you need to know from a basic "hello world" to databases and more complex implementations. It sounds like the basic database-enabled example would get you really close to your objective. The example application builds on itself from one tutorial to the next, so it is not at all a waste to start at the beginning and work through it.
And a couple random bits of advice for a Joomla component development beginner:
One thing you may want to research related to data-entry is the JHTML class (the JHTML::_() function in particular). IMO the approach is less than intuitive, but using it is required to leverage built-in widget classes defined for the standard form fields in more advanced applications. It is also important for working with customized form field types and handlers.
Also, the objects returned by JFactory::getApplication() and JFactory::getDocument() have a ton of useful/important functionality when it comes to manipulating the Joomla application (like access to the JInput object). Get familiar with what they can do and remember how to retrieve them.
Good luck.
While building a component from scratch is the most flexible the initial learning curve might be too expensive (time wise) if you're not experienced with PHP and the Joomla framework.
Generally, if we're asked to do something outside our normal areas in Joomla the first place I look is the Joomla Extension Directory (JED).
From that I can usually find a very good solution or a very near match. If it's not a perfect match I can easily extend it (e.g. adding a plugin for a local payment gateway) or work with the developer to add the features we need to the extensions core). Which is probably a good way to start with Joomla, i.e. modifying or extending an existing extension.
You're lucky though, the area you're interested in has it's own category on the JED — the Real Estate section has 15 items listed and most them seem to have good ratings and reviews.
So, I'd start there.
You could make a form plugin for articles to add the extra field or to divide the body field into sections with json or using the profile plugin as a model you could add fields and store them in a separate table.
YOu could repurpose the contact component and use its many fields, or just clone it and change the names.
You could also use an advanced form extension.
This might be an obvious thing to you but - even after reading through a lot of manuals and blogs - I'm still not sure what exactly should a bundle in Symfony2 represent in a webpage. And it's hard to guess it from the simple demo applications.
For example: I have a site which is divided into two parts (one is just a 2nd level domain like example.com and another is dom2.example.com). Each of these two parts has some sections of it's own - sometimes the same (like news) sometimes different.
What would the correct representation of this in symfony2? Should I have
a MySite\site1 and MySite\site2 bundle and do the different sections via different controllers, or
bundles Site1\News and Site2\News, or
bundles MySite\Site1News and MySite\Site2News etc.
...or am I getting all wrong at this?
I am also new to Symfony and will follow the results of this question with interest, but for what it's worth, my take on it is:
A bundle is just that: a group of files, assets, PHP classes and methods, tests, etc. The logic of the grouping can be anything you like. In some cases, it's really obvious what the grouping is and why it's been done -- for instance, if I wrote a blog system for Symfony2 and wanted to release it, I'd make it into a bundle. That's the sort of example used most in the documentation.
But you'd also use bundles for anything you wanted to release as one little feature. Say for instance, this bundle which creates default routes for all your controllers. It's not a fully developed plugin/feature like a blog or forum, but it's a bit of code that I can easily import into my project, it stays totally separate from everything else, it's a bundle.
Finally, you'd also use bundles internally to your project, in absolutely any way which makes sense to you.
My take on your specific situation:
Quick and easy:
MySite\MyCode -- gets the job done, and maybe you don't have any logical way to break up the code you're going to write.
If there's some more unique features between the two sites and you want to separate them out for clarity:
MySite\SharedFeatures
MySite\Site1Features
MySite\Site2Features
If you really like everything in its place, or if you have a complex project, maybe:
MySite\MySiteMain (shared features and catch-all miscellany that doesn't deserve its own bundle)
MySite\News
MySite\Site1FeatureSomethingOrOther
MySite\Site2FeatureSomethingOrOther
I definitely think you want to stick to logical groups of code -- so I think your example "bundles Site1\News and Site2\News" and "MySite\Site1News and MySite\Site2News" wouldn't be the best way to go. Site1 and Site2 are implementations, so making a separate bundle for each site's news page would seem to be counterproductive to me; you'd want to make one news component and build it to be used in two different ways.
As for your two-domains question, you can either point both domains at the same code, and test within your code for what domain is being requested, or you can check out two copies of the same code and change the configuration files slightly (this doesn't necessarily violate the idea of DRY because you'd still edit the code in one place, then update both copies.)
The way I understand a bundle is that it is similar to what CMS like e.g. Typo3 or Drupal call a "plugin". So it should be ideally self-contained and written in a way that it can be used on other projects too.
E.g. in your case I'd create a "staticHtmlBundle" that contains all the static pages of your website, divided within by site.com and dom2.site.com.
Then I would create a "newsBundle" that contains all the news-articles, maybe even database-driven with a little admin-section where you can edit them and assign them to different channels (in your case that is site.com, dom2.site.com). A static page from within staticHtmlBundle would call newsBundle and display its data (like e.g. a listView of the news or a detailView and so on).
If you keep everything as abstract and reusable as possible then you could even publish the newsBunde in the Symfony 2 Bundle repository and share it with the community!
The way I perceive Symfony2 bundles is that they are provide a modular system which allows you to not only extend and override the php code, but also any resources they may or may not include.
Having said that, consider you have an API and you would like to transfer an object.
How would you do that?
Of course, you can do that manually, but wouldn't it be nice if Symfony can do it for you?
My way of doing this would include 3 bundles, JMSSerializerBundle and FosRestBundle.
One bundle for the client side - MyCompany/ClientBundle
One bundle for the server side - MyCompany/ServerBundle
One bundle housing all the data transfer objects I would like to be able to transfer - MyCompany/CommonBundle.
Inside my MyCompany/CommonBundle I would have the classes I would use for my data transfer objects along with the serialization rules I would have to provide the JMSSerializerBundle with. They may be in the form of xml, yml or php annotations.
Once you have an object filled up with the data, you can just use return and FosRestBundle would serialize it for you. Serialization would depend on the routing, so you can have the object serialized in XML for one system and in JSON for another. Key point is you have different serialization formats and versioning you can utilise at later point.
On the client side, you can use simple param converter to convert the received JSON or XML to an object right in the controller with no additional hassle. You can also type in some validation rules, so you can verify if the object is populated as you expect it to be.
In my example, the MyCompany/CommonBundle has objects that would be used by multiple applications and would be identical. Having that as a separate bundle helps you avoid code duplication and makes long term maintenance a lot easier.
I hope I managed to explain this. Any questions?
Ask in the comments. Will update the answer accordingly.