I'm very new to the world of jQuery and might be asking a fairly trivial question here. I'm curious as to what the community views as the best practice for a databound object with jQuery functionality.
As a specific example, I've currently created a repeater bound to a list of objects. Each object has properties such as "link", "thumbnail", "subtext", etc. This is a small repeater(<10 items at any time). When a user clicks on "link", a separate area of the page updates to reflect that object.
The approaches I've discovered so far involve:
Dynamically creating the necessary jQuery script from the C# codebehind
Creating a JSON service to respond to the link request and return the object to be loaded(an extra possibly unnecessary database hit)
To dynamically create a JS Struct within the C# codebehind (similar struct)
I guess the main reason I have for avoiding a JSON service in this scenario, is that the objects have already been bound once after being returned from the datasource. I'm not sure if another db hit is warranted, but I'm open to any and all suggestions.
Dynamically creating the necessary jQuery script from the C# codebehind might be unecessary as the JQuery code won't have to change. Bear in mind that unobtrusive JS is what jQuery is largely about.
I imagine the single piece of JS would look something like this:
$('.link-class', '#repeater-id').click(function(){
// Get the id of the link or the target using $(this).attr('id')
// Show a page section or call a service using the the discovered ID.
});
You can use the first comment to pull out the data you need to identify the data you wish to display.
The second comment can be either an Ajax call or a div toggle to some other section on your page. If this data is large then I'd be inclined to Ajax it. Otherwise I would keep it on the page and just toggle it on or off.
If you think users would be more inclined to click on several of the links then I would weight the non-ajax option a little more favourably even if the page was a little heavier. Especially if the user might return to a previously clicked link.
Does that make sense? Happy to elaborate further...
I assume this list has some basic details about some items and when you click on one you see some more data about that particular item.
I would definitely pick choices one (dynamic jQuery) or two (JSON service) depending on the size difference of the rendered page. If we're talking a difference in the vicinity of 10kb I would go with dynamic jQuery and just have all the data ready to go. If it's significantly more than that use a JSON service.
There's nothing wrong with an extra DB request and the delays it implies when the user expects it. If someone clicks on a web page item they're going to be fine with any delay less than half a second and perhaps a little over a second if you're nice enough to just say "please wait" to signal that a noticeable delay is normal.
Related
I'm building a website in jquery mobile. It is a SOA application and on 'pageshow' event I call the web services get the data and populate labels and dropdown lists with it. However, say for instance, when a user clicks back and the app takes him back to dashboard, the ajax call is made again and the labels are unnecessarily populated again. What I want to ask is, can I prevent this behaviour of populating the same labels with the same data over and over again? Does jquery mobile have this 'viewstate' behavior built in?
Thank you for taking the time to answer my question.
You could use HTML5's localStorage / sessionStorage API to actually persist data between callbacks.
Personally I think that if you'd use JQM's page idiom (having only data-role=page and not loading any new ajax pages), you wouldn't have this problem at all (but rather the opposite, how to reset all fields).
We have an application where we have a single level navigation menu with some heavy-duty pages on each link. The user can switch back and forth between these pages frequently to obtain information that he needs.
Once the page gets generated, it wouldn't change for the session. However, the page is specific to the user, hence we cant cache it.
I was trying to come up with a solution where we generate the page once, and keep it hidden in the background until its link is clicked, but haven't been able to get my head around this.
One of the ways I thought was to have multiple div tags (one for each page) on one page and keep toggling the visibility as the links are pressed, but that would end up making this single page very heavy. Someone also suggested using iFrames, but I am not really comfortable using the iFrames much and I'm not even sure, if it would be any helpful either.
Can you guys please suggest a few approaches to tackle the issue?
update: Just to clarify, we are fine with keeping the pages separate and navigate across using a standard menu bar. We were just looking for ways to optimize the performance as we know that the pages once generated wouldn't change and there should be some way to tap that benefit.
You can use Ajax tab control for this purpose
Try taking a look at this MSDN article which specifically tackles the issue of how to user-level cache. Also, it might be more manageable to break each tab into a user control. That way your ASP.NET page has just the tab control and 1 user control for each section under the tab. It makes managing tabs much easier.
EDIT:
What I would do in your case, since you say the data won't change for the user, is I would grab the static data from the database and then I would store that data in the Session cache. THe session cache is specific per user and you can try to retrieve the static data from there instead of repetitively calling the database.
Check out the ASP Multiview control. Just remember that even though the different views are hidden when not active, their viewstate is still being sent back and forth. Can be a benefit if you need to check control values across views though.
I'm writing an app in which user can register. While registering the one may choose several options and according to these regiester fields are visible or not and are required or not.
I came up with an idea that all fields will be in in the updatePanel and when users changes registration options I would set visibility of these fields on the server side.
It works but incredibly slow and whats more on the FF I have the given error:
The state information is invalid for
this page and might be corrupted
3 checkboxes with other fields are in the updatePanel
Each field is in dl tag with runat="server>
I had to do it like that cause for "required" option I simply add css class to this dl (need in in javascript validation. If field should be visible I set visible="false" for given dl and then that field for example FirstName with title and so on isn visible after postback.
Am I doing something wrong ? Why does it take so long (~4 min on localhost) and in firefox it doesnt really work (when I use debug I think that process completes without errors on ff, I dont understand that at all :)
If update Panel is so weak what would be other option to change visibility and adding required class to all dls. Logic is quite complicated and has to make query to DB so simple javascript would be quite tricky.
Thanks for any hints,
Oh and I'm using ASP.Net and cant upgrade on this project.
Thanks for help,
bye
Without code to look at, here are general things which will make an UpdatePanel slow:
Large amount of form data (such as Viewstate) being posted. Uploaded data is often slower than downloading data (depending on connection type, such as a home connection where uploads can be 5x slower than downloads). Even though you can't see it, every form field on the page is posted back to the server (even if its not in the UpdatePanel).
I would suggest going through your request/response data in Firebug and making sure that your async requests are less than 5K and your responses are no more than 20K.
A slow process on the server which is running when the UpdatePanel is posted. How does your code perform when the UpdatePanel is removed?
JavaScript errors (yours and Microsoft's). Here is a link to a known bug and a fix that I have used myself: http://support.microsoft.com/?kbid=2000262
Massive DOM manipulation (doesn't sound like this is the case for you).
BTW, searching for the error message you reported gives many possible causes:
http://www.google.com/search?aq=f&sourceid=chrome&ie=UTF-8&q=The+state+information+is+invalid+for+this+page+and+might+be+corrupted
As always, minimize or remove dependencies on ViewState...it's the source of many problems and enables poor design decisions.
You need to set update Panel properties update mode to Conditional instead of Always. Limit the number of controls you put into one update panel
You might want to check, Page events etc. Research on page directive and property AutoEventWireup
Since performance is the issue you highlighted, you might want to check that as well. Update panel mode should be conditional.
Check the triggers as well
Try with these properties values inPage directive. This is always at the top of your page. Let other properties be there as they were before. Update panels should not be slow like you are reporting.
<%# Page ViewStateEncryptionMode="Never" EnableViewStateMac="false"
EnableEventValidation="false" %>
I would also like to add that if your database query that you mentioned is complex, is taking a very long time, then the problem lies not with aspx page or update panel, but with your database query. You will then need to profile your query and check how much time it's taking to execute. The way to go in that case would be to fine tune your query at database level.
I am struggling with finding clear answers to dynamically creating the same page over and over. The questions and samples I have found seem to be all over the board on this topic. I have studied the life cycle and still seem to not have a clear answer as to where code should go.
I have a master page and a content page. All the content in the content area needs to be dynamically created (text boxes, ddl's, page tabs, buttons/onclick etc.).
After a user fills in data and clicks a submit button, I need to read the values off the form and rebuild the page completely again (not add/remove controls to current content).
My question is then.
Where do I put my code to build the page?
Will this area allow me to use IsPostBack so I can rebuild content with Request.Form values?
Will my buttons _Click events work?
Are there any working samples out there you could direct me to?
Thank you very much for the feedback...
I don't know all the answers to your questions, but I hope this may get you started. When dynamically generating the UI through code, this happens in Init. Controls dynamically loaded on Init is key because between init and load, on postback, viewstate is loaded for these controls.
This means you need, on every postback, recreate the page as is to match the previous control tree, then deconstruct it after init and recreate the new UI, if something is supposed to change UI wise. This is because it validates the tree structure to determine its the same UI. Now, if you don't need viewstate, this may not be as much of an issue. I haven't verified this without viewstate to see if it behaves different.
It depends how dynamic you need it, whether you need viewstate (is a big factor).
HTH.
Try creating the controls in the page's PreInit method. "IsPostBack" should work and the click event handlers should work as well.
What you need is a web user control, see ASP.NET User Controls
Brian's advices are good and you should follow them.
This might not really answer your question but still I add it as an advice. I'm professionally creating ASP.net web applications at quite a large scale and from my experience I can say that too much "dynamics" is usually bad and should be avoided because it just introduces complexity. Normally you might want to expose UI parts into ASP.net UserControls or if you want to make them even more reusable (if that's a factor) then into ASP.net Server controls. Then you replace different of them dynamically rather than creating everything from scratch.
Is there any pattern or kind of "least requirements list" to follow for ensuring an asp.NET application to support BACK button of the browser for each aspx page?
thanks
In general, the back button on the browser will take you to the previous HTML GET or POST that occurred. It navigates by page-wide transactions, so anything done dynamically cannot be navigated that way. Also, the back button doesn't rewind code execution, so if you are determining something based off of a Session variable or something similar, that won't be rewound either. Obviously, it won't rewind database transactions either.
In general, if you want to support the back button, you'll need to make sure to divide everything you need to navigate between with said button is divided by an HTML transaction of some sort.
Again, you're going to run into issues if your page display is dependent on server-side control that changes from one post to the next. This is one reason you see some forms feed a 'Page has expired' error when you try to navigate back to them.
Not really... It depends on your application flow.
There are things that make supporting the back button more awkward.
for example using pure ajax to change the majority of the content on the page,
will look like a 'new' page but wont be compatible with the back button (though you can fudge it)
another example is posting back to the same page more than once, as this can make it appear like the back button is not working, and at the same time re-doing your request (and therefore database transactions)
Fundamentally it depends on your application requirements.