I've always wanted to know what is, in a general way, the opinions about popups in web (I mean, those who are implemented via divs).
I've always liked not to load the user with the entire size of this popup in his navegation (when the popup is not visible). I assume that it's better load the content by demand (when the user clicks in the corresponding button). If you have five popups in one page, I always thought that the increase in 'bytes' can make a difference downloading the page.
Following the 'on demand' option I've always liked iframes because they let me change his URL via Javascript. So, I display a popup (div) which contains an iframe in wich I can change his contents downloading the page in this moment.
In my probably limited view, this method has another advantage. The validation logic (usually Asp.NET validators) are isolated in the popup page, so they don't enter in any kind of conflict with the validators located in the parent page (if applicable).
But it seems that iframes are not so well supported by some browsers and they are not too much appreciated by the community of designers (and it's a object with strong security implications).
So Basically I was wondering what are your experiences displaying these kind of UI. I know Jquery can load dynamically HTML in one div, but probably without isolating client validation scripting.
Opinions? THANKS a lot!
Firstly, you can create validation groups (http://msdn.microsoft.com/en-us/library/ms227424.aspx). That will help you with your validation problems.
You're right, you can use jQuery to dynamically load HTML as appropriate, but I'm not sure how well that works with aspx pages. There are problem a number of gotchas. Consider, you have page1.aspx and popup.aspx. If you load popup.aspx in an iFrame, you're fine, because it's a separate page. If you load it dynamically via JQuery.load() - the output of popup.aspx will load into your page1.aspx (this includes html tags, form tags, viewstate fields etc). That will likely cause some problems. (I haven't tried just guessing).
I have used .load in the past, but I tend to load standard html pages, not aspx pages. Then when the "submit" button is pressed, it calls a webservice with the relevent fields. This adds more javascript coding on my part - coding the "submit" button, coding a webservice to handle the ajax submit, coding the "wait screen" while an action is being done or data being submitted via ajax. I also have write the js to do client side validation and any code to handle server side validation and report that back to the user.
jQuery Validation plugins work well for this - or alternatively, you can instantiate .net validators if you don't want more plugins / frameworks (http://msdn.microsoft.com/en-us/library/yb52a4x0.aspx)
Related
Is there a straightforward way to use server-side validation with ASP.NET's validation controls in a form that's displayed in a modal dialog? I am using jQuery and SimpleModal (in C#, VS2010, .NET 4.0)
I've got a modal form which works fine. I need to use a server-side validation because the logic depends on data specific to the record being accessed
My solution for the project I'm working on now is to use a jQuery ajax call to pass all the form data to the server and get back the validation results before allowing the post to proceed. But this is relatively time consuming to implement, and in some situations I'm dealing with now all the validation code exists already.
The first challenge is that of course the modal dialog will close on a full postback. So you could put an UpdatePanel inside the dialog... without even thinking about this too much, though, I assumed that it wouldn't work out that well. It doesn't. And the form which opens the modal dialog to begin with is already in an UpdatePanel, which further confuses matters.
Anyway, I tried putting the contents of the modal form in an UpdatePanel for the heck of it. It does actually do a partial postback, the dialog remains open, but the contents of the dialog do not get updated with anything I change server side. If I close and re-open the dialog on the same page after testing the validation code, though, its contents are in fact updated to reflect these changes. Obviously the way the dialog is rendered is confusing ASP.NET. Or vice-versa. But this just seems sketchy from the get-go.
Rather than trying to hack my way through this problem I was hoping that others had some suggestions about a better way to approach this. Or just tell me I'm trying to hard too mix apples and oranges and I should keep it all client side (or client side + jQuery ajax) if that is the only sensible thing to do.
The two approaches I've taken:
1) submit the data via ajax, the response includes a success:true or false. If false, there is a message included that details the issue.
2) submit the form normally. If there is a validation problem, but the errors in a hidden div on the page and write JS to check for content in that div when the page loads and display the warning/error as necessary.
I have been given a requirement to take an existing stand-alone web-form (i.e. uses postbacks) and throw it into a lightbox.
The standalone web-form already has save and cancel buttons that have predefined behaviors. For example, the Save button attempts to save the form, and either displays validation errors, or if the operation was successful, redirects to some other page in the app.
However, in the context of this new "lightbox mode", the Save button should additionally close the lightbox if the operation was successful.
I see two options:
Option 1-->UpdatePanel + ModalDialogExtender:
a. Extract a UserControl out of the standalone web-form that includes everything but save/cancel buttons
b. Introduce Save and Cancel EventHandlers on said UserControl
c. Use this UserControl on both the standalone and lightbox versions of the page, and wire up the events appropriately
Option 2-->Client side lightbox (i.e. jQuery)
a. ....
I'm a big fan of jQuery and tend to favor its use for Ajax functionality b/c of the level of control it gives me. On the other had, I also want the simplest solution that will possibly work. Assuming that option 2 is that option, any guidance on how to proceed would be appreciated.
I am using fancybox (see http://fancybox.net/home) with great success. It has a mode where it can show my aspx page (usually an edit form without menus and so on) in an iframe fancybox.
It can also be closed from javascript in the iframe.
I am a little confused and making it alot more complicated than this needs to be! Here is what I have...
A view which displays a drop down of US States. When the user chooses a state it loads a list of data from a database and returns the results (populates the View Model) and the View renders the information.
What I wanted to do was have have the dropdown trigger an Ajax event which performs the data load, but also wanted it to depreciate if the user didn't have Javascript enabled. How would I go about rendering the view with AND without javascript / ajax?
Hope that makes sense. Thanks for your help.
You can't re-populate a drop-down without jscript. You can do a page-reload with a new drop-down though, although the logic to determine which to use is javascript unfortunately. (Not to mention triggering the re-load of the page on click)
No Javascript support though? That seems kind of out of date, most people run javascript-enabled browsers these days. As for paranoia freaks with javascript turned off, a <noscript> block to tell them to get over it may be appropriate.
To do this with ajax, read this article about cascade dropdowns by Stephen Walther.
To do this without ajax, you could put your first dropdown in a form with a button visible only when javascript is disabled (hide this with javascript for that) wich gets to some action (in another window, maybe) wich returns the second dropdown populated according to the element selected on the first (on the first window, if you have 2 - you could know this url using a viewstate variable).
For example,
If I have a textbox with runat=server on a page, The value will be posted back to the server so I can access the properties in the code-behind.
However, under the following situations, does it still hold true?
A textbox with runat=server but does not appear in the function that is post back to. For example, a button is also on the page, when clicked a post back occurs and within the method that is raised, this textbox was not used.
Within a MasterPage, will a textbox residing on the Masterpage itself be posted back?
Because just thinking, isn't this mechanism bloated in nature?
If all input controls and its value are posted back on every single button click (even when the input control is not needed), doesn't this deteriorate performance?
Having just one Form Tag on the page really restricts us to using this mechanism?
Truly Understanding ViewState is a must read article on the subject of ASP.NET ViewState
There are several options to cut down on the bloat (and yes, there's a lot of it when dealing with lots of controls):
Use AJAX to post only the items required - although be careful to allow clients that don't have JavaScript enabled to still use the page/ site.
The MVC framework allows multiple form tags to be used so you can group sections if needs be.
Set the EnableViewState to false on pages/ controls.
Break up your pages into smaller ones.
Additionally, check out this brilliant graphical representation of the Page Life Cycle in ASP.NET.
Every input on the page is posted back fully unless you use ajax, because of the single form tag. Welcome to asp.net...
As long as the method that you're hitting on the server-side is a non-static member of the page's class, it'll have access to the textbox and all other controls on the page.
And yes, all controls rendered to the browser (whether in the MasterPage, user control, etc.) will be available on post-back.
You may want to look into Understanding ASP.NET View State.
There surely are performance hits with this architecture, but (depending on complexity of the page) it's usually not an issue from the server load perspective, because hardware upgrades are typically cheaper than additional programming hours spend on optimizing application performance.
With that said, (and as others have pointed out) look into using AJAX if you want to avoid whole page-level postbacks to the server.
Yes, it's all posted back, and yes it can cause bloat. I'm sure if you search for ViewState you will find plenty of people ranting about it and how to minimise it :)
Yes your text box will be available in both cases, yes it is bloated. This is where AJAX comes into play. Using AJAX you can send just the data you need.
If you want to send a minimal ammount of data, you could use a Page Method (static method on page decorated so the script manager builds javascript to call it or you could call it using jquery or other methods), or a script enabled web service works nice as well.
You also have viewstate which can get very large. ASP.Net MVC is a new paradigm instead of using WebForms which doesn't have view state, or post backs. It embraces HTTP instead of hidding it giving developers more control.
The textbox data would be posted back as noted. In addition to using Ajax, disabling view state greatly imporoves your page's performance though even then data in properties critical to the functioning of controls (Control state) would still be posted back.
If you didn't have postback for every control on the form, you wouldn't be able to access it in code-behind. I.e. if in your button press you wanted to modify the property of the text control you couldn't do that because ASP.Net would know nothing about the text control.
Since the communication between the server and the client is stateless and every time a page is server the server forgets all about it Postbacks are important if you want to work with the same page again. No matter what programming language you use, this or similar mechanism exists for processing server side code.
If you wish to minimize postback (viewstate size), do this.
Set enableviewstate=false on all controls that you don't want posted back.
Use AJAX and web services wherever possible (and don't use UpdatePanel).
Use HTML control as much as possible instead of ASP.Net controls.
Hmm.. There are some excellent suggestion in other answers and good links too.
You've pretty much hit the nail on the head with vanilla ASP.NET - it's not very good! In both the instances you describe the answer is yes - the textbox will be sent with the form.
The whole postback/ViewState problem is a bit of a pain, one of the first things any competent ASP.NET developer learns to do is avoid them!
What choices do I have for creating stateful dynamic content in an ASP.Net web site?
Here's my scenario. I have a site that has multiple, nested content regions. The top level are actions tied to a functional area Catalog, Subscriptions, Settings.
When you click on the functional action, I want to dynamically add content specific to that action. For example, when Catalog is clicked, I want to display a tree with the catalog folders & files, and a region to the right for details.
When a user clicks on the tree, I want a context sensitive details to load in the details region (like properties or options to manage the files).
I started with UserControls. They worked fine as long as I kept loading everything into the page, and never let one disappear. As soon as one disappeared, ViewState for the page blew up because the view state tree was invalid.
(I didn't want to keep loading stuff into my page because I don't want the responses to be too huge)
So, my next approach was to replace my dynamic regions with IFrames. Then instead of instantiating a UserControl, I would just change the source on my IFrame. Since the contents of the IFrames were independent pages I didn't run into any ViewState problems.
But, I'm concerned that IFrames might be a bad design choice, but don't fully understand why. The site is not public, so search engines aren't a concern.
So, finally to my question.
What are my options for this scenario? If I choose an Ajax Solution (jQuery), will I have to maintain my own ViewState? Are there any other considerations I should take into account?
Controls that are added dynamically do not persist in viewstate, and this is the reason that it doesn't matter if you use AJAX or iframes or whatever.
One possible work-around is to re-populate controls on postback. The problem with this, is the page life-cycle (simplified) is:
Initialize
LoadViewState
Load Postback Data
Call control Load events
Call Load event
Call control events
Control PreRender
PreRender
SaveViewState
Unload
What this means is the only place to re-add your dynamic controls is Initialize -- otherwise posted data (or viewstate information) is not loaded into that control. But often, because Viewstat/postback data isn't available yet in Initialize, your code doesn't have the information it needs to figure out which controls need to be added.
The only other work-around I've found in this situation is to use a 3rd party control called DynamicControlsPlaceholder. This works quite well, and persists the control information in viewstate.
In your particular case, it doesn't seem like there are that many choices/cases. Is it practical just to have all the different sets of controls in the page, and put them inside of asp:placeholder controls, and then just set one to visible, depending on what is selected?
Some other options:
Content only appears to be dynamic. You load enough controls on the page to handle anything and only actually show what you need. This saves a lot of hassle messing with view state and such, but means your page has a bigger footprint.
Add controls to the page dynamically. You've already been playing with this, so you've seen some of the issues here. Just remember that the place to create your dynamic controls for postbacks is in the Page_Init() event, and that if you want them to be stateful, you need to keep that state somewhere. I recommend a database.
you've got a number of different options, and yes, IFrames were a bad design choice.
The first option is the AJAX solution. And with that there's not really a viewstate scenario, it's just you're passing data back and forth with the webserver, building the UI on the fly as needed.
The next option is to dynamically add the controls you need for a given post, everytime. The way this would work, is that at the start of the page life cycle, you'd need to rebuild the page exactly as it was sent out the last time, and then dump out all the unneeded controls, and build just those that want.
A third option would be to use Master pages. Your top level content could be on the Master page itself, and have links to various pages within the website.
I'm sure given enough time, I could come up with more, but these 3 appeared just from reading your problem.
dynamic controls and viewstate don't mix well, as noted above - but that is a Good Thing, because even if they did the viewstate for a complex dynamic page would get so bloated that performance would diminish to nil
use Ajax [I like AJAX PRO because it is very simple to use] and manage the page state yourself [in session, database tables, or whatever works for your scenario]. This will be a bit more complicated to get going, but the results will be efficient and responsive: each page can update only what needs to change, and you won't be blowing a giant viewstate string back and forth all the time