I've seen a lot of stuff online that shows proof of concept tutorials of how Silverlight can be used to enhance web pages by handing tasks off to it to make use of threading, manipulate the DOM, achieve Comet-like functionality etc.
It all seems very interesting, however, has any one got any real world use cases to share as I can't seem to find many.
Sure. I have used the HTML DOM interaction for several reasons.
First, when migration an existing ASP.NET application to Silverlight. In the architecture we worked with, the application was very heavily AJAX-based with plenty of callbacks. Instead of reinventing the wheel for Silverlight, we were able to use the DOM interaction to provide a bridge so the Silverlight control could callback in a similar fashion. This meant using the ASP.NET security and viewstate information to fetch information from the server and pull into the Silverlight application. We were already returning data in a JSON format so it was straightforward to parse back into the Silverlight application.
Another example is interaction with third-party controls and services. For example, Google Analytics provides rich page tracking features. This project provides a prime example:
http://silverlightanalytics.codeplex.com/
Where the application can integrate and even though you are running in Silverlight, you are essentially tracking clicks, actions, and page views.
Another place I've used this is when Silverlight isn't used as an application, but instead more of a part or a control on the page. While Silverlight controls can communicate with each other using the local communication, this doesn't work with other non-Silverlight controls. By using the HTML-DOM bridge you can easily build JavaScript-based communicatin between the components. Maybe the Silverlight control, for example, is an interactive world map that allows you to browse to a region. When you select the region, it raises a JavaScript event that the other controls listen to and update based on that reason.
You can also use Silverlight as a control like a Captcha control where your form uses the DOM bridge to validate user input into the Silverlight application.
I've seen tag cloud applications where the Silverlight control uses the DOM interaction to walk the current page and then generate an animated cloud of tags based on this.
Hopefully those provide some real world examples.
One thing I've used the DOM-Bridge for is to raise events. The html pages that host my application subscribe to these events and react consequently.
For example, my application receives and displays sales data coming from a WCF webservice. When the data changes, an event is raised so that the rest of the page can display other things.
If you can't use ASP.Net, asking and receiving data from a webservice is much easier and less error-prone in Silverlight than in Javascript (and is also faster because you can use the optimized "binary-xml" encoder).
I think the DOM bridge is most useful when you distribute a silverlight app to be embedded in arbitrary websites where you can't make assumptions on the backend environment but need to provide ability to interact with the SL app.
Related
I recently added a roles/permission functionality to a somewhat old web forms app in ASP.NET and C#. Now I need two simple functions: add/edit roles, add/edit permissions to roles (permissions are in a table but not modifiable). The tables are somewhat like this (I need an interface for the bold ones):
Roles table: RoleID, RoleName
Permissions table: PermissionID, PermissionName
Roles_Permissions table: RoleID, PermissionID
How can I make them interactive, in the sense of not having a post-back, and having both functionalities in the same page? I visualize a dropdown for the Roles, that when one is chosen, the list of Permissions refreshes for that role, and right there the user can change the permissions, RoleName, or even add/delete a role. The page needs to use an existing master page to match its appearance to the rest of the web app; I do not know if that would limit functionality.
I need the implementation to be as non-intrusive as possible (no strange plugins, and work with current browsers without any configuration on the client side). I found breeze, knockout and angularjs, but can't find if/how I can add the functionality to an ASP.NET C# Web Forms in Visual Studio 2012 (version 11).
What is the fastest/easiest way to build the page, that will be easily maintainable in the future, and be a good starting point to begin "modernizing" the rest of the web app based on it?
You can add a standard blank aspx page to your application and get it working as normal for a Web Forms application. Wire up the navigation, make sure that it picks up your master page (if you are using one), etc.
From here, depending on various circumstances, you can do a couple of things.
ASP.NET AJAX
This was originally introduced for ASP.NET Web Forms, and uses Web Forms controls and a small amount of work in the codebehind to glue everything together. It's less flexible than other solutions, but should be fine for the scenario you cite. This would be the preferred method if you are more comfortable with Web Forms than other programming models. Policies or the structure of the existing application may also make this more preferable.
Single Page Application
You mentioned frameworks such as breeze, knockout, and Angular. So, let's focus on those. Again, depending on your experience, and the app, these might be compelling options. I wouldn't go as far as Angular for the time being, since it's more appropriate for a full rewrite. It could work embedded in another application, but is probably too much work for the scope of your project.
At minimum you could make do with plain JavaScript and AJAX, but you'd need to write a lot of your own code. If you add in a little jQuery, that will help with DOM manipulation and AJAX calls to your services. I've had success in enhancing older apps with jQuery for DOM manipulation, and Knockout for databinding. You can probably make do without jQuery, but I wouldn't. These two libraries don't make any assumptions about the environment that you are using them in, and should be content to be constrained within the limited scope of a single page within a larger application.
I inherited a large framework (my employer purchased a product) that uses ASP.Net modules (.ascx files loaded dynamically by Default.aspx). The product did not, of course, come with its tests (at least, I assume the product has tests).
Because the ASP.Net postback client-side experience is awful, I've started adding more modern, Javascript-heavy functionality both to the existing modules, and in the new ones I create. Due to how the system works I really cannot move away from the module-driven framework currently in place into an MVC setup.
I'm looking for a test framework that can access both the browser and the back-end framework. I think I've come up with a set of requirements for this framework/combination of frameworks:
MUST handle navigation to multiple pages (wizard-like behavior).
MUST handle new window popups.
MUST handle DOM manipulation via Javascript (showing/hiding elements).
MUST emulate mouse/keyboard input on pages.
MUST be able to query/validate Javascript variable states.
MUST be able to query/validate back-end SQL Server.
MAY be able to query/validate back-end ASP.Net state. (Nice to have.)
Ideally it would have integration with VS's Test Explorer, but that's not a hard-and-fast requirement.
Does such a framework exist? The google searching I've done has come up with plenty for single-page Javascript-driven sites, MVC sites, and plain ASP.Net sites without pretty Javascript, but I've had a hard time finding (or recognizing) a framework to fit my needs.
So I'm afraid I might be missing something pretty fundamental here, but I really can't get my head around this - Why? Why would we want to use those JS MVC frameworks, instead of sticking with Rails, Django, PHP and so on?
What do these JS frameworks give us that can't be achieved by the old web frameworks? I read about SPA, and there's nothing I couldn't do there with ASP.NET MVC, right?
I'm really baffled by hearing all the people at work wanting to leave our current framework for these new ones, and it's much more than just for the sake of learning something new.
I am totally up for that, and I've always tried playing around with other frameworks to see what I'm missing, but perhaps these new technologies have something really big to offer that I simply cannot see?
Single page applications provide a better experience by having all page transitions be seamless. This means you never see the "page flash" between user actions, in addition to a few other user experience improvements.
Front-end frameworks also generally provide a common way to interface with APIs. So instead of writing an AJAX wrapper for every page in your site, you just say 'This page has this route (path), hooks data with this schema from that API endpoint and presents it with these templates and helpers.' There are many proponents of APIs, because there are many good reason to write you applications from a service standpoint. This talk sums up a lot of the points in favor of APIs. To summarize:
Orchestrating your web offerings as services makes them inherently decoupled. This means they are easily changed out. All the reasons behind strong Object Oriented design principles apply equally to the larger parts of an application. Treat each piece as an independent part, like a car, and the whole platform is more robust and healthy. That way, a defect in the headlights doesn't cause the motor to blow up.
This is very similar to how a SOAP WSDL works, except you have the auto creation tools right out of the box.
Having well defined touch points for each part of your application makes it easier for others to interface with. This may not ever factor into your specific business, but a number of very successful web companies (Google/Yahoo, Amazon AWS) have created very lucrative markets on this principle. In this way, you can have multiple products supported by the same touch points, which cuts a lot of the work out of product development.
As other point out, the front end framework is not a replacement for the backend, server technologies. How could it be? While this may seem like a hindrance ("Great, now we have two products to support!"), it is actually a great boon. Now your front and back ends can be changed and version with much less concern over inadvertently breaking one or the other. As long as you stick to the contract, things will "Just WorkTM".
To answer your additional question in the comment, that is exactly correct. You use a front end framework for handling all the customer interaction and a completely separate back-end technology stack to support it.
I'm forgetting a few good ones...
Angular, Ember, and Backbone are client-side JavaScript frameworks. They could be used interchangeably with a Rails, Django, or PHP backend. These JavaScript MVCs are only responsible for organizing JavaScript code in the browser and don't really care how their data is handled or persisted server-side.
Django/Rails etc are server-side MVC frameworks. Angular/Backbone etc are client-side Javascript MVC frameworks. Django/Rails and Angular/Backbone work together - in a single-page app, usually the server-side MVC will serve the initial HTML/JS/static assets once, and then once that is done, the client-side router will take over and handle all subsequent navigations/interactions with your app.
The difference here lies in the concept of what a "single-page application" is. Think about how a "regular" web Django/Rails website works. A user enters your app, the backend fetches data and serves a page. A user clicks on a link, which triggers the server to serve a new page, which causes the entire page to reload. These traditional types of websites are basically stateless, except for things like cookies/sessions etc.
In contrast, a single-page application is a stateful Javascript application that runs in the browser and appears to act like a traditional webapp in that you can click on things and navigate around as usual, but the page never reloads, instead, specific DOM nodes have their contents refreshed according to the logic of your application. To achieve a pure Javascript client-side experience like this in a maintainable fashion really requires that you start organizing your Javascript code for the same reasons you do on the server - you have a router which takes a URL path and interacts with a controller that often contains the logic for showing/hiding views for a particular URL, you have a model which encapsulates your data (think of a model as roughly one "row" of a database result) which your views consume. And because it's Javascript there are events going on, so you can have your view listen for changes in it's associated model and automatically re-render itself when the data is updated.
Also keep in mind that you don't just have one view on the client side, there are usually many separate views that make up a page and these views are often nested, not only for organizational purposes but because we want the ability to only refresh the parts of the UI that need to be refreshed.
The intro to Backbone is probably a good starter on the topic: http://backbonejs.org/#introduction
Check this article, there is well explained how a modern web application should looks like in the client side, server side and the communication between them.
By the way:
Client side -> Ember, Angular, Backbone, Knockout.
Server side -> Django, Node, Rails
I'm looking to create a cross platform Mobile App and have been looking into Developing using PhoneGap. I'm an amateur programmer and most of my knowledge is in ASP.Net and C#.
Will only being able to use HTML, CSS and Javascript with PhoneGap limit me to specific functionality of my App? and would migrating to HTML5 help in adding more functionality to an App?
I'm looking to be able to Populate Drop-Downs from a Database, Add/Edit/Delete Items from a Database, Create Reports Ect...
Your only real limitation as far as data access goes is that you're limited to an SQLite database, which to be honest isn't much of a limitation since it performs great for single-user access.
The short of it is that you have access to a database from within your app, so you can do whatever you need to. The tools are HTML & JS as opposed to C# with some graphics layer, so doing things like creating graphs is quite different, but it's all possible.
Also note that depending on what your app is doing, PhoneGap is one of several solutions. If you want a "native" look/feel, consider TitaniumUI -- it takes common code (still JS) and pushes it through some translation layers to create native UI components.
I often find myself wondering what is the best way to do a JavaScript based web application. The server may be PHP, Perl or whatever -- but when the client-side is ExtJS or something similar, how do you construct your application? What is the work flow exactly?
For example, how is the authentication handled? In a current application I am developing, I have an ExtJS viewport with a login screen component in it, when the app is being run, it does an AJAX callback to the server to find out whether it's authenticated. If not, I show the login part -- else I show the application viewport. And then depending on the URI hash (e.g. #page=settings&subpage=ui) I run automatically certain components and events in my system.
And what do you do with the back-button. Currently I have a timer that checks if the hash has changed, and if so, I run the new action based on the new hash.
I am interested in any application work flow or logic that you have to share with me -- or any resources you got. I feel like JavaScript based application development has not matured enough yet, because there is almost zero blogs, tutorials, articles, whatsoever talking about this kind of stuff.
One option would be to leverage some of the capabilities of popular frameworks such as Spring MVC. Spring has the ability to handle workflows.
Spring Webflow Introduction
The whole point of a web application is to have your business logic happen on the server-side and not the client. JavaScript can be pesky enough to debug on it's own. Things that are business-logic heavy is best encapsulated in it's own tier of your application.