I'm looking for recommendations for a spreadsheet-like input facility to sit in an ASP MVC environment.
The client currently has a large number of very complex interlinked shared spreadsheets (which they are effectively running 90% of their core business from) for collecting and processing information. They wish to move this to a web application and require ASP MVC. They realise that they will not be able to display as much information on screen as they do currently with their spreadsheets, so a 40 x 60 grid should suffice in most cases. Of this they'll be a limited number of cells for data entry that will immediately update other cells in the grid using various spreadsheet-like formula. The grid must be AJAX enabled.
The quality of the user-interface is of primary concern here. As inevitably there will be a certain amount of resistance to move to database/web (and this project is a pilot anyway) the system must be as slick as possible. Almost as important is ease of implementation - the final system will be quite large so the quicker it is possible to configure the grid the better.
Either Open Source or commercial would be fine. HTML/Javascript, Silverlight and Flex implementations can all be considered.
I initially asked a similar question a year ago (it's taken that long for the client to agree the project) but I'm sure options have changed since then and our environment is now better defined.
I think Grapecity Spread will fit the bill , it can be easily built with MVC pattern and now it also supports the Razor View Engine .There is already a blog which details how to use Grapecity Spread with MVC , you can go through this here
http://www.gcpowertools.info/2011/12/using-grapecity-spread-for-net-with-mvc.html
Microsoft Silverlight. It is almost certainly your best bet for a rich line of business application with web deployment. It will allow you to utilise a consistent code base across your back-end and front-end component.
Whilst a number of commercial datagrid packages exist (Telerik, etc), I'd suggest using the default Datagrid component that is available, and understanding fully the databinding and templating options available.
Check out YUI's datatable, maybe what you need
http://developer.yahoo.com/yui/examples/datatable/dt_cellediting.html
I have used it and its great, very developer friendly and supports pagination.
When asked for a multi-line editable grid, I've done it two ways.
Dropped a SL control onto the page. This was incredibly easy.
A lot of javascript. Double-clicking a row made a row editable with several textboxes to span the gap. I don't think is what you're looking for, though.
For something quick and easy have a look at JqGrid demos to see if it can do what you want
http://www.trirand.com/blog/jqgrid/jqgrid.html
JQuery is already in MVC and being javascript it will work without plugins for the browser. However it may not be powerful enough for what you want in which case you going to need to look at Silver light etc. Could the project not be approached in a more web friendly manor?
Related
I have an existing application which is quite large, uses a SQL Server database and LINQ to SQL built in MVC. It does what it needs to do very well, but the CMS is sadly lacking (it's difficult, complicated to use and prone to errors).
I like the look of Composite C1 to migrate this application to so that my users can get a good CMS experience.
I don't really want to center my development around C1, so I've been looking at creating an MVC application:
http://docs.composite.net/Functions/MVC
I've created a sample controller, view and then returned some static data to the view and finally posted some data to the controller. All works as a "normal" MVC application would do.
Has anyone used this concept for a real world application? The idea is that if a user want's to display one of my controls on a page they just add the control via the Composite editor. I'll also add basic pages on installation.
It's a bit of a vague question, but I'm really looking for feedback on the following:
1) How "involved" do you need to be with Composite C1 stuff? I want to just create my controllers and other classes to do my work
2) How is the performance with this approach?
3) Is there many gotcha's that you've experienced?
I have built a larger application within/on top of a Composite C1 environment, so I can say its definitely possible and the compatibility with .NET application development is actually one of the main reasons why we chose Composite in the first place.
1) How "involved" do you need to be with Composite C1 stuff? I want to just create my controllers and other classes to do my work
You won't be able to completely ignore everything Composite related when developing a full fledged application however, simply because your controls/views/controllers will run on and be rendered by Composite C1. So necessarily some of the work is done at least in part by the C1 foundation you build on, e.g. Routing, Exception Handling or Rendering.
However you can usually work with or around those features without too much trouble. It may however take some understanding of how Composite works.
2) How is the performance with this approach?
So far I cannot say that Composite would slow down the application in any significant way. It may in fact support you in tasks like Output Caching.
3) Is there many gotcha's that you've experienced?
This is a very broad question, but you generally will always have to make sure you know whether something belongs in one of your controls or would be better fit into a Composite component (page, reusable html block). If you put things into the wrong place, the easiest things will become complicated (like creating a page link) due to information being not present in the current context. But as I said, you can solve this through clever design.
Another thing to look out for is that correct source versioning is a bit harder to set up in the first place with a Composite application, because you have to figure out what is content and what is application.
So far I have made good experiences with C1 and will be using it in the future. It may take a little more time to get into it in the first place compared to a vanilla ASP.NET application, but the work that is done for you regarding CMS parts is well worth it.
A junior developer on my team just created a screen using an MVC Helper called WebGrid.
My first reaction was a classic NO! to anything that sounded like Grid / bound tech.
As he demo'd the functionality, it wasn't bad, though it did use
?sort=Title
type of syntax which bothers me generally. He also showed me many examples of posts regarding use on forums like Stack. One such warned against their use, but was categorical and gave no clarification. I would like to know if users have any positive or negative experiences with the WebGrid control.
Would you recommend for or against as "best practice"?
I don't think you're going to get a definitive answer to this question, but I think it's a good question and deserves an answer (others may vote to close it, just as a heads-up). But this is my personal take, FWIW.
One of the benefits, to me, of MVC (vs. Web Forms) is that it provides almost full control over the rendered HTML. With Web Forms, .NET did its own crazy thing to get the front end bound to code behind, and this was magnified with using web controls.
Generally speaking, the same could be said about using controls like this in MVC -- they often limit the control one has over the rendered HTML.
Another argument is that they typically limit what you can do via client-side code (or how easy you can do it). This may be a side effect of not having full control over the HTML.
I would take a look at the HTML it produces -- you may quickly see enough reasons there not to use it (or, to use it).
Of course, the other argument is that third party controls often try to do too much, or do things differently than you'd like (like passing the sort through a query string, as you mentioned).
I am trying to write wrappers library over telerik controls of MVC.
reason behind this is i can easily change third party control without change in View,Controller.
Is it good idea.
I am facing problem to hide telrik completely because, they have there own js and return objects.
Am i in correct direction?
Sounds like an abstraction to far. How many view pages are you talking about? Do you have a concrete requirement to be able to change? The odds are you will lose some of the power and just gain a lot of hassle. Probably easier to rewrite the views if is ever required. If you are that worried you probably maybe you should use a non commercial alternative? However it depends what parts you are using I only used the Grid really and we switched our site to DataTables without much issue.
I use Telerik and have never abstracted it but the rest of my architecture is flexible. I don't ever tie Telerik controls directly to a domain entity list etc. I always use a ViewModel mapped from the Domain entity using AutoMapper.
The UI in most business applications is the least significant part and is normally relatively easy to change if you haven't tightly coupled it to your Domain Model.
Wicket uses the Session heavily which could mean “large memory footprint” (as stated by some developers) for larger apps with lots of pages. If you were to explain to a bunch of CTOs from Fortune 500 that they have to adopt Apache Wicket for their large web application deployments and that their fears about Wicket problems with scaling are just bad assumptions; what would you argue?
PS:
The question concerns only
scaling.
Technical details and real world
examples are very welcomed.
IMO credibility for Apache Wicket in very large scale deployment is satisfied with the following URL: http://mobile.walmart.com View the source.
See also http://mexico.com, http://vegas.com, http://adscale.de, and look those domains up with alexa to see their ranking.
So, yes it is quite possible to build internet scale applications using Wicket. But whether or not you are using Wicket, Struts, SpringMVC, or just plain old JSPs: internet scale software development is hard. No framework can make that easy for you. No framework can give you software with a next-next-finish wizard that services 5M users.
Well, first of all, explain where the footprint comes from, and it is mainly the PageMap.
The next step would be to explain what a page map does, what is it for and what problems it solves (back buttons and popup dialogs for example). Problems, which would have to be solved manually, at similar memory costs but at a much bigger development cost and risk.
And finally, tell them how you can affect what goes in the page map, the secondary page cache and thus how the size can be kept under control.
Obviously you can also show them benchmarks, but probably an even better bet is to drop a line to Martijn Dashorst (although I believe he's reading this post anyway :)).
In any case, I'd try to put two points across:
There's nothing Wicket stores in memory which you wouldn't have to store in memory anyway. It's just better organised, easier to develop, keep consistent, and test.
Java itself means that you're carrying some inevitable excess baggage around all the time. If they are so worried about footprint, maybe Java isn't the language they want to use at all. There are hundreds of large traffic websites written in other languages, so that's a perfectly workable solution. The worst thing they can do is to go with Java, take on the excess baggage and then not use the advantages that come with an advanced framework.
Wicket saves the last N pages in the session. This is done to be able to load the page faster when it is needed. It is needed mostly in two cases - using browser back button or in Ajax applications.
The back button is clear, no need to explain, I think.
About Ajax - each ajax requests needs the current page (the last page in the session cache) to find a component in it and call its callback method, update some model, etc.
From their on the session size completely depends on your application code. It will be the same for any web framework.
The number of pages to cache (N above) is configurable, i.e. depending on the type of your application you may tweak it as your find appropriate. Even when there is no inmemory cache (N=0) the pages are stored in the disk (again configurable) and the page will be find again, just it will be a bit slower.
About some references:
http://fabulously40.com/ - social network with many users,
several education sites - I know two in USA and one in Netherlands. They also have quite a lot users,
currently I work on a project that expects to be used by several million users. Wicket 1.5 will be improved wherever we find hotspots.
Send this to your CTO ;-)
I have a side project done in ASP.NET MVC. So far the presentation is just very basic functionality.
If I were to hire a designer online and work with them to produce the final website design what process should I follow to make it as easy as possible to take their HTML and CSS and translate that into ASP.NET MVC controls etc?
I am unclear on the best way to do this and where the responsibilities of the developer finish and the designer would begin?
How do these two people that speak different languages work smoothly together to quickly converge on the final product?
Thanks!
I would give them mockups done with Balsamiq Mock or some other tool.
You should also define screen resolution, how much of the fonts is done as graphics and what parts are dynamic at the end and what not. The designer needs the information about the dynamic parts because he will give these texts more space.
Then they would usually do some sample layouts for 2-3 pages that you discuss.
From there they start to do the final Photoshop layouts.
Hopefully the designer also does the HTML. If not the document is passed to the html-designer who slices the documents and produces the html+css.
It's crucial that you find a designer who can do design and html. Otherwise you lose some time when the html-guy has to talk back to the designer.
Both have to talk at least: otherwise the html-guy will complain about mising fonts, controls that do look different on the designer mac then on a real computer and text content planned by the designer that can't be read because the font is too small.
The result would be a complete clickable site in html.
Typically what I do is just structure the views in a general way with CSS classes and clean HTML. Then, for the most part I take the designer's HTML template and cut out the top and bottom and paste them into my master page(s). From there I just need to update some of the CSS classes to match the designer's fonts and colors, etc.
I usually just request the Photoshop PSD from my designers and then I do the slicing into HTML/CSS so I know exactly how the page is structured, and I control the CSS. But designers are used to working with people who maybe aren't as design-knowledgeable (read: developers), so just find a good designer, and they'll get you set up right.
Try: http://programmermeetdesigner.com/