How do I use JQuery on a View - javascript

At work I have been thrown in the deep end. A customer required some functionality on the web and one of our devs knocked together an ASP.Net webforms project.
When I started, because of constraints I got handed this project. I am not a web dev (I've dabbled) but because of the work I have put into the project, the customer is now looking for more functionality to be built into the web solution.
I would like to take a look at MVC (on my own time). With a view of converting the project to it. I come from a Xaml background so MVx jives with me.
I seem to have most of the basic theory nailed down except for one thing. What is the best way to use JQuery on the view?
Should the controller just pass back semantic data and the view (via JQuery) makes it pretty / unstatic (with help from JQuery UI).
I am confused but from what I can gather is it correct to assume JQuery (in terms of MVC) is like a client side View engine that would handle things like theming, hiding controls, simple validation, popups, etc?

jQuery (and JavaScript in general) can be used to enhance the behaviour of a page. I say enhance, because it should basically work without JavaScript. About 2% of users do not have JavaScript enabled.
CSS should be used to enhance the presentation (or styling) of a page.
The HTML itself is effectively a vector for your raw data which also provides a semantic context. For example, data in a p tag means that that data is a paragraph. Browsers have CSS defined for HTML elements so that by default, the raw data with a semantic context will look vaguely sensible.
So, with regards to "is it correct to assume JQuery (in terms of MVC) is like a client side View engine that would handle things like theming, hiding controls, simple validation, popups, etc?":
Theming should be done using CSS, as it is presentation. The theming you get from the jQuery UI library just gives you some CSS, which is fine.
Hiding / showing content based on events, popups and validation should be done server-side, but JavaScript can be used as well to enhance the behavioural experience.

Pretty much exactly as you said, the controller should pass data to the view which should be rendered using HTML and structured using CSS.
You can then use jQuery to add validation/dynamic effects/ajax etc.

I think you should see Javascript more like an addon to mock things up. For example:
You've got a serverside validation, but you don't want to reload the whole page all the time, then the javascript is good, but it's an addon, because when you don't have a serverside security, someone who hasn't got javascript turned on, or simply doesn't have it, is going to bypass your security easily.
Jquery in this case, is to make those tasks easier to implement.
I know in ASP.net the hiding of controls and the form submits are standard javascript. But it isn't good practice to do this.
Implementing it in MVC is easy as you just need to put it in the scripts map and then load it with a method in your cshtml page.
For more information about how to build your webpage for alot of browsers, i would recommend you searching after progressive enhancement.

Related

MVC5 vs Angular JS

I've been working with ASP.NET MVC for about a year now. I enjoy the ability to create SPA's especially by using the following tools:
Partial views(via html.action() and renderPartial())
Ajax helpers (Ajax.Actionlink() and Ajax.beginform())
My question is, Is it safe to just continue without a JavaScript frameworks or am i seriously missing out on something by not utilising a Javascript framework like Angular JS.
This depends a lot of the type of application you are building, but in general you don't necessarily have to choose between ASP.NET MVC and Angular, you can use both in a project.
For example, if you have a page with a grid where the user will add rows and you have to calculate sums etc you could use angular on that page (and it will speed up the development process).
But if you have pages with static content you can just serve an html file there using ASP.NET MVC.
And you can even use both of them. For something like a blog post, you can use a static html file for the post content and then implement the comments are with angular.
Since ASP.NET is a server side framework, it can only go that far as AJAX insertions. Angular JS is a client side Framework, designed for SPA in mind. If you are going for a light SPA, ASP.NET will do nicely, but I think you should use the right tools for the right job. Don't hesitate to mix them in order to find the right place between server side rendering and client side dynamism.
You are definitely missing some things.
The purpose of frameworks such as angular is not just to handle your bootstrap tab switches or whatever to display just parts of the UI rather than everything. Sure, you can create small and simple SPAs by utilizing such logic but once you come to create real-world apps that approach will become unusable. The reasons to this are:
Your site will be highly unmaintainable
Frameworks like angular provide much more than just templating (more on that in a moment) but features such as routing, which allows on-demand content loading. That is, instead of sending the whole page to the client, much of which (s)he maybe will not even take a look at, you can load fragments of HTML on-demand, which reduces network usage. Imagine you had to download everything (posts, images, videos, chat messages etc) on Facebook and hide them until you actually want to see them.
Back to templating, this is a very powerful feature. Again, in the case of simple apps you can use custom JS code - that is, concatenate strings to create fragments of HTML and then insert them into the DOM. But even with simple apps this is a smelly thing to do. Imagine you had to write custom JS to concatenate your chat messages in an app like Facebook then insert them into the DOM. With angular2, for example, you can do something like this:
<ul>
<li *ngFor="let msg of messages">{{msg.Sender}} said: {{msg.Content}}</li>
</ul>
This way, Angular2 will do all the parsing and DOM handling for you. That is, you write declarative markup rather than imperative logic for what you want to display.
All in all, they help you to decouple the logic from the UI so you should definitely dig into any of the popular frameworks and get a taste of their capabilities if you want to create rich apps. You will not regret it.

How to create Re-Usable web control library

Question background:
Hello everyone, I have been developing windows form application for my employer for about 3 years. Though most of my works are amateurish. I've been using visual studio, c#, enjoying creating re-usable windows form controls by sub-classing and other techniques. Now my boss want me to make website for this company, the first thinking in my mind is to create re-usable WEB controls just like windors form application.
The methods I have tried
Web User Control, At very first, I found visual studio support developer to create Web User Control, with file extension as *.ascx. I was very exciting to find this because I thought I can create Web controls just like I did in windows form application development. BUT, it's a very big "BUT", I then found that it cannot be embed to assembly file (DLL), and either can it be displayed in ToolBox to support drag and drop in web page design time. AFAIK from msdn, the Web User Control is not intended to be re-used across projects. So I give up this method.
Server Control, then I found there is Custom Server Control can be created to support assembly embed and ToolBox. It's a *.cs file that written with a class which sub-classing from System.Web.UI.WebControls.WebControl or System.Web.UI.WebControls.CompositeControl. Good point is that this is exactly what I want: re-usability and design-time support. HOWEVER, the huge disadvantage is that it doesn't support drag-drop when creating the web control itself. The control can only be rendered by html written in c# or be created by code. And I have to embed css/javascript to the control if I want to create more beautiful, complicated or efficient control. Anyway, from MSDN, Server Control is what I need.
Pure HTML, Javascript (jQuery), CSS, actually I've beening working with Server Control method for a while, just in order to make my boss happy. But I still cannot stop thinking about other better solutions. From my understanding, web page is not that complicated, it's simply constructed (please correct me if I'm wrong) by HTML tag, javascript (or other scripting language), CSS to manipulate UI. So I believe if I create web control by pure Html, Javascript and CSS, it will be of course more complicated but more compatible. Because Server Control solution requires the web server support .Net Framework, which is not free and limited to Microsoft scope. If I have a way to get rid of .Net, why NOT? I'm willing to spend double-time to create Re-Usable control if it's worthy to do. For example, if I want to turn to PHP to create web page, I might have to acquire the technique to create my web control simply by HTML, Javascript and CSS.
My question
Speaking all of the above, is it even possible to create my web control library only based on Html, Javascript and CSS?
If so, is there any tutorial about this method?
I really would like to know that how does commercial/professional company create web page.
Thank you everyone, any advice will be very much appreciated!
Speaking all of the above, is it even possible to create my web control library only based on Html, Javascript and CSS?
In strict speak, the controls you have become accustomed to support the aforementioned. This will continue work in future projects created in WebForms.
However, if you foray into MVC then there is a striking difference. Most of the controls that handle input are client side (which can be wrapped in js wigets and user validation classes). On the other hand there is very little server controls, however there are _MasterLayouts and Views that can make use of PartialViews a PartialView is similar to a Web User Control. In your Controller you can return EditTemplates and other types that would be similar to Server Controls
After digging for a few days, I almost give up creating my own javascript library not just only for web widget(UI), neither I would like to use third-part js frameworks because:
Cost too much time: as it says: 'do not reinvent the wheel', well, I accept/disagree with this point half by half. But now, I simply do not have too much time on it. It really really cost time, can hardly complish by an individual person.
A lot javascript frameworks are so great, like dojo, yui, jqui, as #dandavis commented, BUT, the usage of some is difficult, at least for me (as a js beginner), especially dojo. Dojo is very powerful, AFAIK, but it's hard to implement and use. I followed official tutorial to create my own web widget, spend a hour and not get it done. I might give up too fast?
I still want to dig asp.net with ajax, it is much powerful. And can easily manipulate on server side.
Well, I don't know if it's an answer but this is my personal end of my question. Thanks a lot guys.

Javascript Single Page MVC from scratch

I just wondering what is the technique of creating a single page website by using javascript without using framework like ember js / angular js.
For example in php like they can get
example.com?view=homepage
Can easily get the view and load/display homepage and load homepage's content.
What if in javascript if want to load another page/content?Any technique for building it?
I just building with a simple function like
$("#otherpage").hide();
$("#homepage").show();
I don't know is it the best way to develop a javascript single website page with this way?Or any technique that you all can suggest, cause I need learn from basic, need use javascript to explore and create a single app page without php.
Thanks lot
If it was that easy, do you really think Ember, Spine and Angular would be that widely used?
Snarky comment aside, building a page that refreshes like what you've done, while simple and rather easy to modify, falls very short on quite a few things:
For sites larger than a couple of pages, your HTML markup will become MASSIVE. Not just that, but you'll have to run every single piece of code on every page...per page. Say hi to insane overhead, both on bandwidth and on server-side processing, even with caching.
If you want to dynamically update part of a page, you'll need to use AJAX anyway. Why would it suck to write stuff using an MVC approach from the get-go, rendering data as you go along with AJAX, rather than brute-feeding the entire DOM?
What is the problem with Angular, anyway? Widely used, bug-free, unit-tested, built by reliable people, and if a bug does go through, you can be sure that the community will fix it quicker than you could
If the last comment didn't dissuade you from building your own to replace an already-existing platform, I would strongly recommend you build your JS to be fed data (JSON or otherwise) from your server and to dynamically update the page. You might not want the full-blown MVC approach, but at least the MV part of it. This will also allow modularity.

JavaScript to generate/render dynamic HTML form from JSON or similar data?

I would like to offer viewers a contact form that is modified according to the user's input. An example of such a form is on the Ext JS site.
I have not looked into the product, but I would like to know if there are any other programs/functions that generate such a form dynamically? I found only samples on adding other input elements to existing forms.
Here are some other implementations:
http://neyeon.com/p/jquery.dform/ (depends on jQuery)
http://neyric.github.com/inputex/ (depends on YUI)
http://robla.net/jsonwidget/
I also plan to add this functionality to my own js-forms library, which would also handle validation.
You can always create whatever DOM structure you like using JavaScript. Be it additional inputs or even additional FORM elements. It then depends of course what you use on the server side to process form data and how you do that.
Maybe I haven't understood the nature of your problem because you haven't explained yourself too good.
ExtJS is a JavaScript library that does everything on the client side. It also provides the ability to rapidly create user interface by providing Javascript configuration objects that will result in rich widget creation.
You can do lots with jQuery (and jQueryUI) as well, but it's up to you how to do it. ExtJS just has these very functionally rich and visually consistent set of client controls/widgets that you can use out of the box without much additional development (not to mention bug killing that comes along custom development).
For instance: When writing an Asp.net MVC application it's very easy to issue an Ajax call that would return HTML of so called partial view with complete HTML of your form that you can then easily display in a modal dialog for instance.
If you do need all that functionality to create a desktop-like application I suggest you do take a plunge into ExtJS because it is definitely a very good product. I've used it about 3 years ago (version 2) on some project and I was amazed by the work they've done with it. It's very feature rich product that makes it really easy to create desktop like web applications.
But if you're after a usual web site then a desktop-like experience is probably not what you should give to your visitors.

Growing into JavaScript as an integral part of the front-end vs. 'DHTML'

More of a general question here.
At the moment a lot of the projects I work on utilize server-side views to render the user interface, and spruce it up with some JavaScript here and there. That is all fine and dandy for smaller projects, but lately it seems like the .js files are growing rather large in size, and the stacks upon stacks .live and .bind jQuery calls just don't seem to cut it anymore.
What are good ways to blend JavaScript into the view and, perhaps, the controller of a web application? For the Java-driven websites I found DWR to be quite useful, but a lot of times user initiated events require controller logic, which is starting to become overwhelming and confusing when it's part of the many lone functions included on the pages.
I considered a completely AJAX-driven template engine but that seems to be a bit extreme and will likely be a pain in the butt for anyone to use. Cloning the functionality of the existing backend classes, on the other hand, seems redundant.
What is a good "middle ground" approach used by web apps out there, those that aren't entirely AJAX free nor completely JavaScript driven?
EDIT:
Perhaps I'll provide an everyday example of a problem. Say I'd like to provide the user with a modal dialogue confirming or denying something:
"Your picture is uploaded but looks terrible. You need a new 'do." (OK | What?)
Now, in one scenario, that dialogue could pop up as a result of uploading an image with a page refresh, in which case the server-side view will render it. In another scenario, it might appear after uploading the image via AJAX, in which case it'll probably be triggered by JavaScript on the page. In both cases we need to access the dialogue creation code, and I can't so far think up a way to have, say, a Dialog class which would work the same in both cases.
I'm certainly not an expert in this realm, but in the past have worked with projects utilizing RESTful services which seemed to fit the 'AJAXY' world of web site development nicely. I can't say it'd be ideal for web apps, but worked great for content-rich presentational sites. It seems like it'd fit your need for multi-presentational formats nicely via custom templates. So, the service could call the pictureUpload service using a HTML page template, or it could call the service and request the AJAX component template.
I've been working recently with JavascriptMVC (2.0) for an internal company app. It has its warts, but the overall architecture is good and allows you to create "controller" JS classes. Each controller "owns" a subset of the DOM tree (or if you prefer, a visual part of the page) and responds to events within that zone and uses EJS templates (the "view" part) to alter areas under it. It nicely abstracts what would otherwise be a lot of $(...).bind() and $(...).live() calls into an OOP model.
In my case, our interface is almost 100% JS-driven due to the constraints around the project, but there's no reason you can't mix-n-match.
Now, in one scenario, that dialogue could pop up as a result of uploading an image with a page refresh, in which case the server-side view will render it. In another scenario, it might appear after uploading the image via AJAX, in which case it'll probably be triggered by JavaScript on the page
Here's how I'd do it in a way that works even with Javascript disabled:
Server-side outputs an HTML upload form. The plain-HTML form will submit to another PHP page.
A snippet of Javascript runs when the page finishes loading, looking for that form.
The javascript creates a HairdoUploadController instance, passing in the <form>...</form> to the constructor.
The controller "takes over" the form, using JQuery selectors to alter the styling and to trap the form submitting events.
The controller adds a new div and associates it with a (initially hidden) Jquery-UI Dialog.
When the form is submitted, the controller instead makes an AJAX call, to a slightly different URL than the plain form.
The results of the AJAX call are pushed into the Dialog's div, and the dialog is displayed.
You can throw all logic at the server, and assume a dumb client that displays whatever the server sends.
There are two scenarios:
Non-Ajax Request
Ajax Request
The only difference between them is that, in the first one you're rendering more content than just the modal dialog. There's no reason why you can't have a Dialog class on the server which spits out the HTML representation of the dialog, and is used for both types of request. Then in the AJAX call, you would simply add the server's response into the DOM.
Like you said, it can be problematic sharing UI creation logic on both client and server side, so it's better to choose one and stick with it. In the above case, all logic is pushed to the server. Read up more about AHAH.
It sounds like Google Web Toolkit might be what you're looking for.
It allows you to write client-side
applications in Java and deploy them
as JavaScript.
Presumably then you could write the code once in Java and use it in both places, although I've never used GWT myself.
In my own framework that I'm developing, I'm basically forcing developers to write the code twice. Once in the native language, and once in JavaScript. I make them fill in a function which returns the JS, and then it can be called automatically where it's needed. But all the code is contained within one class so at least you don't have the logic spread all over the place, and you can quickly compare if they are functionally equivalent. For things like regular expressions, it can normally be written just once and then passed to JS (I use it to validate once on the client-side, and then again on the server-side).
I have found myself recently using my server side code (ASP.Net MVC in my case) as a means to provide re-use of my layout components (master files), and small encapsulated bits of UI (partial views), and doing a fair amount of work in javascript. In this particular case I'm still pretty early in my UI work, but with jQuery and jQuery UI I've got a lot of functionality in a very small footprint.
I think one of the challenges to having a mixed solution is figuring out where to put the various bits of logic. After that the rest of it probably goes to figuring out how to re-use as much of your javascript and css code as possible. I still haven't figured out how to manage the various javascript artifacts I end up with (though the Google CDN relieves a lot of that by providing jQuery, jQuery UI, ans the jQuery UI CSS resources).

Categories

Resources