I'm building a Bridge game.
The main page, where you play the game, boast some 200 controls, like buttons that represents the 52 cards, 26 others for won / lost tricks, plenty of text fields... You name it, total some 200.
Actually its been already built and runs under Winforms model, but with the unavoidable question of implementing .NET 4.0 onto user's machine that must run Windows, and installing the software.
Hence I'm considering creating an ASP version (no PHP please, since I'm fluent in VB, and ignorant in C, Java, PHP and the likes).
Is that a "real" option or am I dreaming?
Will it run smoothly for users with a 2MB DSL connection?
Oh, by the way, no MVC please, I'm too old for that sort of sh...t :->
Can it be done? Sure.
The problem for you might be that to do it effectivly you will need to use HTML, CSS, Javascript and the like.
What most likely would be a good idea for you here would be to go the route of Silverlight. It will give you a more rich UI experience and will allow you to code in VB entirely.
I don't see using ASP.BET directly as a good option here. To make it look smooth, you would have to use javascript heavily. I thing you would be better off with Flash.
If you prefer to use pure HTML/Javascript/CSS you can create rich Web UI's by modifying the Document's Object Model (DOM). With little knowledge of Javascript and the usage of some library like: scriptaculus, prototype, sarissa, jquery, you can get rich interfaces. You should take a look at some of these libraries mainly scriptaculus because the set of animations it provides. Another javascript library made for game development is gameQuery.
With that many controls on an ASP.NET page your view state will be gigantic. If you plan on only serving up a couple of games at once then it shouldn't be a problem but you have to actually start thinking about bandwidth with that large of a viewstate. You would be better off with a DOM/jQuery type interface which displayed static images for the cards. All interaction can be handled client side and validated with a server side call.
This might be the perfect opportunity to learn javascript :). Remember each language you learn is another tool in your toolbox. The engineer with the most tools usually wins :).
Related
I am not starting an argumentative discussion here and this post is not about career development, but from the commercial point of view:
If a company was using ASP.Net MVC as a main methodology to build their web sites and application.
However, ASP.Net MVC takes more time to show a functional application than ASP.Net Web Forms, for example, building domain models would take some time which obviously can't be represented on a UI at that current stage.
My question is, if a client wants to see a functional demo application (just a proof of concept) so he knows that the company he is dealing with is professional and capable of doing that. Would it be better to do that demo in ASP.Net Web Forms only to show the client, and then work on the real application using ASP.Net MVC? If not, what are the (quick) alternatives?, I mean, if we tell the client to wait till we have a working demo (by ASP.Net MVC) we may lose the client and the whole project opportunity.
WebForms being faster than MVC is a myth:
You are not required to have a domain model, just something that represents your database tables. This is the same in WebForms unless you are using SqlDataSource's.
The code in your !IsPostBack or btnSubmit_OnSubmit is almost identical to the HttpPost controller actions. Except with MVC you don't have to write left to write object.FirstName = txtFirstName.Text when you understand how UpdateModel works.
UI is UI. If you know HTML/CSS creating the UI is just as easy. Almost easier in MVC because you don't have to set control properties any longer and all UI can be done in one place.
Fast MVC comes from understanding how to get the most bang from your buck using EditorFor, DisplayFor templates. You'll need to know and understand how to customize your Object.ascx file. With this technique under your belt you won't have to create forms by hand anymore. 2 projects ago we had a site with 100% autogenerated forms. Change a class, change a form. Done!
Another helpful MVC tool is the DataAnnotations attributes. Validation made easy. Customizing these is really easy too. Just create your own ModelMetaDataProvider and starting expanding the validations your application can handle.
The only part of MVC that is slower is displaying a grid. MVC 3 already has a useful grid tool and MVCContrib has had a grid tool out for a year now. I ended up rolling my own, its very simple actually, loop through properties, write <td />'s. < 200 lines of code. This isn't really a benefit to WebForms either. To use WebForms grid components means giving up a lot of quality using ObjectDataSources and the like.
To summarize fast MVC comes from these different techniques:
Object.ascx
ModelMetadataProviders
UpdateModel
DataAnnotations
If you are more advanced and know ORMS like EntityFramework and how to use Automapper your probably going to be even faster.
You can get a demo up and running very quickly in MVC. I could put one together much quicker than with WebForms, and I am familiar with both.
The reliance on convention in MCV will help a lot, binding is based on the names of objects.
If i was creating a quick demo, i would just create a bunch of ViewModels with static data in them, different button clicks etc will just bind one of these ViewModels to the page.
Turbo Fast!
I build prototypes in excel. No logic, no code. just basically screenshots to show the user that we are communicating the same ideas. Create a worksheet for each "View" or screen you need to show. Client's usually only care how "pretty" an application looks vs does it work right.
This also is a benefit as you can include more non-technical users in the prototyping process, since most are used to excel. I can send you an example and the finished production web application, if seeing is believing. I personally learn best by example.
And to your post where you wrote...
I mean, if we tell the client to wait till we have a working demo (by ASP.Net MVC) we may lose the client and the whole project opportunity.
They need to have their expectations adjusted and managed. A lot of bad development has been done quickly over the years, which makes client's ask questions like "Bob did it in 1 hour'. To that I say, you can either have a lousy project fast, that you have to constantly duct tape or a well thought out and well written project that will only need to be enhanced as Bus Reqs change
I think the answer is obvious: use whichever you think makes you faster. There's no point in using MVC if you are faster in WebForms. Especially since this is for a throw-away demo.
Recently our newest web designer asked me why we use ASP.NET for our website. Reading through his question to the real one, I started thinking about it myself. Why are we using ASP.NET for web development?
The problem we find so far is colaboration between the design team and developers. Typically our designers create some snazzy cool look crayon laced web pages, then show them off for approval in all their glory. Once approved, the developers rip the HTML out and shove it in to ASP master and detail pages, and huzzah! out comes pretty website.
Since Dreamweaver doesn't play nice with Visual Studio, this is the same process for even small tweaks and changes. I would prefer to just write the backend and let the designers draw the pretty pictures and fancy CSS. Our current websites have plenty of reason to use ASP on nearly every page, so I can't do half in HTML, the other half in ASP.
I have no aversion to doing something else, another language, CMS platform, some other random buzzword, etc...
What are your experiences with this design situation? Are we doing it the hard way? Should we consider alternate platforms and languages? Are there any good, proven ways to allow designers to work on ASP (while still using Dreamweaver)?
Start learning Asp.net MVC as soon as possible. Designers will love you for that. :) And you'll be up to date with new development technologies that will also make your solutions much more robust and less complicated.
But otherwise. Designers should be able to read XHTML fluently. Learning asp.net semantics shouldn't be too hard. Then give then Visual Studio where they can manipulate content. As long as they know how asp.net web forms work things should be fine. They'll probably be able to do majority of things using just CSS. I know I can. Sometimes I do have to check resulting HTML, but it works.
Aside from Wicket (a java web framework), I don't know of any framework or language that would allow designers to continue to work on the design once developers have started to add logic to it.
I would suggest two things though:
Use a MVC framework - ASP.NET MVC, Ruby on Rails, Django, etc since this allows for far more separation of presentation and logic
Keep your presentation layer as stupid as possible and use helpers as much as possible or even better, put the logic in the domain objects. The view should only show or get data with absolutely no logic for processing data, this will keep the pages much more designer friendly.
I find your question very interesting because no matter what kind of technology the project uses the interfaces between the different roles will always cause some friction. I am not sure if there is a technological solution to this communication issue because the designer and developer speak literally different languages.
Depending on the skillset of your designers and developers an additional layer might help you out. I do not know how ASPX works but i am sure there will equivalents to the concepts of other technologies.
In case you have mainly static content which can be expressed in XML than you could provide the backend which delivers the content in XML with a defined Schema and your designers could describe the transformation in XHTML and CSS via XSLT. Given that your designer are capable using XHTML and CSS the addtional effort to learn XML and XSLT is not that huge. I find this solution much powerful than template languages which try to emulate the richness of the serverside scripting language in their own limited constructs. In case you have dynamic elements on the clientside like DHTML, AJAX or you name it you could define your own xml tags which are transformed to richer client side objects after the designer did their work. I guess the designer will understand the usage of these special tags and you provide the proper translation into client side objects.
I used this approach with some coworkes based on PHP. PHP was only the driver for the transformation. The content was assembled into xml with special tags which were transformed into XHTML and CSS via XSLT. Once the objects and the transformation for the different objects is defined you build up a library which can help to shorten the developement cycle of new pages of you webapplication. The benefit of the extra work is, that you designer can change the layout of the page without ever touching you server side code.
Maybe this helps.
Consider using either Expression Web or SharePoint Designer. The latter is now free.
I know you specify dreamweaver, but have you looked at Blend? It plays very nice with Visual Studio and is quite a nice app. to work with.
i know vb.net, but have had no experience at all with web programming. i need to make a web app that can run in a browser where there is a board game and pieces that you can move around. can someone help me get started? are there any examples in asp.net?
i need something like this:
http://www.hallofbrightcarvings.com/game/grid
i don't know what language this is built in, but i would much prefer vb.net. i would like the pieces to be pictures instead of text. please help get started.
I have a very basic example of moving pieces around a grid written in javascript.
You can see it in action here and if you take a look at the source you can see it's done with jquery mostly. Feel free to take a prod around, I haven't updated that version in a long time but hopefully you might find it useful.
I think ASP.NET can do very little for you according to what you described. What you need is either Flash or Javascript skills.
Let's decompose this, you need two things if you want to make the whole thing yourself
Client Side: Flash, SilverLight, JAVA
Server Side:PHP, ASP.net, Java
As you know vb.net and want to work with asp.net, so I recommand to use Silverlight.
How complex can this be?
Depends on what you want to build, if you want to build a Mafia war games, then you'll need to work the user interface and it'll be very hard. Also the server side will be important as you need to handle registration and relation between different players.
If you specify more your question, you could get better answers.
The example you cited above is fully client-side, which means the code all sits on the browser and the server doesn't do anything to enable the grid. So if you did a "Save As" of that page on your computer, you could run it offline.
You should use the view source functionality of your browser on the page you cited, and look at how it's built. It's done using HTML, CSS and javascript. Use w3schools to get yourself started on those three matters.
If you really need to code it using vb.net, I don't know of any way that allows drag-and-drop for web forms. I'd be interested to know though. Ajax and .net drag-and-drop should be keywords for you to look into.
To do this on the web, you'd probably want to divide the project into two components: Client-side and server-side.
On the server-side, you'll want to use language like PHP, Python or ASP.NET. I think ASP.NET has some way to use VB.NET, so that would be a good choice for you to minimize the number of new things you need to learn.
Client-side is going to be the big hurdle. There's basically two different approaches to take here:
HTML+CSS+Javascript, using HTTP callbacks (ie, AJAX) to communicate with the server.
Flash using Flex (I think HTTP calls is probably the easiest way to talk to your server here as well.)
For a game like that, I would think that Flash is probably the best way to go. It will be easier to do graphics and sounds, and it'll run the same in every browser that has Flash support.
I've seen a few blog posts and tutorials overviewing mixing in jQuery and the UI elements for Views in a .NET MVC web app. But usually targeted at developers with a comprehensive grasp of the full dev cycle and variations of back/middle tier technologies.
As the front end developer I'm pitching a jQuery-only UI to the back-end dev - he cautions against a non-webforms interface for sake of the code maturity pov.
I'm trying to hit back with "well...it's your pattern ...isn't it elemental to MVC? No logic in the view? I'm reading that to be 'server-side stuff'. You just serialize the properties i'm asking for, or better...let me easily discover what you _can send me...i'll be able to implement the UI via jQuery UI."
So how valid is my position?
Can jQuery's grid be expected to handle at least the bottom 85% of .net's native control (low-to-moderate capacities # of rows)?
How about in-line editing? ...from the grid?
Would working exclusively in Web Services simplify his life at all? and if so, wouldn't that be logical way to build a .net-to-jQuery relationship? - ajax liaisoning twixt server (.net WS methods) and client?
mny thx
--steve...
Don't fight the platform. That way lies pain and suffering.
The MVC view objects are vastly different than asp.net webforms with server controls--you get straight up html. You get jquery and ajax basically for free, with (almost) magic server side ajax call processing.
They are designed to do what you ask. Writing your own jquery ui is reinventing the wheel.
Not only would it be a ton of extra work for no gain. You would be the only developer around trying to do that, and when you needed help, few could offer advice.
If this is an admin interface, and the client has agreed that users must have javascript enabled then I think using javascript to build widgets on the page is a better option than using the asp.net server controls. If however this is a public facing website I would argue that a pure html and css approach is much better, and then use javascript to progressively enhance the page!
Now I dont ever advocate using asp.net server controls, because they spit out poor markup and they are overly complicated to use. Instead I have been using jQuery to do the grunt work and dom querying and traversing. I also dont advocate using jQuery UI because they are missing some very essential widgets, for example no datatable, no treeview etc. I know that there are lots of plugins for jQuery but they are not componentised and therefore each plugin needs to reinvent the wheel to achieve everything it needs. Once you have included all your plugin libraries and css you often end up with a very large page footprint. Also each plugin often has a different home page and documentation that may or may not be up to scratch.
I think that the best UI library is YUI, and you can easily combine it with jQuery. Because each widget is made up from core components the overall weight of download is smaller. Also you have all the documentation in one place with 100's of working examples. Also it means working with the same set of javascript patterns across the board, so with each widget you learn more and more about the library. Hopefully jQuery UI will catch up, but personally I am looking forward to YUI 3 which for me might mean dropping jQuery altogether...
jQuery is a very mature library. It is used by thousands of people across the internet, and I dont think I have ever encountered a bug. YUI is dogfooded by YAHOO so it too is battle hardened.
One thing I did not mention to you is that I am using the default webforms view engine with asp.net mvc. I think it is still the best option as you get intellisense and also Resharper refactoring even searches your views, and the static solution anaylsis can find code errors in your views.
For building my markup I have been using MvcContrib Fluent Html but you could also checkout this article that advocated the DRY principal very well.
I'm in the process of designing a solution for the company I work at (but have just resigned from) which has a very complex application process in it. The process is close to 10 steps (including T&C's and preview) and also has some very tricky UI-level business rules (mostly driven by a legacy tie-in system).
Essentially the validation is driven by what has been selected on previous forms, and not just the one directly prior.
The solution has already been decided as an ASP.NET application but the more I design the solution the more it's looking like it's going to be very difficult to achieve in a stateless environment. It's going to either end up with query string parameters, hidden variables on the page, viewState or session to pass the information around.
Then I had it suggested that I look at Silverlight, to give it a more stateful environment and make it easier to handle the passing of the parameters around.
I've never done anything with Silverlight, other than watch presentations, so I've got no hands-on experience with it, but from everything I've read I think that it does have potential to solve some of the major problems which I can see coming out of trying to do this with standard ASP.NET.
So how do I go about:
Is Silverlight a viable option considering what I mentioned above?
Pitching Silverlight to a company without any Silverlight skills?
How do you deal with the "but it requires a browser plugin" argument?
From what you're saying your problem is about keeping state between multiple pages/forms. Sessions are good for that (not so much the query params or hidden variables as those can be tampered with, just having to think about that possibility when developing your app will slow you down.) I'd recommend that as simplest all round.
However, you can also put several forms on one page and submit them together, but have it look like different pages using javascript. It wouldn't be too hard to do with any decent javascript library, but I recommend jQuery (Microsoft is adopting, over their own, as the standard for ASP.NET)
Same as the silverlight problem if your company doesn't have many skills in javascript, but at least it doesn't require a plugin.
Don't get me wrong, I love silverlight, I love it so much that when it gets market share similar to flash, I'd drop HTML/css/javascript. It just doesn't seem to fit for you though.
I currently work for a company that builds its primary LOB app in Silverlight.
Silverlight may be a good choice for what you are trying to do, but consider:
Using Silverlight won't reduce the complexity of the application.
If you're already comfortable with ASP.Net, you can deal with complex workflow using existing idioms (Session state, the wizard control, or plain old CLR objects of your own that implement a decision tree/state machine model).
If your problem is really an issue of workflow design, you can integrate ASP.Net apps with something like Windows Workflow Foundation. However, "won't reduce the complexity of the application" probably applies to this, as well; in my limited experience, Windows Workflow Foundation hasn't made building workflows simpler, either.
What you gain by having state all wrapped up in local client objects will most likely be smaller than the cost of learning Silverlight and its idiosyncrasies.
That being said, there's nothing wrong with the idea of attacking this kind of problem in Silverlight. It's just not a silver bullet or anything; Silverlight has its own data access headaches, quirky UI code idiosyncrasies, and requires wrapping your head around yet another model for developing applications.
Silverlight has a Page class that enables you to easily support navigation where you can go back to the previous page as you do in your browser. I think Silverlight pages and the navigation framework is very suitable for the kind of application you have described.
Using Silverlight enables you to create a very rich client experience. Doing that is probably also possible in ASP.NET to some extent, but I find all the moving parts in a traditional web application (HTML, CSS, JavaScript etc.) and their interactions much more complex than the Silverlight model. If you don't have experience using Silverlight you could create a simple page navigation prototype without any real logic to get a feel for the experience. If you are satisfied you could then show it to management to demonstrate the power of Silverlight. If they like eye candy you could change the visual theme of your application in an attempt to impress them. This tactic may backfire, though, if management actually prefers battleship grey.