Edit: I noticed that there have been 40 views, but no responses. Have I asked for too much? Does anyone have any thoughts or points that are responsive to part of what I am looking for?
I am looking for a software library (open source or commercial) for my company that meets the following specifications. A bit of background first.
My company provides cloud-based software that, among other things, allows users to create ad hoc database tables, similar to SharePoint lists, and store any type of data there. Assume, for the sake of argument, that the data can be accessed through a regular SQL query, against either a table or view.
We want to give our users the ability to visualize the data stored in these ad hoc tables by creating their own charts. Our end users will not have any technical abilities and no coding should be required to make this possible.
Our software uses java on the backend. Clients access the software thru a browser and typically no plug-ins or add-ons are required.
Here is what I am looking for:
A library that can create a very broad range of charts (pie, bar, etc.), not just 1 or 2 kinds, and fairly complex versions of those charts.
Whether the charts are created on the backend (in java) or on the front end (using javascript) does not matter.
The end user should be able to use a wizard to design the chart. This includes not just what type of chart and the various chart options (labels, colors, etc.), but also what data fields will be used to construct each part of the chart. For example, the end user might select a pie chart, then select a specific data source (e.g., Store Sales), and from the data source they can select the columns that will be used as the pie dimension (the slices) and the pie measure (the size of each slice). This does not necessarily require that the library have access to the data source, as the fields in the data source and the datatype of each could be sent to the library (be it in java or javascript).
Finally, assuming the data is stored as a regular table or can be accessed as a SQL view, once the fields have been selected and the various aggregations defined to create the chart, the library should write the actual SQL code that will be required to query the underlying data. The end users cannot be expected to write the SQL code themselves.
I believe there are some SharePoint add-ons that will write the necessary queries to pull data out of a SharePoint list to create the charts. Something similar to that, but not SharePoint-based.
Mark,
I'll try and answer this to the best of my knowledge (Disclosure: I'm the co-founder & CEO of FusionCharts - where we make JavaScript charting components).
I've split my answer into 2 parts:
How to find a charting component for your web application?
How to build the UI for end-users to modify the charts created by these libraries?
There are three ways to add charting capabilities to your web application.
Using server-side charting libraries
First is to use platform-specific charting libraries that accept data on server through their APIs, create images to represent the chart, and then stream these images. Examples of such components are Telerik (.NET, paid), Infragistics (.NET, paid), ComponentArt (.NET, paid), ChartFX (Java, .NET, paid), Steema (.NET, paid), pChart (PHP, free), jPGraph, and a whole bunch of them.
The advantage of using such components are:
Mature libraries offer a huge variety of chart types
Since the charts are generated as images, they work everywhere, including mobile devices
The look & feel always stays the same, again by the virtue of charts rendered as images
If just one or two charts are served per user across entire application, lesser bandwidth is used compared to client-side libraries which could range from 50-500KB in size, but get cached thereafter
Disadvantages are:
Considerable resources are used at server-side when generating charts as images. More so for applications that have many concurrent users
Interactivity and animation offered by the charts are very limited, as there's only so much you can do with images
They are technology specific. So if you're using a library for ASP.NET, if/when you move to Java, you'll have to switch to a different library, and hence the look, feel and featureset would differ.
Using hosted charting APIs
Second option is to use hosted charting libraries that take in data over querystring/REST API and return chart image back to your application. Examples would be old Google Charting API.
Advantages of this are:
You do not need to host the charting library, and hence all maintenance and upgrade issues are managed by them
When you change your technology stack, the charts are still delivered by the same service and hence look & feel are same
Disadvantages:
Such services do NOT offer a variety of chart types
Confidential data needs to be transferred over HTTP outside your servers to such providers
Limitations on amount of data that can be sent over querystring
Again, charts cannot be interactive, as they are images
Client-side charting using JavaScript, CSS, Flash, Silverlight or Java applets
The third and last option is to use client-side charting libraries written in either JavaScript/HTML5, Pure CSS, Flash, Java applets or Microsoft Silverlight. Considering the fact that iOS devices do not support and proprietary plugins, Flash, Java and Silverlight based plugins do not work on iPads and iPhones. So you can safely to ignore them. Pure CSS components are very light-weight and can be used for very basic visualizations.
That finally brings us to JavaScript/HTML5 based charting components. There are a whole bunch of JavaScript charting libraries, both free and paid. I've listed some of them below:
Paid: FusionCharts Suite XT (JavaScript), HighCharts, amcharts, AnyChart, Jqplot, ZingCharts, Wijmo, TeeChart, Sencha Touch Charts, RGpraph, Kendo UI DataViz, JSCharts, Arcadia Charts, jQChart, EJSChart, emprisejs, techoctave
Free: FusionCharts Free (Flash), Google Chart Tools, Yahoo UI components, Flot, Milkchart, Moochart, protovis, graphael, elycharts, smootiecharts, dhtmlxchart, grafico, canvasjs, dygraphs, thejit, awesomechartjs, jchartFX. More free components based on d3.js for data visualization: xcharts, nvd3, rickshaw, cubism.js, Dc.js, xkcd, graphene
Now, given the number of components available, the questions you need to ask yourself when narrowing done for a charting component should include:
What chart types would you need - now and in the future? If you need very basic charts like column, pie etc., most of these libraries fit the bill. But if you need even slightly advanced charts like Pareto or Funnel, most of the components do not offer such charts.
How important is for you to have the charts rendered on maximum number of devices and older browsers like IE6? Many open-source libraries just use SVG for rendering, thereby not having support for IE6,7,8 (which 6% of the world still uses).
Can you use the part of your product where you implement data visualization as a USP during demos? If yes, how important is the look & feel of the charting component to you?
Are you looking to spend considerable amount of time tweaking the charts for basic features? For example, many open-source libraries enable tool-tips upon writing additional code, or the fact that if you've >25 data points on chart, x-axis label overlapping needs to be taken care of by you. Or, do you want these capabilities out of the box, so that you can focus on your application and business logic?
How important is it for you to be able to customize each and every feature of the chart, including cosmetics? For example, do you need to be able to render the charts in 3D, customize how the number gets formatted, control gradients etc.?
Do you want a component with an exhaustive documentation and real-life business demos so that you can get started easily, or are you ok with minimal docs and learning by experimentation which could take a lot time?
Is it important for you to get personalized support when something doesn't work as expected, or are you ok with posting on public forums and not having an SLA for a reply/fix?
Hoping that this information would help you choose a charting component for your web application, let me address the second question: Is there a component that comes with a client-side wizard for end-users to design the chart?
For the client-side charting libraries, the short answer is NO. Because, it ties the client-side library to a particular server-side technology for data persistence, and secondly not many users have need for it.
Some server-side libraries (Dundas used to have this capability) do provide this capability, though not all features of the chart can be customized at client-side.
That being said, many developers have created such wizards for use by non technical users. For example, at FusionCharts, we have created wizard for SharePoint which is called Collabion (see www.collabion.com), and PowerPoint which is called oomfo (www.oomfo.com). While these are not open source, we would be happy to share code of these, if you find them relevant.
Another option is to use an open-source BI component (like Pentaho, JasperSoft etc.) that have charting components in-built and also provide a wizard for end-users. However, they could require considerable server resources per user, and are time-taking to install and maintain.
Hope I've been able to answer your questions.
This sounds like a "build vs. buy" question. I'm interested to know if you have looked into comprehensive business intelligence tool like Tableau, qlikview, jDashboard, or LogiAnalytics?
Of course buying a pre-built solution will come down to constraints- can your vendor work with you on these? Or allow you to build minimal add-ons to address them? This might achieve many of your application's goals but have a higher upfront licensing cost.
Purchasing a visualization library or downloading an open source lib would provide one of the many materials you need to build the application you've described. This would have lower licensing costs but require building out the rest of your requirements around it.
The decision you need to make is whether you have the patience and ability required to juggle multiple libraries and handle custom coding, or whether you would be willing to pay for a complete solution that satisfies most but not necessarily ALL of your requirements.
Your requirement seems to be two-fold from my perspective. I would share my views, though I am not sure if it will help you.
You need a charting component that is diverse in nature, easily configurable, robust to extreme tinkering by users and looks good even in worst case scenario. (I assumed many items here since it is evident that users would be creating charts and thus it can be highly far-fetched.)
A visual editor (preferably wizard-style), that can be used to create and configure every aspect of such charts from exiting data sources.
Since your application is for creating and store custom data sources (as far as I could figure,) using a BI tool as overlay makes less sense since the nature of data is too flexible to conform to any source standards.
If my basic analysis is correct, then the following is my advise on a respective bases:
For such a comprehensive requirement, you would need charting solution that specialises
in visualisation and is a visualisation component taking care of your charting needs.
The only component that I see that meets your requirement is
FusionCharts. The reason being that FusionCharts is designed to
cater to enterprise customers with high fault-tolerance on input and
yet look appealing. (I can elaborate with examples or you can lookup the website
http://www.fusioncharts.com/.)
Sadly, there is no such component that comes inherently paired with such a capable
visualisation front-end. This primarily because most charting solutions provider caters
to consumers whose use-cases involve the chart generation to be on their own end.
You do have Dundas Chart Builder - which IMHO is not web-based and
jsCharts chart editor - whose visualisation front-end is not as comprehensive as
your needs and I am not sure if they sell the editor.
Having said that, there is another product from FusionCharts called Collabion.
The product uses FusionCharts to render charts and connects SharePoint data sources.
The interesting part is the visual chart builder that it has. It allows you to fully
customise the appearance and functionalities of FusionCharts and configuration of
data sources. Visit http://www.collabion.com/ and you can check out the screenshots.
Collabion is primarily intended for deployment on MicroSoft stack (SharePoint), but
your requirement is on Java. IMHO, if you go to that length, you can run an instance
of SharePoint and communicate the process. (Just thinking aloud.)
Indeed, FusionchartXT matchs your requirement, but you need a web-based FusionchartXT editor too. It must allow your customers optionally configure their charts attributes, cosmetics, dateset, and trend lines, just like this: http://www.crossui.com/FCEditor/.
Related
We are done migrating a website from old CMS to SDL Tridion. We have thousands of clients out of which fewer than five are migrated. Now let's say we need to automate migrating the rest of the thousands clients, obviously we can not use manual effort. Is there a way to develop automated solution against SDL using any APIs it may provide? If yes where can we find documentation for APIs? Any Books or online tutorials for the same?
all very technical answers. Whatever route you choose you need to weigh up the option of not doing a technical migration (and trying to get that right) versus employing a load of students to copy and paste.
Regardless of the CMS, the complexity of a migration can be measured based on how organized is your content in the system you want to migrate from.
I categorize the migration into 3 types related to the Origin and Destination:
1--> CMS to CMS
2--> Database to CMS
3--> WebSite to CMS
If the original source is a database or another CMS typically the complexity is reduced, as the content is already structured.
You have to extract that and map the existing content with the structure that will have in the new system
If the goal is migrate an existing website into a CMS the complexity increases as the content is more disorganized that
having that in the CMS.
Again, if the content in the site is properly structured is still possible to automate that, but most of the cases are old sites
maintained manually.
There are commercial tools that crawl the content from the sites and apply patterns to identify common elements, common content, common metadata, structure
and are able to massage the original content and apply logic based on rules that allows to structure the content, however even the best tool has a hard
work to do when the source is disorganized.
Also I have seen migrations that cut the final html in pieces and put that in the CMS. That is an easy approach but of course a wrong one, as
you are not taking any advantage of the CMS
And 3 Types related the source type we migrate from and the source type we want to obtain
1--> Content to Content
2--> (HTML + Content All together) into (HTML) + (Content) separated
3--> (HTML + Content + Code All together) into (HTML) + (Content) +
(Code) separated
Content to Content Migration is less complex
Second option is of course more complex, as you have to Separate Content and HTML that will become templates
Third option is even more complex, as if you are extracting the html of the page (using an http client for instance as most of the commercial tools do),
you are not capturing the logic of the page. For this case you need to work at the file level
Try to do a very depth analysis before you enter in a migration, as things can turn complex.
Only if you have a very good knowledge of the original system and solid patterns to apply you can think in an automation
Tridion has extensive APIs and these are thoroughly documented. Your starting point for SDL Tridion 2011 is https://www.sdltridionworld.com/downloads/documentation/SDLTridion2011SP1/index.aspx
Automated migrations are perfectly possible, however API support is not the limiting factor here. Understanding your data in your source and target scenarios is much more important.
I would consider contacting Kapow or Vamosa who both specialize in crawling sites and then importing them to a CMS. They both have connectors for SDL Tridion. This may save your clients both time and money.
Every migration is different, unless you are migrating "thousands of" sites (assuming a client is a site) from same source type to same destination (SDL Tridion in this case) with extremely close data models. Several SDL Tridion partners are already solving this problem and built/building assisted migration automation tools. Get in touch with us if you need more information.
We are looking for a Asp.net CMS to integrate in our existing Enterprise-Webapplication. Some requirements:
Full integration in Visual Studio 2010 and our existing Application (so no Umbraco)
Common ASP.NET Web Forms Developing practices (Global.asax, Masterpages, User-/Custom-Controls)
Security (FormsAuthentication, custom Membership-/RoleProvider)
Very flexible and extendable (good API)
Lightweights CMS with good performance (thousands of simultaneous requests)
Easy content editing
At the moment we are looking at Sitefinity and N2CMS.
I really like the N2CMS approach (Integrate CMS engine in application) but is it mature enough for "real" usage scenarios? Is there another alternative to N2CMS?
Yes, N2 is mature. Company I work for is using it for more than three years now for various projects, and it is still our platform of choice. Best thing about it is that it is not CM System in a classic manner but rather CM Framework with several layers, meaning you have many things implemented, but they are not part of the core. As a result, you can change almost anything that is not usually changeable in other CMSes.
Also, whole architecture is organized in such a way that you can easily override almost any system behavior with your own implementation. Example? Imagine you reached 100s of news entries under News folder in site tree, and you decide to completely hide them from site tree, instead implementing plugin for manipulating them. Solution? Attribute-decorated class with 10 lines of code for hiding items in a tree based on your custom rule expressed in C# code.
I think N2 is pretty polished product and that you can go for it without too much worries.
We too are using N2. We've used it for a campaign site and now we are building our companies corporate website and the 20-or-so country specific subsidiary sites.
It is very fast to develop on (if you are a .net programmer it is a treat, an html-guy might find it difficult). Extremely flexible and extensible. And so far it seems to be very mature and stable. It has less features in terms of workflow-management than e.g. sitecore, but then again most customers put a lot of emphasis on those things, when they evaluate options, but end up not using them. So I don't think that is a problem.
The problem we are having is that it doesn't properly support preview, so website editors cannot preview their changes before publishing them. It is supposed to be done at some point, but there is no word on when.
Full disclosure, I work for Telerik and I'm the Sitefinity Evangelist.
Full integration in Visual Studio 2010 and our existing Application (so no Umbraco)
This is a difficult item to claim with a blanket statement.
I don't know much about your existing application. Our customers have accomplished a lot of Sitefinity integrations with various applications. This could be done through web services, custom controls or simply accounting for external URL's in Sitefinity's sitemap. Feel free to post to our Sitefinity forums for recommendations for your specific scenario.
Regarding Visual Studio integration, Sitefinity includes Telerik RadControls and OpenAccess ORM. We also try to align ourselves closely with traditional ASP.NET technologies.
Common ASP.NET Web Forms Developing practices
Sitefinity Templates = ASP.NET Master Pages
Editable CMS regions = ContentPlaceHolders
Sitefinity Widgets = ASP.NET Controls
Sitefinity Themes = ASP.NET Themes
We make the marketing claim "if you know ASP.NET, then you know Sitefinity". However, realistically all products comes with some learning curve. As much as possible we try to align ourselves with the experience ASP.NET developers already have.
Security (FormsAuthentication, custom Membership-/RoleProvider)
Sitefinity's authentication is based on traditional ASP.NET Membership & Role providers. We've included a couple (Sitefinity & Active Directory) but you can extend with your own.
Very flexible and extendable (good API)
Our API is LINQ enabled and we also have a Fluent API. We also have a full RESTful web service API.
Lightweight CMS with good performance (thousands of simultaneous requests)
Our own Telerik web sites run on Sitefinity, and many of our customers support web sites that handle a large volume of traffic.
However, I'm not sure what constitutes "lightweight". Many CMS's have little overhead, but also do very little. We've tried to deliver a lot of features and end-user friendliness with Sitefinity. This comes at the cost of some overhead.
Managing the balance between a CMS that "helps you" and "gets out of your way" is a constant challenge. The best I can promise is that we're aware of the challenge and we're doing our best to deliver effective results.
Easy content editing
Judge for yourself. Even better, download the product and let your content editors experiment. We welcome the comparison. Over & over again, this becomes our differentiator.
--
Hopefully this post doesn't sound like a lot of evangelist BS. I've tried to be accurate with my answers. Best of luck with your project.
Basically my project is product based.
Once we developed a project and catch the multiple client and deploy the application based on their needs.
But We decided to put the new features and project dependent modules are as component.
Now my application got many number of customer.
Every customer needs a different features based on the component.
But we have centralized component for all client . we move the components additional feature to client specific folder and deploy.
My problem is , I am unable maintain the components features for multiple client.
My component feature code is increased and I am unable to track the client features.
Is there any solution for maintaining the multiple component features for multiple client ?
I've worked for a couple of companies in a similar space - product software but very heavily customised.
Essentially there is a decision the company needs to make - are you a product company (that is you ship broadly the same to every client) or are you a bespoke company. At the moment it sounds like they're between two stools and wanting the economies of being a product company with the ability to meet specific client demands the way a bespoke software company can.
Assuming the company wants to be a product software company, unless there are specific technical reasons why you can't, you need to move to a single code base with the modifications for each customer being handled through customisable options (i.e. flags saying how this particular situation is being handled, whether this feature is available and so on).
These can be set at run time (so they can be changed as the client wants - think options in Word or Excel), or build time (so code is included / excluded when you do the build), but the key things is that every client has to be pulled from the same code base.
But this needs to be agreed with the business as it limits what they can sell - every change they sell has to fit into an overall vision which can be accommodated by the single product.
The alternative is that you're essentially producing bespoke software for each client (that is coded specifically for what they want) but using many common libraries. That's fine and allows you to produce something which is exactly what they want but in the end it is going to be more work and the business needs to understand and cost for that.
We actually do a bit of both - there is a server product which is identical for all clients, and then web and mobile clients which are specific to them (in the case of mobile you can't have lots of dead code on the device - the web stuff is historic and will be moving to a standard product for all clients).
Good luck though, it's a difficult problem with no easy solution.
You are essentially talking about software product lines (SPLs): variations from a common base. Since you already package your features as components, you need a specialized tool to manage such variations.
You can then build a complete custom application based on a configuration that is unique to any given customer. Easier said than done, of course.
A model-driven software development(MDSD) approach can help a lot on this task. One such system that can support this development setup is ABSE, an emerging MDSD approach that among other things, can implement a software product line (info at http://www.abse.info - Disclaimer: I am the ABSE project lead). There is no product yet though. An alpha preview is coming.
Again, I know some companies that, using an MDSD coupled with code generation, have achieved what I understand you want: products that are half pre-packaged, half custom.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We have written a software package for a particular niche industry. This package has been pretty successful, to the extent that we have signed up several different clients in the industry, who use us as a hosted solution provider, and many others are knocking on our doors. If we achieve the kind of success that we're aiming for, we will have literally hundreds of clients, each with their own web site hosted on our servers.
Trouble is, each client comes in with their own little customizations and tweaks that they need for their own local circumstances and conditions, often (but not always) based on local state or even county legislation or bureaucracy. So while probably 90-95% of the system is the same across all clients, we're going to have to build and support these little customizations.
Moreover, the system is still very much a work in progress. There are enhancements and bug fixes happening continually on the core system that need to be applied across all clients.
We are writing code in .NET (ASP, C#), MS-SQL 2005 is our DB server, and we're using SourceGear Vault as our source control system. I have worked with branching in Vault before, and it's great if you only need to keep 2 or 3 branches synchronized - but we're looking at maintaining hundreds of branches, which is just unthinkable.
My question is: How do you recommend we manage all this?
I expect answers will be addressing things like object architecture, web server architecture, source control management, developer teams etc. I have a few ideas of my own, but I have no real experience in managing something like this, and I'd really appreciate hearing from people who have done this sort of thing before.
Thanks!
I would recommend against maintaining separate code branches per customer. This is a nightmare to maintain working code against your Core.
I do recommend you do implement the Strategy Pattern and cover your "customer customizations" with automated tests (e.g. Unit & Functional) whenever you are changing your Core.
UPDATE:
I recommend that before you get too many customers, you need to establish a system of creating and updating each of their websites. How involved you get is going to be balanced by your current revenue stream of course, but you should have an end in mind.
For example, when you just signed up Customer X (hopefully all via the web), their website will be created in XX minutes and send the customer an email stating it's ready.
You definitely want to setup a Continuous Integration (CI) environment. TeamCity is a great tool, and free.
With this in place, you'll be able to check your updates in a staging environment and can then apply those patches across your production instances.
Bottom Line: Once you get over a handful of customers, you need to start thinking about automating your operations and your deployment as yet another application to itself.
UPDATE: This post highlights the negative effects of branching per customer.
Our software has very similar requirements and I've picked up a few things over the years.
First of all, such customizations will cost you both in the short and long-term. If you have control over it, place some checks and balances such that sales & marketing do not over-zealously sell customizations.
I agree with the other posters that say NOT to use source control to manage this. It should be built into the project architecture wherever possible. When I first began working for my current employer, source control was being used for this and it quickly became a nightmare.
We use a separate database for each client, mainly because for many of our clients, the law or the client themselves require it due to privacy concerns, etc...
I would say that the business logic differences have probably been the least difficult part of the experience for us (your mileage may vary depending on the nature of the customizations required). For us, most variations in business logic can be broken down into a set of configuration values which we store in an xml file that is modified upon deployment (if machine specific) or stored in a client-specific folder and kept in source control (explained below). The business logic obtains these values at runtime and adjusts its execution appropriately. You can use this in concert with various strategy and factory patterns as well -- config fields can contain names of strategies etc... . Also, unit testing can be used to verify that you haven't broken things for other clients when you make changes. Currently, adding most new clients to the system involves simply mixing/matching the appropriate config values (as far as business logic is concerned).
More of a problem for us is managing the content of the site itself including the pages/style sheets/text strings/images, all of which our clients often want customized. The current approach that I've taken for this is to create a folder tree for each client that mirrors the main site - this tree is rooted at a folder named "custom" that is located in the main site folder and deployed with the site. Content placed in the client-specific set of folders either overrides or merges with the default content (depending on file type). At runtime the correct file is chosen based on the current context (user, language, etc...). The site can be made to serve multiple clients this way. Efficiency may also be a concern - you can use caching, etc... to make it faster (I use a custom VirtualPathProvider). The largest problem we run into is the burden of visually testing all of these pages when we need to make changes. Basically, to be 100% sure you haven't broken something in a client's custom setup when you have changed a shared stylesheet, image, etc... you would have to visually inspect every single page after any significant design change. I've developed some "feel" over time as to what changes can be comfortably made without breaking things, but it's still not a foolproof system by any means.
In my case I also have no control other than offering my opinion over which visual/code customizations are sold so MANY more of them than I would like have been sold and implemented.
This is not something that you want to solve with source control management, but within the architecture of your application.
I would come up with some sort of plugin like architecture. Which plugins to use for which website would then become a configuration issue and not a source control issue.
This allows you to use branches, etc. for the stuff that they are intended for: parallel development of code between (or maybe even over) releases. Each plugin becomes a seperate project (or subproject) within your source code system. This also allows you to combine all plugins and your main application into one visual studio solution to help with dependency analisys etc.
Loosely coupling the various components in your application is the best way to go.
As mention before, source control does not sound like a good solution for your problem. To me it sounds that is better yo have a single code base using a multi-tenant architecture. This way you get a lot of benefits in terms of managing your application, load on the service, scalability, etc.
Our product using this approach and what we have is some (a lot) of core functionality that is the same for all clients, custom modules that are used by one or more clients and at the core a the "customization" is a simple workflow engine that uses different workflows for different clients, so each clients gets the core functionality, its own workflow(s) and some extended set of modules that are either client specific or generalized for more that one client.
Here's something to get you started on multi-tenancy architecture:
Multi-Tenant Data Architecture
SaaS database tenancy patterns
Without more info, such as types of client specific customization, one can only guess how deep or superficial the changes are. Some simple/standard approaches to consider:
If you can keep a central config specifying the uniqueness from client to client
If you can centralize the business rules to one class or group of classes
If you can store the business rules in the database and pull out based on client
If the business rules can all be DB/SQL based (each client having their own DB
Overall hard coding differences based on client name/id is very problematic, keeping different code bases per client is costly (think of the complete testing/retesting time required for the 90% that doesn't change)...I think more info is required to properly answer (give some specifics)
Layer the application. One of those layers contains customizations and should be able to be pulled out at any time without affect on the rest of the system. Application- and DB-level "triggers" (quoted because they may or many not employ actual DB triggers) that call customer-specific code or are parametrized with customer keys) are very helpful.
Core should never be customized, but you must layer it in somewhere, even if it is simplistic web filtering.
What we have is a a core datbase that has the functionality that all clients get. Then each client has a separate database that contains the customizations for that client. This is expensive in terms of maintenance. The other problem is that when two clients ask for a simliar functionality, it is often done differnetly by the two separate teams. There is currently little done to share custiomizations between clients and make common ones become part of the core application. Each client has their own application portal, so we don't have the worry about a change to one client affecting some other client.
Right now we are looking at changing to a process using a rules engine, but there is some concern that the perfomance won't be there for the number of records we need to be able to process. However, in your circumstances, this might be a viable alternative.
I've used some applications that offered the following customizations:
Web pages were configurable - we could drag fields out of view, position them where we wanted with our own name for the field label.
Add our own views or stored procedures and use them in: data grids (along with an update proc) and reports. Each client would need their own database.
Custom mapping of Excel files to import data into system.
Add our own calculated fields.
Ability to run custom scripts on forms during various events.
Identify our own custom fields.
If you clients are larger companies, you're almost going to need your own SDK, API's, etc.
Which CMS is the most flexible and/or easily modifiable in the following ways:
Have multiple clients access the CMS with multiple users per client. And each client can control multiple sites.
Control the layout of created pages based on certain criteria. Criteria such as which
section/sub-section the user would like to put the page in. e.g. - if the section for the page chosen is Clothing->Womens->Shorts then only allow certain layouts to be chosen.
It would go something like this:
- The user creates a new page within the CMS
- They choose the section or subsection of the page
- Based on that selection, we control if they are allowed to use the chosen layout/template.
Reason for this is that we want to control the UI of the top level pages (where the user enters the site from). And, have less control on the lower nested pages.
2 very flexible Php based CMS frameworks are Drupal and Joomla. Both are built upon plugin architectures where you can customize you application by downloading, installing and configuring the appropriate plugins for things like blogs, forums, search indexing, RSS, storing & playing video etc...
Drupal refers to their plugins as Modules. There are thousands of modules available (over 700 in the Utilities category alone). Warning - the modules are version dependant and not all modules have been upgraded to run in the current production versions of Drupal so pay attention to the version support.
Joomla refers to their plugins as Extensions. At time of posting, they had over 4500 extensions available. I haven't used Joomla myself so I can't talk to it's quality or ease of use, but it does seem to be another very popular, flexible product.
I just found this post that compares 10 Java based opensource cms products. I don't know if you have a particular technology in mind, but if Java's your thing one of these might help you out.
http://blog.taragana.com/index.php/archive/top-10-java-content-management-software/
Have a look at Jahia (www.jahia.com) - java open source based cms. The features you are describing are indeed typical of "site factories" which is a main business case for that CMS.
read http://www.jahia.com/jahia/webdav/site/jahiacom/shared/products/Jahia%20Sitefactory_WhitePaper.pdf and test yourself the features with the online demo.
I'm using Jahia with Alfresco as document repository using Communitiy release (without Alfresco connector, not too easy but it's possible using REST).
It's really a good solution because with Jahia you could add some Java Spring dynamic modules.
i think Wordpress is one of the best content management system. that provides much better flexibility as compared to other CMS.