We are currently bringing an online business software to other EU markets, where not only language but also rules and regulations differ from country to country which made me wonder, what is the best way to implement such in a software?
The UI localization isn't really a problem - done that more times then I could care to count, but for example while invoicing countries tend to require different data (well not totally different, but different enough to make you think about it architecture wise) meaning different inputs, different validations and somewhat different handling of that data.
Which way can be considered better?
The standard way of localizing UI and adding the needed conditional statements for showing extra and hiding non-essential elements with similar conditionals in the Controller classes
Creating a copy of the app for the given country with slightly altered controllers and views (which will make the constant updates a nightmare, but the code much cleaner)
Trying to somehow create a Factory/Builder pattern around this?
While the last one sounds most reasonable to me, it frustrates me even more, as I have no clue on where to start yet. Any good pointers on that?
Language of the choice is PHP with Laravel
Definitely do not make different copies.
Have a look at your current database architecture and see how you can expand it to fulfill your requirements. Then rewrite or update the business-logic code layer of your application.
Then you will only need to make minor adjustments in the front-end.
This post is some kinda old, But the title is general and could be found by some others via search, so I wrote my answer in the following:
I think it's totally based on your architecture. In recent years, peoples are following different principles to break-down the whole application into meaningful microservices with specific tasks and boundaries. This mindset would help you to analyze the whole business process and the places that you may need to do some customization for each customer or country.
for example, for product catalog or inventory management, the processes between each country may not differ. but in the payment or order management, invoicing you need to do small modifications which would be quite easier while you are following a microservice pattern. Furthermore, you can have your own plugin loader structure which lets you modify, override and extend each instance by having a filter/hook feature in your application as you might have seen in WordPress and other opensource platforms.
Related
At my company we have a web application that we have been developing for over 5 years. We still have a codebase that contains PHP4 and has been extended with loads of PHP5.
The LOC is pretty big, about 471k. It is not based on a framework, ORM, etc, etc.
The developers who started of with this project ignored any i18n and translations. All the language texts are hardcoded in the software. Yes, I know this sucks big time.
At the moment we're fine since we only sell this in the language the software is written in but we're also looking at expanding abroad.
I'm struggling with the best approach on dealing with the translation.
How would you guys approach this? Would it be better to rewrite using a framework since that would probably also improve the codebase and providing a solid structure. Or would you just use the current software and filter out the language texts.
Any tips and hints on this subject are appreciated!
I think both variants are possible. You can leave your code, or rewrite. But as you know rewriting is a long process, in spite of that fact you've writing it for over 5 year.
If it's still stable, works fine, and PHP4 and other 'tasty things' you don't need, you can leave and just review all hardcoded texts. i18n helpers are very easy to make. You have to do nothing more then:
Choose appropriate way of storing texts and translations
Caching mechanism for already loaded translations
Class and helper for i18n operations.
You should analyse you bussiness plan well, if you decide to rewrite you code.
Still got an additional answer. Translating almost identical strings is very costly. Multiply that with the number of languages and one realizes: a good internationalization with sharing of same strings, and maybe formats, is really more efficient.
A first rewrite of the templating part, probably makes sense. First by hand, then with an automatic conversion tool written by you. It should prepare I18N.
In my experience, it's not a good job to have a single project with two major goals - especially if those goals are almost entirely unrelated from a business point of view. I'd have one project team responsible for localization (which may well involve more than just translation - different countries have different legal requirements, currencies, payment providers, etc.), and one team for "improving the code base".
I'd start by having the localization team work out a rough plan (and cost) for "the simplest thing you could do" - retro-fitting localization functionality into the site as it is right now. Unless that cost is unacceptable form a business point of view - I'd go down that route.
If the business case for refactoring hasn't been made, I'd not try to shoe-horn it into your localization project - I've seen similar things happen before, and all the developers wanted to work on the cool refactoring stuff, talk about the relative merits of various frameworks, and which source code control system to use, while the thing the business cared about was pushed to the future; eventually, the business owners lost interest in the project, and cancelled it.
If there really is no realistic way to do the localization without a refactoring effort, I'd still run it with two, separate teams. The localization team can be a primary requirements owner for the refactoring team, and they do need to work together - but by keeping the two projects running independently, you avoid the risk that you get 90% of the refactoring done, but only 10% of the localization.
It sounds like you have more than a translation project ahead of you. If you're wanting to take it abroad, you'll have to redesign at least part of the system.
If your budget allows for it and the benefit justifies it, you'll want to step back and take a look at the overall design. Keep what you can, but don't be afraid to rip out, redesign, replace and upgrade major portions of it.
Much has changed in the last 5 years, so if it's an app that you plan on selling for many more years, it's likely worth the investment in redesign.
It depends on what the priorities are, as to what you should do.
If the main concern is the language translation, then you can start with just taking out the hard-coded strings so they can be internationalized.
If there are other needs, such as wanting to easily support different databases, then that would help determine if there is a better approach.
I am creating the cms for a relatively simple site - portfolio, some general content pages, custom blog etc.
What are some of the best patterns to consider before diving into the design.
I want the system to be as flexible as possible without being too complex.
I have looked for some good resources that discus cms and blog design but can't find anything too good.
My language is php but I suppose I am looking for more language independent advice.
Flexibility without complexity... nice program.
Maybe you're a genius and you will make something that feet your needs. But I think the biggest problem you will face is security and robustness. So really, take other advices on this page and have a look at wordpress, drupal, joomla and ezpublish. A lot of security stuff is already done. And not only security...
So, study some of these tools, track their flaws, check their security policy. Study how they handle caching, sessions, bootstrap, absolute & relative url managment, documents (images, videos, etc), ajax, authentification, identification, acl, user interfaces, rich-text editing, migrations, templating, page composition, content filtering (I try to remove the things you won't need, plugins, database abstraction, fine caching, css and js minification, all the extra-complex stuff not needed for a single instance simple CMS). Soon you'll have a 'picture' of the stuff they've done.
By doing this work, you'll certainly notice some big differences, and mistakes. You'll start going on irc and flaming developpers, telling them that others have done better choices. You'll start forgetting to shave. You'll maybe do some contributions. Some will be accepted, others won't. Old core devs doesn't like when someone explain why they made mistakes (and they make mistakes).
Now, comes the day you have a beard. Some of your contributions will start looking like forks. You will have ennemies, and friends, or followers. And you will start feeling the force.
And you will go on irc and tell god that the world is ugly and that you'll make the first CMS which will be flexible without being complex. And people will cry. And birds will run in circles. And you will be able to explain what are the design pattern of a CMS.
I am a user. I know what I want. Doing what I want will make user happy. I'm happy.
You shall not trust code from people with glasses
"MVC MVC MVC" : and the people responds 'that shall be done'
Seriously, There's still a place for a good CMS with disruptive innovation, the fork history has started long time ago with phpNuke (as far as I can remember). But some of the actual products are really fine for most tasks.
I'm probably risking the reputation here, but my experience shows that building your own CMS can be a very justified decision, especially when you get familiar with current opensource systems and understand what exactly they lack in terms of features, security or what not. Open-source often means a lot of backward-compatibility concerns and bad architecture decisions that cannot be easily changed.
I strongly suggest that instead of just taking on MVC you take a look at ideas that make it attractive.
One main problem with CMSes is the range of technologies involved in driving dynamic web-sites: imperative php for logic, declarative SQL for data queries, markup HTML for interface, imperative/functional javascript for dynamic interface, JSON for ajax calls etc. To keep the system manageable you have to keep these technologies in a controlled and understandable environment, but yet allow for smooth integration. Knowledge and best practices are out there. MVC is but one approach to manage this problem.
My choice at the time was to use the following principles:
Object-oriented code with static calling (php is a one-run thing, many instances of code objects are rarely justified), nothing except for one line of init code in global context
100% code-design separation with the use of XSLT and custom content processor
Custom router that can take any http request and reroute it to registered methods
Custom content processor that can take arbitrary method output and convert it into any usable format such as xhtml, xml, json etc. based on the request parameters (i.e. http://local/class/method.xhtml, http://local/class/method.json)
One copy of code for as many virtual web servers as necessary
SQL query builder (chosen for flexibility over ORM) for all database queries
Mandatory filtering of method input with filter_* functions
I believe you can choose a few that you like :) And good luck!
A good pattern to start with is the Model View Controller pattern, or MVC.
This pattern suggests to seperate your application's logic in the following layers: data logic(model), manipulation or business logic (controller) and display logic (view).
This is a good pattern to start with as you'll run into other problems (and thus patterns) along the way.
The following website explains the MVC concept quite well: MVC Principles
There is no point reinventing the wheel unless you are trying to better it in anyway.
THere are a lot of CMS available already. I personally have worked with ezpublish. There are other options such as drupal etc. This is the list of all open source cms avaliable - Click here
If you are just trying to learn then you can perhaps pick any one of the popular opensource and work on them to find its architecture and design.
Besides, I dont think anyone can give you a list of design patterns that would be best for a CMS tool. Because each design pattern solves some particular problem. And, you just have to choose a design pattern depending on a specific problem you want to solve in your project.
These days, writing your own CMS is a horrible waste of time. The usual open source solutions -- these days Joomla, WordPress and Drupal are popular -- are written by thousands of people and while you might loose a little flexibility by using on that's ready made this is by far offset by not needing to redo everything from scratch. If you go with Drupal, you can also enjoy high quality, massively scalable etc code :)
If Your rquiremnt is portfolio, some general content pages, custom blog only, Wordpress will be simple and Better.
In PHP so many CMS available , most popular one is Joomla.
I am building a website with individual user customization in mind. So for instance, client #1 may say i want this feature to be designed for my account and then user #2 may say i want this added to my account. I was thinking of implementing a php if code where upon authentication those features will be loaded each time they login. But i have hundreds of thousands of customizations that i will be doing, to add each php code for each client will be terrible, is there a way i can do it more easily and with less stress?
Added from comments to particular answer:
"Basically i am running the technical side of a business intelligence company. We offer various reports and information along with a dozen analytic tools. So one user might say i want all that you offer plus a custom feature where a particular area of the business is being analyzed and then upload to their account. As you can imagine there can be hundreds of such requests for a lot of accounts."
Your best bet is to either design yourself a framework, or find an existing one that supports this level of customization. Either way, it's not a small job, and launching code for each user leaves you prone to security issues and bugs arising from out-of-date methods as time goes on.
Ask yourself what kind of customizations you're doing, and if they can be abstracted away from the code level by (for example) a templating system.
Designs can fit in certain generic requirements. So until and unless you have some generic requirements, you can not do the design. For example, if requirement is for different look and feel for each client, you might go for dynamic theming. Similarly, for positional changes for different users, you can think of user profiling. For language, also you can keep the user language as part of the profile. Study different approaches for user profile management and then take a step ahead.
As others have said, its impossible to give a specific answer without knowing a lot more about what you mean by "Customization". The only sensible answer is the one you've already provided - i.e. to implement as much as possible of the variable behaviour in data.
This in itself may not be a trivial exercise - on one application I worked on, I designed a heuristic artificial intelligence engine (in PHP) which was hugely successful - but this was a fairly complex exercise in software engineering, and one I'd be hesitant to recommend to anyone who needs to ask the question.
Assuming that pushing all the application logic into data is not practical, then there are some other approaches you might consider, e.g. splitting the customizations into seperate php files (or templates if its just a display thing):
<?php
session_start();
/* do authentication checks...*/
$app=$_SESSION['user_profile'] . '/' . dirname($_SERVER['SCRIPT_NAME'] . '/inc.php');
if (! include_once($app)) {
include_once('default/'.dirname($_SERVER['SCRIPT_NAME'].'/inc.php');
}
...
Although it would be posible to store php code in a database and eval it at runtime - I'd not recommend this as it opens the door to code injection attacks. OTOH, it may prove easier to implement the customizations in a different language and call that from PHP e.g. prolog.
C.
I have been playing around with the concept of 'module' that some mvc frameworks implement and it seems like a good solution, and also with TDD, but I think there must be something more, like a design pattern I missed (I only know a few), that will let me build applications that can grow (in code) with no limits.
Any thoughts?
edit : Another good thing about modules is that they can be built in a way that they are application-independent, so they can be reused.
In "Facts and Fallacies of Software Engineering," Robert L. Glass says:
Fact 15. Reuse-in-the-small is a well-solved problem.
Fact 16. Reuse-in-the-large remains a mostly unsolved problem.
Fact 17. Reuse-in-the-large works best in families of related systems.
In other words, you can reuse modules, but only between applications that work very similarly. Trying to make modules so versatile that you can resuse them in any application is too hard. You end up making modules that are so configurable that they're overly complex to use, and contain lots of code to handle scenarios that are of no use to a given application.
You'd be better off coding a custom module for each application, that does just what that each application needs, and no more. This is especially important for a language like PHP, where code is loaded on each request, so the volume of code has a significant impact on performance.
Reusing more fine-grained functionality is different. The uses of say, logging, is reasonably similar between applications no matter how different the applications are from one another. This is why most frameworks do really well with general-purpose service-style classes.
Re comment from #A_Var:
You can make a class reusable if you know the range of possible functionality in advance, and therefore the parts that need to be extensible. This is relatively easy for a simple class that's used similarly in every app. I mentioned the example of logging. This is what Glass refers to as reuse-in-the-small.
But we're not talking about simple classes. If you try to do the same thing with a complex module (think of multiple classes to handle multiple screens, forms, different database schema, etc.), it's too hard to write the code to be generic enough to cover all the specific needs for each application. You end up needing more code in the generic module than the sum total code you'd need to write separate modules for each app.
Also, testing becomes very costly, because any change you make to the base module requires that you re-test all the apps that use and extend it.
In the end, it's less work to write a new module for each app, and you can gain what efficiency you can by employing reusable components that are more fine-grained.
Sorry for the confusing title....
We are developing an application to be used by multiple companies. For the most part, the application is the same, your standard sort of database manipulation pages (search pages, edit pages, etc.) customized for the data that it is designed for.
However, each company has a slightly different process, and we will be dealing directly with each company so we'd like to use some sort of system that would allow us to tweak pages depending on which company is viewing the page. For example, one company might want a couple extra fields on a data input page, or another company might want to view a different piece of data on a search results screen, and so on.
I understand this is all hypothetical and I wish I had a concrete example to give you, but honestly the companies haven't even given us very good examples. We just want to be ready.
So my basic question is, what is the most flexible way to allow for these tweaks and customizations on a per-company basis? Obviously, the most flexible but least programmer-friendly way would be to make a complete copy of the app for each company. This obviously isn't an option because we'd need to manage updating code on all the sites, trying to keep them all running and tested and having issues resulting from the customized code.
What are your thoughts on Smarty being a solution to this? Perhaps if we have a master set of templates, but then each company can have a different subfolder with any replacement template files... Of course we'd still need to update a bunch of different template files whenever we change one of them, but it would be a little more localized anyway.
Is there a better way? Some sort of differencing template engine maybe, so that we can still edit the original files and the changes will adapt on top of the originals (kind of like a patch)? Or perhaps we should use the object-oriented features of PHP5 and then use polymorphism? What is your best suggestion, and especially if you've had experience with this sort of thing, what are the options and which have you used and why?
I think the template method pattern will help you out a lot. It's really a great pattern for factoring stuff that is mostly the same but differs in a few places. I'm actually working out a template method hierarchy for my own project right now.
I would suggest you try to create the application either using an mvc framework or using your own implementation of mvc.
In this manner you could create models that could be reused (and also views) for other companies.