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.
Related
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 :).
I'm scratching my head on how to accomplish the following task: I need to write a simple web forms filler/submitter with QT C++, it does the following:
1) Loads page url
2) Fills in form fields
3) Submits the form
Sounds easy, but I'm a web developer and can't find the way how to make QT accomplish the task, I only managed to load url with QWebView object using WebKit, have no idea what to do next, how to fill in fields and submit forms. Any hints, tutorials, videos? I appreciate this.
QWebElement class does all the work, just reading through the class documentation gave me a full idea on how to accomplish my task. Thanks to eveyrone for suggestions.
The best solution would be to write the logic in JavaScript that does what you want and then inject it into the page using QWebFrame::evaluateJavaScript() after it finishes loading.
There's also another way to do this; involving the document tree traversal API that's been available in QtWebKit since 4.6: QWebElement. You'd basically process the form pretty much the same as you would do in JavaScript, except that here the API is different and more limited. It's C++ though and might be a little bit faster. I guess, this approach might be less attractive for you, given you're a web developer and probably already know JavaScript.
I still find myself hand coding Visual Studio projects more than using the variety of UI-driven menus and dialogs. For example:
web projects: hand code html/css in Source View vs dealing with the Design View / Properties Window
flushing out class files: code by hand using stuff like the prop-TAB-TAB Create Property keyboard shortcut and good ole Ctrl+[X|C|V] instead of the Class Diagram feature
Do I need to give the dialogs and menus another shot, or is this the current state of IDEs? Intellisense is the best thing since sliced bread IMO.
Steve
I'd be quite content to have Microsoft remove the design view from Visual Studio. I find myself cursing it every time I accidentally hit the button and wait ages for the broken rendering engine to kick in. This is from the perspective of a web developer mind you - I'm sure it's essential for developing windows apps.
Generally I think most of the RAD tools are not particularly useful, and in the long run end up being problematic as they're not very flexible. When developing web forms asp.net applications the listview and repeater are generally the only controls that I use. Hand coding html/css would be the preference for most designers anyway. Tools like Dreamweaver are nice initially when you're learning, but you do get to a stage where you realise you're using them as a glorified text editor.
Intellisense as you mention is utterly bad arse, and the one thing that I would miss if I switched to something like e or Textmate.
I am not a .NET programmer, and I understand Visual Studio does provide a lot of nifty code generation tools. However, I think it's rather important that a developer knows the code in his application. If you feel comfortable hand-coding it because you feel more in control that way, I don't think that should bother you at all.
Also, as someone who writes a lot of HTML/CSS by hand, I know that Visual Studio's Design View does not churn out 'quality' front end code a lot of the time.
I personally hand code html/css as well as my class definitions 99% of the time. Exceptions would be things that would be hard to hand-code otherwise (does anyone hand-code WCF proxies?)
It's all about YOU. What makes YOU more productive. What makes more scenes for YOU.
It's good to know and learn alternative ways to achieve your goal. You can give it try but if it slows you down return to the way YOU used to code.
I certainly find the the UI designer only works for the simplest of pages, and even for them only for a few design iterations. I find this for two reasons
1) When laying out a page, there are often several legitimate choices, and I don't like the choices VS makes. For instance, it will set the width of tables using pixel sizes, while for most fluid pages percentages make more sense. Nothing wrong with what it does, but for whatever reason I find myself fighting it more often than not.
2) It hard-codes a lot of style information, and even creates synthetic styles in an in-page style sheet. I'd rather have a concise and comprehensive CSS for the site as a whole, minimizing overrides on each page (or in each element!). Again, I fight it more often than not.
Well the designer for WPF/Silverlight is pretty cumbersome to use. So I pretty much hand code xaml and C#. At the moment I do not do much asp but with MVC, I would assume I would hand code that.
With visual studio having intellisense for a lot different syntaxes now, it is easier then ever to hand code, well, code. :) I mean intellisense works for C#, CSS, javascript, asp, and XML (if set up right). It is pretty easy to code now days. The youngsters have it so easy now days. They do not know how hard it was to code back in the day.
I'd say it absolutely, 100% depends on what you're writing.
If it's a basic CRUD interface for a simple database, then I'd say yes, 80% is way too much.
If it's a Web Application with plenty of JQuery UI and no persistent data source, then 80% is probably less than I'd expect.
As Vadium said, it also depends on what makes you more productive. Personally, I fly along with Intellisense, but I'm not too good on using UI tools to build an app.
I always feel dumber using Visual Studio, but I have to finish my project sometime this century to get paid.
Not sure if this belongs in community wiki...
Can somebody give some general guidelines on how to successfully build an ASP.NET site that isn't dependent on JavaScript? My understanding is that I should build a functional site initially without JavaScript, and use it to enhance the user experience. That is easier said than done... how can I make sure my site works without JavaScript short of disabling JavaScript and trying it? Or is this something that comes with experience?
Try ASP.NET MVC! sure most of the examples use JavaScript for the AJAX functionality, but it's easy to build a fully functioning site that doesn't use JavaScript.
Since ASP.NET MVC doesn't use server controls with all their embedded JavaScript, it's a great way to build a site with very minimal and lightweight HTML, while still writting your data access and business logic in C#, VB.NET, or any other .NET language.
I've built working ASP.Net sites with little or no JavaScript, so it's definitely possible (just a royal pain.) The trick, and this sounds silly, is to use as few <ASP:> type tags as possible. Those all spawn various levels of JavaScript. Regular old-school HTML elements work just fine with no scripting.
So, on the extreme end, you write, say, your form using all plain-vanilla HTML elements, and then you have that form submit point at another page that accepts the form submit and hands it off to your server-side scripting.
To put it another way, pretend that all you get with ASP.NET is a snazzy server-side programming language and you're writing HTML in 1998.
Now, having done this, I can tell you that what this ends up as is a classic ASP webpage with cleaner programming syntax. ;) Most of the features that make ASP.NET "better" than classic ASP hang on JavaScript, so writing a JavaScript-free ASP.NET system is an exercise in shooting oneself in the foot repeatedly.
However, the one thing you should absolutely do is make sure the first page or two do work without JavaScript. Unlike 10 years ago you can safely assume that any browser hitting your page has JavaScript, and unlike about 8 years ago, your visitors probably don't have JavaScript turned off for speed reasons, but they very well might have something like the NoScript plugin for Firefox dialed all the way to 11. So, your first couple of pages need to work well enough to a) tell the new visitor that they need JavaScript, and b) still look and work good enough to make it look like adding your site to the white list is worth it. (In my experience, most people get the first one done, but in such as way as to totally drop the ball on the second. To put it another way - if your super fancy web 2.0 mega site starts looking like craigslist if noScript is fired up, I'm probably not going to bother letting you run scripts on my machine.)
If you want to use many of the ASP.NET controls (i.e. the DataGridView), ASP.NET pages are generated with lots of JavaScript in order to handle the events on the controls (i.e. selecting a row in the DataGridView). I think you're going to lose so much of ASP.NET that trying to have ASP.NET work without JavaScript enabled is impractical.
Disabling Javascript is the best way to test how a web site performs with out it. Good news, IE8's developer tools provide a quick and easy way to do just that. Now, having said that, often times the only thing that you can do is put up a message with a noscript tag to the effect that your site requires javascript for best function.
Many ASP.NET functionalities & controls won't work when JavaScript has been disabled. Think of LinkButton's onclick event which contains a call to a JavaScript function.
LinkButton is just an example. But there are many other things too.
If your concern is with JavaScript being disabled in user's browser then you can check for that and handle your site accordingly.
If you do decide to build the site without JavaScript then you will end up building a somewhat static web site. If your need is just to build a static website then you can go on with this approach.
Write everything with basic html forms and css, and then you will know that it works without javascript.
Once you are happy with it, then look at unobtrusive javascript, so you can modify the way the application works when javascript is enabled.
Last time I looked at some stats about this around 1% disable JavaScript, so why spend hours and hours on this when what you should do is show a message telling the user that your site requires javascript.
Use your time to be productive instead of trying to write around perceived limitations.
When does it become unavoidable and when would you want to choose JavaScript over server side when you have a choice?
When you need to change something on your page without reloading it.
Designer perspective:
When you want to give more interactivity to your web page
When you want to load stuff without reloading (i.e.: ajax for example)
When you shouldn't use:
When You don't want to spend 1000 hours in pointless tries to disable the back arrow of your browser :)
Google maps would not have been possible without JavaScript. At least not in the form we know (and love) it today. So, depending on your ambition (and requirements) clearly: sometimes JavaScript is unavoidable, even though there exist technologies that take another approach that might have worked equally well (Java Applets, RIA technologies, etc).
If I had the choice I would probably chose JavaScript over a server-side implementation for a large number of applications, but then again, it is not a black or white picture. The server will remain important for web applications for a very long time to come.
Yes, you do. Now take out your textbook and turn to Chapter One. ;)
Honestly, though, to answer your question, I don't think it's ever "unavoidable," no; you can always code for the absence of JavaScript. (Indeed, usability best practices dictate you at least try to "gracefully degrade" the user experience for browsers that don't support it, or for users who choose not to.) In the beginning, of course, there was no JavaScript -- but there was still the Web. It just, well, kinda sucked.
There's no simple answer, but if you absolutely must have one, the most straight-ahead one I can think of is to use JavaScript to improve the user experience. Secondarily, use it to shift the workload from your server toward the browser (Hello, Ajax!) -- validation, state, etc. Those are two big reasons, broadly stated, IMO.
At a stretch, you could do everything via server-side programming. Some things will be painfully slow and difficult to pull off right, but it is possible. If you want to see something clever done with nothing more than CSS, try out the search feature on lxr.mozilla.org with scripting disabled.
Practically though, the best places to use javascript are where it'd otherwise disrupt the flow of what the user's doing - the AJAXy things on here are all pretty good examples, as is the realtime preview (everyone should have one of these!)
If it provides significant benefit, then it's completely fine to use it. But please, don't make it required unless the server-only equivalent is needlessly complicated.
I never want to choose JavaScript, but it becomes unavoidable when clients want a decent web app. JavaScript has the unique feature of low latency feedback in a browser - server side code doesn't.
Also, there are a (rather limited) number of times when it's actually easier to bust out some JQuery for formatting rather than dealing with ASP.NET's event model to manipulate client elements. But, I'd say those are relatively few.
If you are looking for a responsive UI and want to avoid JavaScript, consider some of the RIA technologies such as Flex, Silverlight or JavaFX. I've been developing with Flex since v1.5 and find it very capable and productive. Silverlight is getting significantly better with each release, too.
GWT is a nice system that compiles java code into javascript which becomes kind of like a "Machine language" for the browser--you never have to consider it.
I believe most google apps are written using GWT. It's pretty slick.
All your source code is pretty much straight Java using a library somewhat like Swing.
JavaScript is not a necessity but, coupled with the DOM API, it provides a very useful medium for gradually improving the user experience of your site. Obviously the extent to which this is true is dependent on how well you execute these enhancements, don't just use JavaScript for the sake of it; it's a design decision, and should not be taken lightly.
Sharing the load between client and server.
Try to keep it natural. Use it to enhance little things, do not built your whole application on JS.
A good way to measure the breadth of your skills is when "Do I have to use ..." starts disappearing from your conversation. Hopefully you get to the point where a language is just a language, and you develop a feel for what the right tool is for the job, and can use it as comfortably as any other language.
If it's any consolation, there's increasing evidence that there's enough conventional wisdom and available toolsets that developers are increasingly preferring javascript. I personally like it for its conciseness and easy exensibility - once you get to know it.
You don't have to.
But if you want to provide UI extras like autocomplete, drag and drop, richer form entry fields, etc.…, Javascript is your only answer.
Of course you can abstract that Javascript generation out to the server side but you'd still be tussling with Javascript, albeit via programmatic code generation.
When you create a Rich Internet Application which gets loaded into a browser and which communicate to a Web Server with an Open API (like SOAP, JSON etc)
"Javascript over server side " JavaScript is client side, not server side.
You would still need to run server side stuff to get the data from the server. Javascript just gives you more control on how the client receives the data from the server.
JavaScript is unavoidable when you want a certain dynamic feature on your website which is not supported by default.
Dynamic feature
- without JavaScript: you can use CSS to change background of an element when the mouse is over the element. You can do the same thing with using JavaScript.
- Only in JavaScript: When you click the element with your mouse, the element disappears. Don't think it is possible in CSS(maybe you be able to use :active in CSS on some elements. Never tested it myself).