Related
I would like to ask you what experience you have with developing and deploying one application that in general has some standard features, but the application can also have customer specific features.
For example:
Customer 1 have the standard features but also want a search function.
Customer 2 have the standard features only.
Customer 3 have the standard features and also want an employee calendar.
How would you solve this?
Would you have one project where you deploy all the application from and then have some kind of config file to determind which features are avaliable in the specific application?
Would you have one project for each customer? This is how I'm doing it now, but the problem here is that if there are bugs that need to be fixed in the standard features I have to fix them in every project.
Any other suggestions are very welcome.
The application is developed in Delphi and C#.
My company solves that problem by giving all customers all features. This keeps development simpler and allows us to spend more time working on improving the product and not have to spend time dealing with the complexities of optional features.
We sometimes meet mild resistance from clients who want a cheaper version with less functionality but that's never been a sales problem.
On the other hand if you sell clients cheaper less functional versions, they are liable to try to get away with these cheaper versions. This can then lead to them not liking the software as much they should because they bought the cheap crippled version. I strongly believe in getting the best product possible to the user.
This advice may not be appropriate to your personal situation, but you did say that any opinions would be welcome.
One version per customer is not a good idea, IMHO. It will stuck your sales one day or later.
Better let all features be released to all customers, i.e. just maintain one software, but locked by a password, for instance. You can give a unique licence number at the software installation in order to identify the customer (put its name in the licence), then compute some passwords according to this licence number, to unlock some features, on request - when paid. This password can be easily automated via a web site, with minimal cost for you.
Or you can also let all functions available for testing, but lock the printing or the saving - just to let the customer think about spending some money to have this "nice added feature".
Sometimes, having all features tend to create a "Gasworks" application. You'll probably need a separate setup application, to customize the application to your customer's needs. Worth thinking about this architecture.
Even with a revision control, multiple versions are a nightmare to maintain: for instance, just back-port all hotfixes to a previous version takes a lot of time. If you don't have to (because of regulatory purpose / certified versions e.g.), don't "branch" your software.
No definitely do not have one project per customer, you could have one solution per customer where you agregate all projects given setup need.
Just to give you in an alternative to plugin architecture, which is right way to go, but also usualy fairly complex.
Option1.
Put common functionality in main project (Core)
Additional stuff like calendar put in separated DLL projects ( one per functionality)
Create VS SOLUTIONS, where you agregate all projects for specific setup + Core. So customer1 will have Customer1Silution with Core and all additional projects he need, customer2 its solution with Core and its additional stuff.
Option2.
Have one big setup for every one and based on its configuration/license enable/ disable access to user to a additional functionality.
Depends on your resources like time, experience, people you work with, clients , you can chose an option more appropriate to you.
1 plugin based: may be the best one but it, complex and it will take a time you become familiar with it, if you never did before something similiar.
Option 1 easy and fast, but if the clients quantity and configyration become defer you will jump into scale problems.
Option 2 is an average between those two, but keep an eye on your setup dimension.
Considering tha fact that you refer projects and nit DLLs in your solutions, if you fix a problem in Core in one solution it will affect also all other solutions.
you have several options:
put the "standard features" into separate module(s) which can be used/linked by the other versions
use a "plugin-architecture" to load the optional features dynamically
In addition to what others have said there is another option: Conditional defines.
With conditional compiling you can wrap feature specific code with IFDEFS (IFDEF EmployeeCalendar, IFDEF SearchFunction...). Then for each client you copy the project file only and set the conditional defines according to features you want to include.
If a client wants/pays for additional feature you just add it to Conditional defines in that client's project file.
This is similar to the modules approach (BPL/DLL) but avoids the added cost of having to deploy/manage extra files. The drawback is that the feature set is fixed at compile time.
With BPL/DLL you could dynamically load additional modules at run time, but if that is not important in your case, then Conditional defines might be a good choice.
Of course if your features are not easily separable then you can end up with a lot of IFDEFs in the code, but then your problem is clear separation of features, and it would be the problem with modules too.
I am looking people's opinion and experience on using chart controls within an ASP.NET application (web forms or MVC) primarily but also in any kind of project.
I am currently doing my research and I have a pretty big list of controls to evaluate. My list includes (in no particular order):
ASP.NET controls:
DevExpress XtraCharts (http://demos.devexpress.com/XtraChartsDemos/)
Dundas Chart for .NET (http://www.dundas.com/)
Telerik RadChart for ASP.NET AJAX (http://www.telerik.com/)
ComponentArt Charting & Visualization
for ASP.NET (http://www.componentart.com/)
Infragistics WebChart (http://www.infragistics.com/dotnet/netadvantage/aspnet.aspx#Overview)
.net Charting (http://www.dotnetcharting.com/)
Chart Control for .Net Framework
(Microsoft's) (http://weblogs.asp.net/scottgu/archive/2008/11/24/new-asp-net-charting-control-lt-asp-chart-runat-quot-server-quot-gt.aspx)
Flash controls:
FusionCharts v3 (http://www.fusioncharts.com/)
XML/SWF Charts (http://www.maani.us/xml_charts/index.php)
amCharts (http://www.amcharts.com/)
AnyChart (http://www.anychart.com/home/)
Javascript:
Flot (http://code.google.com/p/flot/)
Flotr (http://solutoire.com/flotr/)
jqPlot (http://www.jqplot.com/index.php)
(If I missed some that worth to be compared against the above please let me know.)
What I am looking is opinions on using any of the above so I can form my own and help others do the same, based on what I read here.
I do not care which one is better. What I care for is why someone likes one of the above and what do these controls offer as a distinct advantage. I am interested in developer's opinion and I would like to find out which things are difficult doing with any of the above controls and which things are easy to achieve.
AJAX compatibility (build in to the controls but also manual), ASP.NET compatibility, input capabilities, data binding options, performance, how much code does one need to write in order to create a chart, are some of the things that I would want to read about.
I have already done my research on StackOverflow for relevant questions but there is nothing on the level of detail that I would want to read in order to make a responsible decision.
I worked a little bit with Google charts and the .Net Chart Control (formerly Dundas Chart 5.5). I do not have an opinion about the other products you listed.
At the time (a year ago) there was no functioning .Net wrapper framework for Google Charts (at least I did not find one), and while the Google Charts Api is relatively simple, it is also very limited. I found the resulting code that composes the chart request to be inherently ugly and not very maintainable (not necessarily the fault of the API, I know - but it would have required a much larger investment to do it better). Here are some of the resulting charts. For instance, I was unable to find a way to align the grid with the tick marks. The 30mph line on the third chart seems to be randomly placed. If you need fine-grained control, Google Charts is not your choice.
The .Net Chart Control on the other hand gives you a lot of control. I worked on a prototype earlier this year and the goal was to create charts that matched the ones from a print publication put together by a design firm. At first I thought it would require compromises, but the Chart Control turned out to be capable of the job. Here is the result (click the 2nd tab). I found the ability to use a range chart in this way, and have control over the placement of the labels for the vertical lines at special values pretty unique for a free tool. Also, Alex Gorev who runs the MSDN forum turned out to be very helpful when I ran into an issue (even though he could not ultimately solve it).
Not a control, but another option for producing charts and publish them to the web, is SSRS. I have used the web service interface to publish a report that contains a chart. This could be a better option for very large sets.
2014 update: The comments above are for a previous (obsolete) generation of Google's chart API. The new API probably addresses many of the limitations, so you should check it out.
SimpleChart is a straight forward and easy to use component. I've used Fusion Charts and would also recommend it for simplicity and well presented graphs.
I went with the Microsoft Chart control, mentioned as the marked-answer, over here: Charts for ASP.NET
so far the best charts I have used is FusionCharts. it can be used with any programming language, as it provides a good documentation. the free version is good enough.
I have done a lot of .Net projects that required graphing and would recommend a solution outside of .Net. The reason why I go outside of .Net is because I expose my datasets by JSON (usually) and like to move the processing to the client. Altogether this saves me burgeoning my servers with graphically intensive tasks.
I have mainly used Javascript API's and I would recommend Protovis because the charts are beautiful (but not always compatible with IE) and can be manipulated in realtime on the client with new AJAX fed datasets.
Another of note is Google Chart and Visualisations.
Echoing everyone else - it all depends what you need to do with it.
We looked at a number of chart controls for a recent project and it's amazing how many of them have really basic limitations. As an example, we needed to specifically set the size and position of the plot area - you'd think that would be easy but the dundas and the microsoft charting api can't do it. We also had a lot of problems getting charts to format datetime scales sensibly.
In the end we went for dotnetCharting. The website makes it look pretty rubbish, but we've found it to be extremely good, if a little quirky in places. I'd thoroughly recommend it to anyone. It's got some reasonably slick AJAXy stuff, but to be honest you can (and we did) custom write most of that stuff yourself anyway. There are more important things to consider when choosing the tool imho.
Make a list of specific things you think you'll need and then find a control that does them. Don't make any assumptions, as a lot of the tools have pretty elementary problems (as above).
I did not use a lot of charting tools, but make sure it will work with MVC if you are planning to use this framework. I have some issues with the DevExpress Grid and MVC.
I haven't used a cross-section of these controls, but of the ones I have used, I prefer the Infragistics WebChart.
In my opinion, the designer is easy to use and there is a ton of flexability.
My second choice would be the Google Chart API.
I've used the DevExpress XtraChart in ASP.NET, and it was great. I've used Google Chart API successfully in a rails project, but as it is hosted, generating the points and labels would be easy on any platform.
I am using ChartDirector in my projects. The thing that I like the most about this component is very complex examples. I have been able to implement their financial chart example with almost no alterations saving enormous amount of time in the process.
i has used microsoft charts control in one of my project. it provided me things that i needed.
Tutorial on Charts Control:
http://parasdoshi1989.wordpress.com/2010/10/03/how-to-include-charts-in-visual-studio-2008-express-edition-using-microsoft-chart-control/
I thought I'd canvas the more experienced .NET (mostly CSharp/ASP.NET) Developers on the most useful general components. I've got about $5-$7k to spend as I want on components as part of a project which involves web based graphs/reports/data visualisation, but I want to get things that will be useful for general purpose the board while the cash is there to be had! My current thoughts are as follows, any opinions welcome:
Dundas Chart (already bought, I've had great experiences using it)
Telerik .NET
DevExpress DXperience (a bit of a dupe against the Telerik components but I figure if one has a strange bug or limitation you have the other as a fallback). Both seem very comprehensive.
Was considering a diagram type control like godiagram- it doesn't look visually amazing like the old Corgent/Dundas diagram did, but I can't find a better one presently. If anyone knows a nice one that does anti-aliasing and suits workflow type diagrams, let me know!
Considering a Telerik SiteFinity license, it looks quite good but not sure how well it'll combine with non-cms type pages, so the jury is out.
Any glaring omissions? Thanks all!
I have purchased the DevExpress and Telerik libraries and, while both are good, I ended up removing Telerik altogether and sticking with DevExpress for some pretty concrete reasons.
First, there is a great deal of overlap between the two and the two of them really share the leadership position in the ASP.NET/C# market.
DevExpress has a significant advantage with respect to their reporting tool. No tool I evaluated was perfect (I looked at four altogether) but DevExpress was the easiest to get going with, the easiest to deploy and at least as powerful as any of the others (with the possible exception of the MS tool - but that has its own deployment problems). This was a big advantage as reporting is central to my app as well.
The DevExpress charting library is very nice and integrates well with the reporting tool - another win for them. Dundas and Telerik have nice libraries as well but, after years of doing charts, ease of setup/definition is important to me and DevExpress has the edge there.
Telerik has a better online HTML editor (we feature a CMS in our product) but the DevExpress product wasn't that far behind. If I was not doing reporting/charting, I might go with Telerik on this basis alone since our CMS is quite important but it isn't enough of an advantage if you are doing reporting/charting.
The Grid products from both are great but DevExpress also offers a PivotGrid that is a spectacular data analysis tool and a nice addition to any site where data analysis is important.
Both have very good support in my experience.
The generic controls from both are very capable but, honestly, there's little reason to choose either one over the other for the controls that I care about. My focus was on date-handling controls and numerical inputs.
So, I can absolutely see people being happy with either of the two but I ended up (after using both for about two years) going with just DevExpress. It didn't hurt that the DevExpress team also wrote a book that really helped flesh out the range of uses to which their library could be put.
Hope that helps!
Before spending money on controls you might use, you should figure out what you're doing and buy the ones you will use.
I like the asp.net chart controls, http://weblogs.asp.net/dwahlin/archive/2008/11/25/getting-started-with-the-asp-net-3-5-chart-control.aspx
but they're free.
I completely agree with #John Boker, but would also add that you consider broadening your search to include development tools which might make your team faster at code production/testing/validation.
Making your code easier to build and maintain wins out over having a wide variety of expensive component libraries in my experience, and this is mostly due to having very good free versions of the controls you are looking for, yet a relative dearth of decent free code production tools.
Development tools like ReSharper and dotTrace will be useful in writing efficient & maintainable code
I think Peter Blum's validator controls are great, and his data entry stuff is pretty nice too.
SQL Server reporting services (if you're using SQL Server) might help you lose the cost of a few of these. Also the no frills Google Chart API is cheap and a lot easier to integrate.
I have before created a quick Ajax Framework for one of my projects. It was an ASP.Net Website (C#). There was not a lot of Ajax type functions so I just made a new Page with nothing in it and in the code behind file I put some code in the Page_Load method which would look for an action in the request and then call the appropriate method.
I am in the same scenario again and I am finding that I am tempted to do the same again.
I am letting the user create a new accommodation. Two of the fields that belong with accommodation are accommodation type and area. Both of these fields are maintained by the users so they can CRUD both of these fields on other pages. I was thinking that if the area or accommodation type did not yet exist it would be irritating to have to go to another page. So instead I want to give them the functionality of adding new areas and adding new accommodation types on the same form. So I have tickboxes for the accommodation type, when they click new I present them a textbox they enter the value and click add. It makes an Ajax call to the database to add the value and then a new tickbox appears if successful else an error message. Very similar for area except I will be using a drop down list.
This time however I am using some jQuery too. I am not that familiar with jQuery's Ajax libraries YET. My question is, "Is there a...
Better
Easier
Smarter
More Extendable
All of the above
way of doing this." If so can you please point me in the right direction.
Given that with VS2008 there's support for AJAX already built into the IDE (and with jQuery support coming), I think you'll find it tough to come up with something which is not only a better user experience but also a better developer experience.
The Visual Studio team not only have a lot of resources invested in making this work well, but they also know how to integrate features into the IDE, almost certainly better than you do (and with more access to do so, I suspect).
If you want to do this for fun (or as part of MonoDevelop, for instance), that makes sense - but from a productivity point of view, I'd just stick to Visual Studio.
I dont think you need to create an entirely new Ajax Framework. A lot of time and effort by many people has been put into other frameworks like the Asp.net Ajax, jQuery, and others. Take some time to learn what these frameworks provide for you and how you can use them. If you still find them lacking nearly all of them have ways to extend on their already built features.
I'm not going repeat what Jon Skeet said and I am sure twenty other people are typing; however, if you decide to roll your own, instead of using a blank ASPX page, look into creating your own Http Handler. In visual studo you can create you own quick and dirty handler. They have an extension of .ASHX. The benefit here is you avoid the overhead of the page object framework.
jQuery is in my experience a very good library with a lot of community support. Check out the jQuery IRC channel if you can't find what you are looking for in the documentation. We have an Ajax intensive application and it runs on jQuery as its core framework. We have been pleased with the results. If you are worried about size, Google hosts jQuery so your clients can cache it locally.
Alternatively, you may just want to create the proper HttpHandler(s) that will allow your client code to call server side resources without the overhead of a traditional ASP.NET Page class.
Check out this article from MSDN
A few days ago, I read a question asking how many developers hand code their HTML/XHTML rather than rely on the WYSIWYG tools - https://stackoverflow.com/questions/406052/do-most-web-programmers-not-designers-use-wysiwyg-editors-or-hand-code-their
I tend to lean towards designing ASP.NET server controls rather than User Controls for use in my code. I do this so that I can reuse them by drag and drop into WYSIWYG and just set the few pertinent properties. This does cost a little extra in time designing the components, but simplifies things a lot when I come to using them in larger applications.
After having read that most developers seem to hand code rather than use WYSIWYG, it leads me to wonder: Am I wasting my time developing components this way?
Edit: To clarify - mostly, the original intent has been that these controls are for my own use. However, there have been a number of occasions when they could be useful for the rest of my team or potentially for public release. However, like most things, I tend to see the huge potential extra value provided by comparatively little extra work regardless of the probability that the extra value will be realized.
No, you are not wasting your time. Your potential user base will be larger if WYSIWYG users can easily use your components. If you are the only user of these components design them so they fit your development style. If you design visually then it makes sense to have WYSIWYG support.
You could create a UserControl and using different techniques get it compile into a dll that can then be referenced by your web applications:
Overview of some methods:
Link
Detailed method:
http://webproject.scottgu.com/CSharp/UserControls/UserControls.aspx
I never use the WYSIWYG tools cause it never trully is WYSIWYG once you facter javascript, and CSS and other things. (I know VS2008 got better but not perfect). And the designers are always sooo slow. I prefer to code using markup.
If your developing a commercial component that you intend to sell you should spend the time on having the most complete feature set IMHO. Including WYSIWYG. If your building components so that your or your team can use them, then you should evaluate the cost benefit of the time it takes to get your components that extra step.
I think you're not wasting your time, especially if you want to release these controls for other developers to use. If the effort required is truly "a little extra" and you find it helps you in larger projects I think your controls are improved by being WYSIWYG tool compatible.
Personally, I generally hand code HTML/XHTML but I like using WYSIWYG functionality on occasion. I've always found that controls that were WYSIWYG friendly were easier to use than controls that relied on all code being written manually.
For your own use you already know if you are wasting your time or not.
[me enters karma-bomb shelter]
For the public and the rest of your team I'm going to offer an opinion against the flow that you probably are... well not wasting your time, but possibly not making the best use of it.
I think very few web developers will take WYSIWYG offerings seriously, however if the majority can use your controls at a hand code level and the minority can do their drag and dropping then you've provided the benefit of choice which is never an outright bad thing. Except possibly where small children and good behaviour are concerned.
If you are more comfortable with your work in the WYSIWYG editor and developing server components makes your job easier, then I don't see why you should attempt to conform to other developers methods if what you do works for you.
I think you have to take that poll with a grain of salt. Just because most people on Stack Overflow say they hand-code their HTML doesn't mean that most web developers do. Tools like Dreamweaver and Microsoft Frontpage are highly popular tools, for instance, mainly because of their WYSIWYG features. Web hosting companies usually have WYSIWYG web page builders that are also highly popular. I hand-code most of my stuff too, but I do a lot of freelance work working with web developers from other companies around the world, and from my personal experience I would probably go so far as to say that most web developers DO use WYSIWYG tools. The more experienced a web developer is, the less likely they are to use a WYSIWYG tool, but those with less experience far outnumber those with a lot of experience.
You might pose the question, to yourself, "are other developers wasting their time hand coding controls?".
I'd typically just drag and drop controls on a page and alter the generated html when needed, if it's only used on one page. If the control and it's functionality are used on more than one page in the same web app, then I'd go to a user control. When it's going definitely going to be used across apps, then I only want to code once so I go to a server control I can easily distribute. I think the key is that it (the layout and functionality) are being used in multiple places, or you're about to use it in multiple places. It's just as much a "mistake" to have duplicate code in many places as it is to have spent more time developing reusable code for one use. Plus, it's software, so you can change it later!
I think your real question probably is, "is there a way to develop my UI that I should learn more about, because it might be better than the way I'm doing it now?"
Considering how fast things are changing, that's a question we are all asking pretty frequently. I reember the first time I saw sites that were developed with Ruby on Rails; and then I ran through a tutorial that had no step for wysiwyging; but everything was accomplished with CSS and themes; and it hit me that maybe Dreamweaver isn't the most productive environment for everything, and the result could be at least equally attractive.
Working through the MVC tutorials gave me the same jolt.
So I think it's at least worth trying the alternatives to make an intelligent decision about what works best for me, my skills, and my requirements. I want the best tools in my toolkit, even if I don't need them for every project.
Especially since you seem to appreciate that your current approach is taking a substantial amount of your time.
I would say that if it is indeed only a little extra work and it adds so much extra value it's hard to conceive it could be a waste of time. Users coming in behind you that look to use your components in future will find it a lot easier and will be saving a lot of time that would otherwise be spent coding by hand. Not to mention that if you can drag and drop a component with a mouse click and drag, then why waste the keystrokes?
Like everything else, the appropriate answer is 'it depends' ...
You have to measure the ROI of adding this functionality.
For the 'I'; Personally, I've never created a web control that would work for a wysiwyg editor, so I don't know how much of effort it is.
For the 'R'; If you work on a large development team, distribute your code, will reuse these controls yourself in a wysiwyg editor, or even just want the experience, then you will definitely get your return. But if doing this is based on future maintainence programmers; you may be leaning a bit into the over optimization side. (IMHO)
I would agree with the previous posts. I don't think you are wasting your time. Making your control WYSIWYG enabled allow users to do things both ways, threw the designer and threw code. Also some times it is easier to discover what a control does when you use the property editor, apposed to making your changes in code and then compiling and running the app.
When I started to program I loved WYSIWYG and used it for almost everything.
I started to code html by necessity, there was always something that i just coul not get right using just the WYSIWYG editor. Has time passed i realised that it was faster for me to simply right the html than using the mouse to set the properties, so as time passed i used more and more html until no more WYSIWYG editors for me.
Why did i tell you this story? because my personal experience tells me that a beginner programmer will love WYSIWYG and your efforts to make server controls and a advanced programmer wont give you any credit for it.
My opinion is that you should do as you prefer. If you do this way to please others, don't bother to if there is no beginner programmer on your team.
That's my 5 cents ;)
I think I would create the control if it's used in many places. Even you hand code the html, it still saves time, and simplify the work.
but I agree that hand-coding html/css is more efficient, WYSIWYG web page builders don't support this very well.