Hi
I have a hosted web application written in asp.net and would like to publish widgets for use in remote websites. For that purpose I believe I want to use embedded widgets over IFrame.
I therefore need some client side code to retrieve the widget's HTML from the server.
I'd appreciate assistance in the Client\ Server communication. If you have sample code to call a .NET webservice (or any other way) so that I can start by embedding this code within the widget's client UI.
I would also appreciate recommendations for the client UI library (JQuery, ...)
Thanks a lot !
Some people find JQuery the best choice for this, but if you would rather not have (or don't need) the overhead of all of the JQuery scripts, you can use a ServiceReference in a ScriptManager to call a .Net WebService. See this example for that. There are also examples of loading the HTML from a UserControl via Javascript too if that route would be more fitting for your needs.
Related
I am writing a thesis and have been able to place all my frameworks under two categories (client-side frameworks and server-side frameworks), but I can't seem to finf where to place Adobe Flex...
In which category should I place this or should I place it in some separate catgeory?
Thanks!
Flex is completely client side. I don't see where the confusion comes from? I guess it could be server side as well since the original compiler was meant to compile the code when a user accesses the site and then deliver the resulting swf, but that functionality is phased out.
In each case, the result is a client side UI.
Flex lives strongly on the client. It is a stateful framework which lives in the browser, desktop or mobile devices. It talks to the backend in the form of data services but unlike the HTML model, markup is not generated on the server but compiled and executed on the client.
Hope this helps!
The Flex Framework is a client side framework. What were the specifics that caused you confusion?
It has features for connecting with server side software; but most client side technologies do.
I have a qt main-window application from which several dialogs are accessed.
I implemented the server and client versions of the application using tcp/ip using c socket programming.
But now I have been told to make the application accessible to any web browser after username and password have been given using QHttp or any appropriate class.
I'm a beginner and have no idea of implementing this. Could anyone give some tips or examples.
I'm using qt 4.6.2
I'm not sure I understand you. You have a Qt main window which contains some widgets arranged in a GUI. You want those same widgets to be accessible inside a web browser? Then you need to re-create all your GUI code in HTML, CSS and JS.
Your Qt app can use QHttp to listen for incoming client connections. When one of those comes, you reply with a webpage (written in HTML, CSS, JS). When this webpage is received by the user, his browser will display it. When the user interacts with the webpage, you'll probably want to send some data back to the Qt server eventually. You can do this either via form posting or via XMLHttpRequest.
You should know client-side web development is not that simple. Even when you know your languages, there's lots of things to learn about browser compatibility, security, accessiblity, JS app architecture, etc.
You want to make your application into an Http server. Here is an example using Qt to get you started:
http://doc.qt.nokia.com/solutions/4/qtservice/qtservice-example-server.html
As Stefan notes, this means putting your GUI into HTML/CSS/JS and more.
Does someone can help me to understand WHERE to collocate Gwt compared to (for exmaple): asp.net or jquery ?
Does it only a toolkit client side, server side or... ?
I'd like the "final product" written with GWT but i'm an asp.net developer.. can i integrate asp.net with GWT ?
AS you can see.. i'm little confused about it!
I believe that the idea is that with Google Web Toolkit (GWT) you write in Java, but the output is JavaScript, therefore you would just need to include the JavaScript output in whatever project you are using in order to have the "deployed" version of your GWT code available.
I'm not sure why you'd use GWT with asp.net rather than crank some jQuery to sit alongside your asp.net pages. That's more of a subjective subject.
Since GWT is able to retrieve JSON data, you are free to integrate it with ASP.NET web site. But GWT is all about Java, I can't see any reason for ASP.NET developer to use it.
In case if you want to utilize it's UI widgets, you can try jQuery-UI, ExtJS or Yahoo UI client-side libraries.
Check out Morfik, it allows to build ajax apps with C#
What are the differences between jQuery and ASP.NET Ajax?
They are very separate things, jQuery is a JavaScript framework that has the ability to do some rudimentary Ajax functionality while ASP.NET Ajax is a more fully-featured Ajax framework that encompasses .NET controls and server-side aspects as well as client-side aspects.
jQuery's main focus is on a creating standard, stable, and powerful framework for working with JavaScript as a whole in the client.
Albeit ASP.NET AJAX encompasses a client side framework it is perhaps best known/feared/loathed for its server side controls, particularly the UpdatePanel. What you get with ASP.NET AJAX is out-of-the-box AJAX for the most basic stuff without having to write a single line of JavaScript.
If on the other hand you need to write some JavaScript or go a little out-of-the-box, working with ASP.NET AJAX can soon become a little tedious.
jQuery on the otherhand is lightweight and requires you to write JavaScript, although for most part, the jQuery guys has done a very good job of hiding the ugly JavaScript stuff away, so apart from a small learning curve it comes pretty natural (particularly if you are on home-stretch in CSS selectors).
Main problem in using jQuery with ASP.NET can be if you mess too much with the DOM you might get ViewState/Event validation problems.
jQuery is a standalone javascript library that can be integrated into any development environment. It it widely used and many great plugins exist for it.
It can be used for much much more than just AJAX functionality. Like traversing through current elements and changing their functionality.
ASP.NET AJAX is something else entirely, since it only focuses on AJAX like functionality in the .NET environment.
Main goal of ASP.NET Ajax is calling ASP.NET web services from client using simple JavaScript notation. It also provides client access to some ASP.NET server features. Like profile, for example. All other operations it's better to perform with jQuery.
i used Ajax Control Toolkit from microsoft quite extensively for 2 years before i switched to jQuery and in my experience i think jquery ajax calls are much more light weight, efficient compared to the ajax control toolkit libraries. besides that the efficiency ofcourse depends on the data that you send & receive via your ajax calls.
you can add custom HTTP Status codes in jQuery ajax calls as well to capture any errors on the server and returning the appropriate response.
#Andrew and #Ólafur hit the nail on the head, but I would add that the biggest concept that separates these two approaches to ajax development is that w/ jQuery you get total control of what happens between the client and the server. With the MS AJAX Toolkit you give up any control over what is sent between these 2 points. If you want to be "close to the metal" you would be best to choose jQuery. If you are just working up some quick and dirty solution that needs zero customization and speedy delivery is all your client cares about, maybe take a look at the MS AJAX Toolkit.
by the way - scott gu officially announced that asp.net would include support for jquery (full intellisense too) with their ajax framework (which is really bloated)
check this link - http://weblogs.asp.net/scottgu/archive/2008/09/28/jquery-and-microsoft.aspx
if you have used ms ajax, you would be aware its really really bloated up, and many things which ms ajax does - you can achieve via jquery writing few lines of javascript code, and you would save a lot on bandwidth and performance
you can even call asp.net json + xml web services via jquery writing just few lines of code
I have been rather successful in promoting JQuery within my organization. No small feat on it's own. However, one of the ideas being kicked around here to make it part of our app is to create an ASP.net server side control. (We are going to be sticking with WebForms for the foreseeable future.)
I'm not too wild about this approach as it seems like overkill when a couple of script tags will do the job. We found an article on the web, and the amount of code involved really doesn't seem to justify itself. However, I do hear that there is some benefit in the script caching or generating that happens with the server controls.
My questions:
Has anyone else written an ASP.net server control to serve up the JQuery js code?
Does anyone else think that this is a crazy idea to just avoid writing JQuery or Javascript code?
I know Microsoft (along with Nokia) is "mainstreaming" jQuery and will be integrating it with future versions of Visual Studio. You may want to explore how they'll be officially using it so you can tailor your setup now, and hopefully ease your transition to "official MS jQuery" down the road.
I agree with you. It is not worth the time to create and overhead to create a control to make to add a JQuery script location.
A better solution would be to have 1 .js file that has all the links required to load on the page. That could eliminate allot of .js links, if that is the issue with the team.
The only time I would excuse creating a custom control to just link JavaScript would be for whatever reason you did not want to copy the JavaScript to the server and want to be embed it into the .dll. However you will not stop people from seeing the JavaScript on the page because if you embed the files in the .dll you must register them in the header as the full script file.
One reason for using a server control for injecting the JavaScript reference is that it is easier to control which JavaScript files get added to a page. Imagine a scenario where you use jQuery core, plus jQuery UI and a handful of other plugins. Depending on how you coded this control, you could allow a developer to easily choose which features were needed for a specific page without worrying about the specific scripts needed. This approach would allow you lots of flexibility for segmenting your application: for example the server control might be used by a master pages, a child page, user controls or another server control. If the master page registered a requirement for one jQuery library, but the child page or one of the user controls requires additional libraries, then having a unified API makes this simple. Personally, I believe this is best handled by a helper library rather than a server control.
The bottom line is how much you want each developer re-inventing the wheel or using a common, simple to use API which enforces uniformity across your apps.
I found Scott Hanselman's blog post with a sample app that has ASP.net AJAX + JQuery. It's a simple app, but it includes all the javascript with script tags. I don't see any advisement to use a server control to serve up the scripts.