In grails if you rerender a template back on top of itself to update information on a GSP does the old template's DOM get updated or does the new template cause DOM issues by having its own DOM? And also, is it considered good practice to rerender a template on top of itself to update information? I just used this approach for the first time and hence I was wondering if it is considered good practice.
Doing a partial page updates using AJAX is very common with many modern web based UIs or websites. This has little to do with Grails and it's easier to think about what's going on if you think of what is being sent back to the browser as just HTML and ignore the fact it's coming from a Grails template.
That said, your question of "... does the old template's DOM get updated or does the new template cause DOM issues by having its own DOM?" is slightly awkward because templates or HTML fragments don't have a DOM but the entire page as whole within the browser does.
What is happening is the page is rendering, being loaded by the browser and parsed into a DOM, then displayed. When you do a partial page update the browser parses the new fragment into DOM elements and replaces/updates portions of the existing DOM with the new elements.
All in all, this is considered a good practice since it allows you the developer to only update what information needs to be changed within the DOM and not refresh the entire DOM by reloading the entire page.
I hope this helps, if not please comment and I will explain further with theoretical examples if needed.
Related
wondering how to use BoilerplateJS with Jquery Mobile. Perticulary when it comes to manage url and how to deal with the which is created automatically.
Thanks.
I haven't seen any examples out there so have been doing exactly that myself but haven't yet completed the exercise. You need to add the jQuery Mobile references into the top level index.html and then modify the html (structure, tags) to something that JQM will like to render. You also need to ensure the views correctly trigger enhancement of content changes. It seems straight forward enough although styling might yet be a gotcha so I can't yet say whether it's trivial-but-time-consuming or going to be a mess.
I'm doing an app with jQuery Mobile and Angular.js. Cause we have some issues using both libs, exists an adapter that do "teh job".
So I'm trying using routeProvider to route my pages. But I still can't render pages using this.
Here plunker if u can help show me the way.
http://plnkr.co/edit/DNGiT83csWMmfYnHXOop
Thanks in advance!
I ran into a similar problem and maybe what I learned might help you. It comes down to the differences in the way angular and jquery go from one page/section to another (routing).
First, the basics: angular routes by inserting a chunk of html into your view, then on whatever click/action/etc, removing that html from the view and adding a new chunk of html. Essentially you're on the same page all the time; it's just the included html is changing. In contrast, think of jqm as loading up all the html into the same page, with those html chunks as divs. Instead of removing html chunks and replacing them (via routing), it's just turning divs off and on. (There are multi-page jqm apps but SPAs really highlight the differences.)
My suggestion is to pick which set of features you really want: angular's minimalistic loading (only as you need it), or jqm's flashy transitions and other built-in features. If you've got a massive app with a lot of data on every page, you might want to bypass jqm and use angular alone, and see what you can do with angular's new animate functions. It'll mean you'll need to build (via CSS or javascript) duplicates of the jqm features -- and from what I've seen, you can get close but it won't quite be as pleasantly streamlined as jqm.
If the jqm built-in features are what you really want, then skip using angular's routing. It'll just introduce all kinds of complications, anyway. Set up your pages using jqm's pattern, and use angular only where you're dealing with data.
What I've found works best is to treat it like it's a jqm app overall, and only add angular into the sections where you need it. After all, you don't have to add ng-app at the html line; you can add it into a single div as needed. Since jqm is happiest as a system-wide kind of thing, while angular is just fine being confined to pieces within a system, so far I've found jqm-whole and angular-parts to be the simplest way to get the best of both worlds.
I'm using the datatables plugin in a Jquery Mobile project.
I'm using a multipage layout, with several pages containing tables enhanced by the datatables plugin. Since I already have a lot of overhead using Jquery-Mobile, running datatables alongside seems to push my mobile browser's limit.
So my questions:
- Does it make sense to only initialize a datatables table when the Jquery Mobile page is being pulled into view?
- Should I destroy a datatables table when I'm leaving the page for another page and re-initialize when the user goes back to the page?
I guess the question is sort of a longshot, but maybe someone can share some insights or opinion on it nevertheless.
Thanks!
I've used dataTables a lot and i had problems only when the row count got too big. In any cas to your questions
Does it make sense to only initialize a datatables table when the Jquery Mobile page is being pulled into view?
Yes this makes sense to me, no need to waste processing power and memory if the table is not shown
Should I destroy a datatables table when I'm leaving the page for another page and re-initialize when the user goes back to the page?
This is a little more difficult to decide since you have to consider the effort that you put into creating the table. That's a though decision and only testing out both options will lead you to the right decision
Yes, it makes sense to initialize them as the page is pulled into view (maybe the pageload event?) In Chrome, I profiled ~30ms hit when binding data tables to a 3-row table. That will really add up if you have large tables or many of them.
This seems a bit arbitrary. Once the hit has already been taken to create/bind the datatables, I'm not sure that destroying it will clean up anything as no datatable functionality/events will be called once the page is removed from view. In fact you will put an additional (and largely unnecessary) hit on the browser unbinding them.
We have a fairly complex application that was previously using WebForms. We are in the process of rewriting bits of it from scratch using MVC. Our application is comprised of a number of widgets, that together make up the functionality of the application.
In WebForms, we used UserControls. Each UserControl would register its CSS and JavaScript by means of a collection that was stored in HttpContext.Current.Items. That collection would then be merged to output as one single request. Typically this would occur in the Page_Load event, and the containing page would then render out a script tag that would comprise all the JavaScript and CSS needed for that page.
We've been struggling with doing the same in MVC. We are using a number of views within a masterpage to mimic the widgets. Each widget has its own controller, so the functionality can be sufficiently segregated. The masterpage builds up the widgets on the page using RenderAction from MVC futures. Originally we were using the same registration method for the CSS/JS files. Each controller would register its required files in an Action. The files would then be contained in the HttpContext.Current.Items collection, and would be rendered out to the page. To facilitate this, I wrote an HtmlHelper extension to render the links/scripts out to the page. It looks like this:
<%= Html.GetRegisteredCssFiles() %>
The problem is that MVC uses a more top down approach. This call is made in the tag of the page, but our subsequent calls to RenderAction happen below. By the time RenderAction is called and the required files are registered in HttpContext.Current.Items, the code above has already executed. So, the collection is not modified at the right time.
Does anyone have any ideas on how we should be constructing this? I'm looking for answers that incorporate best practices for MVC.
This question was asked a lot of time ago, so probably you've dealt with this already. But for future visitors, maybe this solution will be helpful:
http://marcinbudny.blogspot.com/2010/01/handling-stylesheet-references-in.html
The Free Telerik MVC tools have a script and a style register that might do what you want ...
Not sure if this is a feasible solution for you, but try moving that call to the bottom of each page.
I've always included my javascript and css files in the html HEAD, so I don't know if it would work lower down. My assumption is that it'll work in most browsers, but you might have random problems in a few.
The alternative is to have GetRegisteredFiles() output some javascript that loads the CSS files in the proper place (via DOM manipulation).
The problem with either of these solutions is that the files aren't included until the end, which could cause the page to look "plain" until the CSS is downloaded.
Alternatively, the controller could predict which "widgets" will get loaded and pass that data to the master page.
What is the 'page lifecycle' of an ASP.NET MVC page, compared to ASP.NET WebForms?
I'm tryin to better understand this 'simple' question in order to determine whether or not existing pages I have in a (very) simple site can be easily converted from ASP.NET WebForms.
Either a 'conversion' of the process below, or an alternative lifecycle would be what I'm looking for.
What I'm currently doing:
(yes i know that anyone capable of answering my question already knows all this -- i'm just tryin to get a comparison of the 'lifecycle' so i thought i'd start by filling in what we already all know)
Rendering the page:
I have a master page which contains my basic template
I have content pages that give me named regions from the master page into which I put content.
In an event handler for each content page I load data from the database (mostly read-only).
I bind this data to ASP.NET controls representing grids, dropdowns or repeaters. This data all 'lives' inside the HTML generated. Some of it gets into ViewState (but I wont go into that too much!)
I set properties or bind data to certain items like Image or TextBox controls on the page.
The page gets sent to the client rendered as non-reusable HTML.
I try to avoid using ViewState other than what the page needs as a minimum.
Client side (not using ASP.NET AJAX):
I may use JQuery and some nasty tricks to find controls on the page and perform operations on them.
If the user selects from a dropdown -- a postback is generated which triggers a C# event in my codebehind. This event may go to the database, but whatever it does a completely newly generated HTML page ends up getting sent back to the client.
I may use Page.Session to store key value pairs I need to reuse later
So with MVC how does this 'lifecycle' change?
I'll attempt to comment on each of the bullet points you mentioned:
Your master pages still exist in MVC and are used to provide a consistent layout to the site. not much new there.
Your content pages will become views in the MVC world. They still provide the same content areas to your master pages.
The eventhandling of webforms should not be used in MVC, instead your Controller classes and their action methods will handle loading your data into a "model" that gets passed to the view.
Although webform style databinding is possible in MVC, I find that it is not the optimal solution. Better to place your data in a model class and strongly type your view so that you have direct access to that model. Then its simply a matter of using the <%= ViewData.Model.SomeProperty %> syntax to access your data and display it in the desired locations. As for viewstate, my recommendation is to forget that it even exists.
Remember that one of the advantages of using MVC is that you have control over the HTML you send to the client. Embrace that power and try to find solutions that allow you to maintain that control. Webform controls attempt to hide the the html from you and as such make it more difficult to customize the html when you need to.
I would highly recommend JQuery or one of the other similarly powerful javascript libraries. But learn to use them to access the HTML DOM directly and avoid the id mangling issues of webform controls.
You can use jquery to hook into the dropdown selection on the client side and submit standard or ajax style requests. Those request can return new pages, redirects, html fragments or even JSON data that can be used to update the existing page.
The asp.net Session can be used as needed.