I'm looking for a calendar control (AKA date-picker) that works on mobile devices. The problem is most devices are without JavaScript, or with poor JavaScript support.
ASP.NET's built-in control uses JavaScript to do post-backs. ASP.NET has a mobile calendar control, but it isn't fully localizable (on low-end devices where it displays a step-by-step date picker, its buttons are always in English).
I am thinking of overriding the built-in calendar control to replace the JavaScript post-back directly with parameterized links.
My compound question is -
Is there a good JavaScript-less calendar control, of a way to get rid of JavaScript in ASP.NET's built-in control, or of a way to localize ASP.NET's mobile calendar control?
If all of the above doesn't exist, is replacing the post-back with parameterized links a good way to go? What would other suggestions be?
Currently, I'm not concerned with formatting - the device I'm targeting displays the date-picker well. I'm concerned only with the small problem of getting it to work...
What I ended up doing is building a custom calendar control.
For now, I used a table, but it will have to change when I want to support more devices. Since I'm targeting right-to-left languages, a table is already a pain.
#troelskn - I didn't go for <select> because they're not comfortable for a user using a mobile device, but thank you for the advice.
You can generate some dropdown (<select>) boxes and use them as a simple datepicker. You'll need to do some server side validation though, since no JavaScript would mean that the user could pick an invalid date (for example, 31st of Feb).
Related
I have an existing ASP.net 4.5 webforms application that I want to make into a "WebApp"-like application for mobile browsers.
What I'm mainly interested in is the graphics / sizing / scaling aspect, since the WebForms site works well with mobile browsers already, but it looks ugly and not "mobile" at all.
Reading around, I came across jQuery mobile, which at a glance seems perfect: just including it in my website turns every element of the page "mobile friendly" (fixed page size, big buttons and elements, auto stretching, etc.).
But my initial enthusiasm was short lived: as soon as I tried to use the website, I noticed that while the graphics were perfect, including JQ mobile broke almost all the logic, for example:
DropDownLists stopped generating postbacks
Clicking on LinkButtons stopped working (nothing happens on click)
UpdatePanels broke completely (the ajax calls don't fire anymore)
MultiViews broke completely (they get reset to the initlia View on
every postback)
Am I doing something wrong, or is it just that WebForms and JQuery Mobile are just incompatible?
If they are incompatible, can anyone suggest an alternative to make my website look like a mobile web app (other than re-designing everything by hand that is).
I use asp.net webforms in conjunction with jQuery Mobile and they can work well together. However it takes some forethought and planning, and probably some new ways of doing things compared to the traditional webforms approach. So converting an existing webapp is not as quick and simple as you would like.
Some hints:
If you are using a single aspx page with multiple data-role="page" elements, consider putting all of them within one FORM element so that asp.net postbacks/updatePanels can work.
For linkbuttons, you will most likely need to turn off the default AJAX loading of page links in jQM.
In many cases, instead of using postbacks on controls, use client-side scripts to make async calls via PageMethods in the codebehind, or WebMethods in a WebService(asmx). If you are more comfortable with UpdatePanels, these should still work if you have everything inside a form tag and a scriptmanager within the form tag too.
DropDowns do get restyled by jQM, so you might want to catch the change event in javascript and then either use async calls or fire the postback via javascript.
Here are some other opinions:
JQuery-Mobile and ASP.Net - AJAX or Postback?
How to mix jQuery Mobile and ASP.NET
jQueryMobile in ASP.NET WebForm
If you choose to have Ajax enabled with jquery mobile JQM [which is preferred when using JQM to give the user feeling a native app], you won't have the post back anymore. That is not good because you would lose a lot of built in features like validation controls, built in request validations....
So, one of the options would be using WCF restful service and have it compatible with asp.net (by having this in the web config: serviceHostingEnvironment aspNetCompatibilityEnabled="true"). In this case, you need to mitigate security threats like script injection and cross side request forgery and .... inside with the WCF service as there is no built in request validation.
And now some JQM gotchas:
In order to avoid a lot of surprise, you may have only one page in the DOM by removing previous page from the DOM. This way, you don't need to worry about having multiple items with the same id in the DOM.
The other thing is binding events. if you have a java script in you master page and you have let say a click event to bind, make sure to use one instead of on. otherwise, it behaves unexpectedly.
For the client side validation jquery validation works fine and easy to use and no conflict with JQM.
Is there a way prevent an ASP gridview from always relying on javascript for the edit and delete LinkButtons? If I disable javascript in my browser the edit and delete commands still seem to link to "javascript: _doPostBack". (I'm using VB and .NET framework 2.0)
Thanks in advance.
You could implement the edit and delete buttons yourself using an <asp:TemplateField>. Then you are free to have them do the postback however you like, with <input type=submit> buttons, perhaps.
You are limited to smaller subset of controls when Javascript is not available. See MSDN. The postbacks function conveys to the runtime what was clicked and that is how the server side events are triggered. If you really want to develop an app without Javascript support, you will have to stay away from most server controls. The rendering is fine but any interaction (like editable grid) would be one of those controls to stay away from. You might also want to look into ASP.NET MVC framework.
Which control is best in terms of performance... multi-view or TabContainer in asp.net ?
According to your description I would probably don't use any of those two controls. I wouldn't go with tabs as you don't really need to be able to switch between them all the time as is seems. The tabs container uses javascript to enable you to change tab on the client side.
About the multiview. I find it bad practice to have that much different logic in the same place and it will probably give you problems later on. In my opinion and experience it's usually better to split that up in different pages and have one for each thing you want to add/modify (you can have the delete at the modify page and/or in the listings). I would recommend to stay away from the multiview control for tasks like this, as I think that having one page to show multiple pages is usually a bad idea.
As far as i know TabContainer isn't a native control in ASP.NET, you could use TabStrip from microsoft.web.ui.webcontrols, but this is limited to Internet Explorer.
So if you have TabContainer from a third party source, use MultiView which is native to asp.net therefore faster. But everything in ASP.NET eventually renders as basic HTML.
I don't know how they render in HTML.
In Asp.Net, what control is more suitable for getting time (hh:mm) from user and pass it as a parameter to a query?
If you don't mind using the ASP.NET Ajax Control Toolkit, you can use the MaskedEdit control. The second example shows you how to let users enter a time-value.
I believe you have to choose between the following three:
Use a TextBox and do extensive input validation.
Use solution #1, but add a client side time picker on top of the TextBox.
Use two DropDownList controls - one for hours, one for minutes.
Use some kind of third-party time picker control.
Which one is better? I would say, that depends a lot on the expected users of your application. Anyone used to working with a keyboard is likely to prefer the TextBox. Others might prefer the other options. For the broad masses, I would most likely go for solution #2, as it should suit both keyboard and mouse centric users.
If you choose to go with a third-party control, be wary that it might not degrade gracefully for users that do not accept Javascript. The control might just revert to a simple TextBox, possibly without any validation logic.
I am using C# and ASP.NET with version 2.0 of the .NET Framework library on this particular project. We are also using the AjaxControlToolkit. The AjaxControlToolkit should have the controls available to make a descent User Interface solution to the problem I'm facing.
I have run into this in a few projects in the last year, and used different solutions in the past. The current design of the project I just picked up, is that there is an <asp:DropDownList> control and on page load a Database call is made to get a list of values. This is then bound using DropDownList's datasource. The problem is that there is 25k items returned from the database. First thing, that's not acceptable for a user to have to scroll through tens of thousands of items. But, even more importantly, is that in every browser that it is tested on (IE 7, FF 3, Safari, and Chrome) the browser completely hangs as it is propagating the dropdownlist items.
What I'm thinking is using a Modal Popup form, which an Autocomplete Extender that allows the user to drill down to a specific company. So, in the field where they have to choose a company, they click on a "select company" icon, the modal form comes up, letting them use the autocomplete extender to select an existing company. They click "Ok" and it save the value to the field.
However, I'm an old school command line/shell/terminal guy, and my ideas of acceptable UI design might be skewed (give me a command prompt on any system, and I'm good to go). I would like the advice of those in the community here as to what they think would be an acceptable solution, or if they have faced other issues like this.
I think your idea for the autocomplete extender is the best solution. I've had this problem as well (sounds similar--a project you are taking over from somebody else). The push-back often comes from the user side. They are used to being able to select from a list of items. Unfortunately as the database grows, this becomes less and less feasible.
But when you have 0.5MB of html downloaded on the page (not including the viewstate), compromises have to be made.
Why do you think you need to create modal popup? Can't you just have the extender on your data entry page?
I had to deal with the same issue. But I ended up using a combobox with paging support and auto complete. Currently this combobox happens to be from Telerik. Its a comboBox for auto complete since you can't type into a droplist.
I agree that no user is going to want to look thru 25,000 items to find the one they want. Is there some way you can limit the data so that they drill down? Like selecting a region or type of company first and then showing the ones that match?
Multiple cascading ListBoxes, each futher refining the resultset of the previous
AJAX AutoCompleteExtender