I'm working with my team to create an enterprise level web application with Grails, but I don't see any "out of the box" solution to dealing with browser history when using grails with AJAX. Can someone point me to some documentation so that I can nail this?
Thanks a ton.
Grails is predominantly a server-side framework. All it provides in terms of client-side functionality are some tags to make it easy to call the server via AJAX. I'm not aware of any functionality in the core framework to support using the back/forward buttons when AJAX calls are made.
You might find something in a plugin, but I doubt it. Your best bet is to look for this functionality in whichever JS library you're using (YUI, JQuery, Dojo, etc.)
Typically this is done by changing the location.hash property on the page. This corresponds to a string you can add after the current url with a #. Adding or modifying this part of the URL will keep you on the same page, but add an additional history entry.
The jQuery BBQ plugin is a very useful framework to manage the hash. It contains a number of useful methods to manage the hash property as key/value pairs, the same way the regular URL query string works.
Related
i have to create a new asp.net mvc page that integrates content provided by a cms on the server side static. my mvc page provides a masterpage with the navigation and certain links should point to pages of the cms (which is installed on the same server). it should be something like a "server side iframe".
my idea is to create a controller which loads the page of the cms using a webrequest, extracts the body part of the page and passes the extracted data to the view. the view simply outputs the passed html. i also plan to add some logic to pass post requests to the cms (for news letter subscriptions, contact forms, ...)
now my question is: is it possible to implement this solution? or is there a better way to do this on the server side?
Could you use Application Request Routing to just hand off requests to your CMS, or do you need to include the externally provided content within an existing masterpage?
If you need to use the masterpage I would stick to the solution you suggest, although I might investigate the most robust and efficient option for querying the content from the CMS and perhaps if caching would be a good option.
It is undoubtedly possible, but keeping track of users, authentication, cookies etc. seems like a really tedious job. Also, embedding css classes, hard-coded styling etc. from the CMS in your MVC site could give you a severe headache.
If the CMS isn't home-brewed it probably has an API. In that case I would much prefer to use the API to get at the data I needed and then render that data using pure MVC. This will give you a much cleaner and more stable integration with the CMS.
I am looking at the HDIV framework to implement it in my Grails application. Looks like the framework is more user friendly to Struts/java based applications. They do say it can be configured on other frameworks. This is what it exactly says:
It is possible to use HDIV in applications that don’t use Struts 1.x, Struts 2.x, Spring MVC or JSTL, but in this case it is necessary to modify the application (JSP pages).
I see that we need to modify the editable and non editable data being sent to the server (one of the strategies is to cypher code the hidden field and add a state parameter to link urls.)
And in the response we get back this data and use a validate() function to do integrity checks.
The sample grails-HDIV project on GITHUB is really basic with no details.
Has anyone implemented it on grails?
Thanks
Priyank
I've just written a plugin for this very thing. I'll see if my company will let me release it and if so I'll inform you.
Isotope lets you write templates in javascript. These templates can then be rendered by either the client (using plain-old javascript) or on the server (using Johnson).
The benefit is DRYer code. When updating the DOM on an ajax or web socket update, you can don't have to write a new partial...just point it to the one you already wrote.
Has anyone used this?
Interesting, I would have to try it, however , and I know not a lot of people do it, but I actually use HAML to template .js files. Although there is still that problem the author mentions , of each request being templated on the server and sending back html, unless you are sending loads of kb, or you have really, really high load site I don't think it's such a big deal.
Also ideally you shouldn't be even sending html data back and force, just JSON objects, which are rendered on the page by your ajax request. The only legitimate use I can see for this is if you have heavily ajax website, such as where you load a page once, and the you just keeping doing ajax requests for all interaction and javascript to manipulate view.
So it would help if you would clarify the final goal. Is this for some internal app where you control user environment ( you know for sure which browsers they will use, and that they will have fast enough computers to manipulate all this javascript?) Or is it going to be an app targeted towards 3rd world, where people don't have yet resources available to use all that fancy javascript.
All that said, it's an interesting concept, and I will try it our myself, to see how well it works.
This uses Johnson, which last I checked did not work on Ruby 1.9. So that might hint at some of the immaturity of this particular solution. Eventually the community will come up with something that works really well.
One approach I have used is to make 2 completely separate templates, but try to make them as similar as possible so that it is easy to port changes from one to the other.
This seems like a bad idea. In an Ajax application, I believe that the server should be responsible for rendering all display text. This makes i18n easier, and concentrates everything in one place. The JavaScript should simply receive data from the server, with all display text already rendered, and put it in the appropriate DOM object.
In other words, I believe that in an Ajax application, the need for a JS template engine is itself a design smell.
The situation is different in exclusively client-side JS applications, of course.
I'm working on my first Ruby on Rails aplication and it's quite big (at least for me ;) - database has about 25 tables). I'm still learning Ruby and Rails and I never wrote anything in Javascript nor Ajax.
Should I add Ajax to my application from the beginning? Or maybe it will be better to add it latter?
Or in the other words: is it (relatively) easy to add ajax to existing web application?
Jeremy Keith has written a great article on this topic, which he refers to as Hijax
In short:
Plan for Ajax from the start.
Implement Ajax at the end.
Depends on how important Ajax is for the application. Since you are probably going to use Ajax for progressive usability enhancements only, I would say it is best to start with a traditional non-Ajax software, and add Ajax features only when you have the first features working. You can do this feature by feature, or write the whole software first, and then start ajaxing it.
Adding Ajax may be easier if you familiarize yourself with unobtrusive JavaScript techniques. Use jQuery instead of Prototype.js, or LowPro in addition to Prototype.js. For the latter, see e.g. Jarkko Laine's PDF book Unobtrusive Prototype.js.
If you are planning to do AJAX, I would do it from the beginning. It will help you structure your controller actions and views, especially with respect to generating some data in partial views, correctly from the very beginning. Knowing that some actions need to be able to render just parts of the page will change your design. This isn't to say that you can't go back and retrofit the design, but I think it's easier to get the design right if you design with this in mind up-front. You should also consider how to make it work without AJAX (or javascript at all), too so that your design is as fail-safe as possible. That doesn't mean that all functionality has to be available, but that important functionality works in the absence of javascript. For example, action links that use AJAX should have a default url that will invoke the correct action via a GET request if the javascript isn't enabled. Forms that post via AJAX should also work if posted normally. Dynamic behavior (like an image gallery) should have a usable, alternative view that works, etc.
Now that RC1 is out I need to decide once and for all whether to use MS Ajax libraries or just jQuery for AJAX requests. The application is a new application. Essentially the way I'll decide is whether or not i get any significant benefit from the Microsoft libraries that I wouldn't get from jQuery. I already HAVE jQuery loading and I am concerned about the extra overhead of file size more than anything.
As far as I'm aware -- the only benefit really is that there are helpers like Ajax.BeginForm, but perhaps these will work with jQuery at some point anyway? I was also told today by a government employee friend of mine that MS Ajax library has a LOT of bugs in it - which concerns me.
With Microsoft now having officially befriended jQuery I wouldn't be too worried about them doing anything in future to leave jQuery in the dust by enhancing their own libraries.
I really don't know a whole lot about exactly what MS Ajax actually does for me. Are there certain pros and cons. Or is it just 90% bloat to support 'update panel' ?
I also find it very interesting that the ASP.NET MVC in Action book just skips over the MS Ajax libraries and jumps straight into jQuery :
In this chapter the reader will
examine how the ajax technique is
applied to ASP.NET MVC in a more
seamless way than with Web Forms. The
reader will see how to leverage an
increasingly popular, lightweight
javascript library called jQuery.
(from free sample chapter on AJAX)
Would very much appreciate hearing from anyone about their experiences workin with both, expecially on the following additional questions :
is it easy to convert code between the two libraries - assuming relatively simple ajax requirements ?
is debugging notably better or faster in either library
anybody know how ASP.NET 4.0 is progressing and any announced plans for the AJAX library that might be beneficial to MVC?
what in a nutshell could MS AJAX do for an MVC app beyond sending requests and sticking the response in a DIV?
how do i do the equivalent of Ajax.BeginForm(...) and use jQuery ?
what was your deal killer one way or the other?
what are most people out there using?
Personally, I would stick with JQuery. MS AJAX is pretty heavyweight in terms of size and you can do so much with JQuery. As far as whether it is easy to convert code, well it depends on how much of the MS AJAX stuff you are using. I don't think there is really much appreciable difference in debugging from one to the other. You will have a larger community of JQuery users from which to pull resources.
You can (and I do) use both depending on the need. When I want a particular form to be non-javascript friendly AND I'm generating content on the server, I'll use MS AJAX via the AjaxHelper. It builds everything I need on the client side to handle the non-javascript enabled browser. I only need to detect AJAX/non-AJAX in the controller and return a partial or a full view depending. If I need to use AJAX as part of a plugin (say autocomplete), then I'll use jQuery. The point is I use the tool that best suited (easiest to implement) for me. Granted, most of my apps run on an intranet so I'm much less concerned about the size of the downloads.
I also found the jQuery announcement about MS incorporating the library
Apparently :
Additionally Microsoft will be
developing additional controls, or
widgets, to run on top of jQuery that
will be easily deployable within your
.NET applications. jQuery helpers will
also be included in the server-side
portion of .NET development (in
addition to the existing helpers)
providing complementary functions to
existing ASP.NET AJAX capabilities.
So I'm thinking its quite probable that they'll end up having jQuery helpers that exactly mirror the AJAX helpers for the MS stuff.
I guess solution I'll take is to use Html.BeginForm, and then intercept the submit button to use jQuery. I'm not especially worried about people without javascript losing functionality, but its not that much harder to do so I may as well.
JQuery is much easier to code than Ajax allot of the problems with overhead can be remedied by adding more memory rather than by stream lining code. Ajax just does not make any sense to me although I'm just a beginner at it. After dealing with the overly criptic Ajax syntax, jQuery is like a breath of freash air.
Well there is one thing that I found with MS Ajax framework that cannot be done elegantly with jQuery. User controls build MS Ajax are very object oriented. This cannot be easily done with jQuery. For example, lets assume you are building a "address" user control, that will have address1, address2, city, state, zipcode and country. You can build this control with jQuery and Ajax but the benefit that's provided by Ajax library is that it will compartmentalize the address control. You can define a function "reset()" on that control that would reset the contents of address control. Lets say that you want "reset()" to set address1, address2, City to Empty string but State to "AL" and Country to USA. You define the code for Ajax control in (.js) file and that function will be associated with your address control. Same is not possible with jQuery. Any function you define will be global in scope and there is no easy way to tie that function Address control. You can very well call the "reset" function on textbox control on the form!!!
So if you want to create a pure object oriented user controls then i guess better choice is using MS Ajax framework.