ASP.NET's GridView controller is great, it's easy to use, it offers sorting, paging, and other stuff, but I find it difficult to customize the way it looks.
The GridView will always generated a table with headers and divided columns, but sometimes I need the users to see a better looking listed items, customized using CSS.
In other words, I don't want something like this:
I want something like this:
But when I'm going to generate the HTML and customize the way it looks, it would take time to implement the paging and sorting by myself, from scratch.
So How can I mix the Customized HTML with the Capabilities of GridView?
You are looking for the Repeater! Complete control over layout and rendering, but the downside is a lot of the built-in stuff like paging and sorting is not there.
I've actually used a Repeater combined with ASPNET Pager: http://www.codeproject.com/Articles/11418/Pager-Control-for-ASP-NET, and I also rolled my own multi-sort.
It's more work than a GridView, but if you want complete control, there's no better option.
Related
Lets say I want to make a website in which only one HTML template is used. For example, if one wants to create a new object, he clicks a button, and form shows up, leaving the remaining web page intact. My question is simples: should I use only 1 view to handle all the possible inputs/outcomes or should I have multiple views that handle the same template?
Thanks in advance
You can do one view, but if it starts to get complex, accounting for each possible input and output can become a headache. I suggest you use as many views as you need and then later implement AJAX to present everything as if it's only one-page
Seems like if that is the only thing that you want to do, having one FormView and handling the cases accordingly should suffice. For a given form, if it's not necessary, keeping it to one view is generally a good choice.
I've had the chance to work with very different types of frameworks for web development. Somehow I can see that every framework tries to avoid me writing pure HTML code.
For example Spring has it's own tags, Struts comes with it's own tags also Zend and Codeigniter (PHP) have form helpers.
Does this mean I shouldn't just write HTML code myself or that it's not recommended? SHould I be using them? because they don't seem that intuitive, easy to manage and time saving as they intend.
You need to write your own HTML (and CSS) to define the overall structure and layout of your website design. Don't confuse this with time-saving features that eliminate the need to write repetitive HTML, such as form inputs and navigation menu items.
For example, under ASP.NET MVC you still need to get the bulk of your HTML into a MasterViewPage or Razor Layout, but when it comes to writing all of the form inputs you just need to put <%= Html.TextBoxFor( m => m.FirstName ) and it handles the rest, which saves you the trouble of writing boilerplate HTML for the <input /> element. It also helps avoid bugs (if you forget a name="" or `id=""`` attribute, for example, but in some frameworks it's essential to get reliable round-trip form data working.
I suggest you to manage your code by yourself if you don't have VERY good tools for generate it (for example Razor in ASP.NET MVC) which can do your code cleaner and more intuitive. In your case if You use Zend i suggest you to write your html in normal sites and only use generator for forms with Zenf_form. Becouse it is great.
Generated code services I have used generate ugly code that is hard to sift through at a later date.
writing the code and HTML yourself makes for a better structure and will not effect the way its run if that is what you are worried about and these languages are set to a standard.
Recommendation is to write the code where you can and generate code in areas you dont (or learn how to code it before you attempt it in test sheets).
I think it is a case by case basis.
These frameworks help you get rid of boilerplate code and write cleaner applications. You might also avoid some security problems by using them and you respect MVC.
There might be a performance penalty though so if you write a small application or you have certain requirements in speed you might be better without (some of) them.
I'm currently evaluating the combination of jQuery Mobile and PhoneGap. For my application, I need a kind of "inner application" navigation model: A fixed header that contains elements to switch between various contexts and functions, and the entire region below that depends on whatever function is selected. An example: The user selects a customer and can then switch between different data and statistics views concerning that customer. Alternatively, the user can switch between different customers while keeping the same view. Each function / view might again be a rather complex construct of multiple pages with its own navigation.
I think I understand the basic ideas of jQuery Mobile by now, but I'm unsure how to implement this "the right way".
I could do this simply by coding the entire header with the navigation into every single page, but that feels like a really bad idea - lots of redundant code, lots of places to insert tiny mistakes that are very hard to find.
I could try to add all the UI elements for the different views to a single page, hide them and only display the ones that belong to the current function. This doesn't feel right either - I suspect that the DOM would be really large and I suspect that this might cause various (performance) issues.
I could try to create the contents of the page that depend on the function dynamically using jQuery DOM manipulation techniques. This sounds like a good idea, but the individual pages can be really complex, and I'm worried that generating lots of complex HTML code using JavaScript will lead to an unmaintainable blob of code.
I could try to combine the approaches - code the individual pages in the HTML file and then somehow "link" them into the appropriate place using DOM manipulation - but I've never done that and I'm unsure if and how I can get this working.
I could try to put the "detail" page into an iframe - would this work at all?
What is the best / canonical way of implementing this kind of application? Do you know of any tutorials or examples?
Just detach your header and then reattach it to your new page. For instance:
$footer = $("#myfooter");
$header = $("#myheader");
$footer.detach();
$footer.appendTo('#newpage');
$header.detach();
$header.prependTo('#newpage');
$.mobile.changePage('#newpage');
Detaching does not kill all of your button handlers / etc. You will need to keep track of what page you are on or look at location.hash to do different things depending on what page is being shown.
--Greg Frame
Thex Interactive
www.thexinteractive.com
The first way is the easiest way to do it. That's the way i did it too. Also this gives u the freedom to add a button specific to whats in the browsing area for that page.
The second approach will have loads of extra calls which you don't want.
The rest of the approaches are not worth the effort.
For full control of your application, do you prefer a GridView or a HTML table?
And why?
For instance, I need to create on-the-fly hyperlinks-per-row in a GridView/HTML table. What object would be more easy to add that feature (or others like this one)?
Note: I'm creating programmatically my datasets
If you don't need the built in support for sorting or paging, and want more control over the rendered output then I would consider using a Repeater control to output a table. If you need the built in sorting/paging then the GridView can be very helpful.
If you want the best of both worlds, upgrade to ASP.net 3.5 and use the ListView.
EDIT: Can you clarify what you mean by 'on-the-fly hyperlinks-per-row'?
Stay away from the Gridview. It has to pull down the entire dataset to render the paging. It's much faster to render only the rows you need (e.g. rows 30 - 40 of 6,0000) and use a seperate pager control.
Also when it comes to HTML/CSS, using a repeater or listview will be much easier to debug, since you'll have total control over the code.
A plain HTML <table> generated by Response.Write is straightforward and has the added benefit that if you ever work on a non-Microsoft system, you won't feel naked without their redundant ASP.NET web controls that mostly just make it more difficult to generate the HTML everyone already knows.
I think the Repeater or the newer ListView is the way to go if you don't need sorting and/or paging. The Repeater and ListView allow you to control the HTML (the GridView is a total black box in this regard and generates atrocious HTML) while avoiding the tedious server-side code that comes with the <asp:Table> control: "OK, new row. New cell. Do something with cell. Add cell to row. Add row to table. Repeat".
On the other hand, if you need paging and sorting, the GridView is probably the better solution.
You can use GridView or more simple Repeater-like controls to build your own html, even if you have to sort/page you data.
With a Repeater for example you can build a custom system of pagination using a PagedDataSource data source with the property AllowPaging sets to true.
The only problem is clearly that with a simple Repeater you must write more code to do the work that GridView does natively.
But the result is faster.
I imagine there are many of you out there who have developed an application online which automates a lot of processes and saves people at your company time and money.
The question is, what are your experiences with developing that application, having it all set in place, then "spicing" it up with some Ajax, so it makes for a better user experience?
Also, what libraries would you suggest using when adding Ajax to an already-developed web application?
Lastly, what are some common processes you see in web applications that Ajax does well with? For example, auto-populating the search box as you type.
My preferred way of building Ajax-enabled applications is to build it the old-fashioned way where every button, link, etc. posts to the server, and then hijack all those button, link, etc. clicks to the Ajax functionality.
This ensures that my app is down-browser compatible, which is good.
It doesn't really matter which you use, unless you're trying to do something very specialized.
Here's a good list: http://code.google.com/apis/ajaxlibs/.
Yes, auto-completers are a pretty handy implementation of Ajax. It's also quite useful for data-intensive activities like populating drill-down data.
A lot of what you can do with these libraries isn't Ajax-specific, there is a lot of UI interaction that can benefit the user as well. You can do things like slideshows and lightboxes quite easily with many of these libraries.
Pick the one that you're comfortable with. The syntax they all use is a little different. Give a few a spin and try to build simple examples. Stick with the one you like.
Using ASP.NET Ajax to wrap a few chunks of code is an easy way to get going. But personally I prefer to use jQuery. You can easily add some simple Ajax calls with it to make the UI more responsive without the ASP.NET Ajax overhead.
If you are using ASP.NET to write your applications, adding AJAX using ASP.NET AJAX is very straightforward and in many places will not require you to change any code at all except add two controls to the pages you want to modify.
This works using partial page loads. The controls you have to add (off the top off my head) are called something like
<asp:ScriptManager
and
<asp:UpdatePanel
The biggest thing I use for AJAX is lists and search forms. Why? Because the overhead of loading an entire page when you are going though a list of, let's say, 200 records, it will get frustrating for a user to go though everything. However, it is important that if you click on a link in the page and then hit the back button or use a link at the top to return to the same page you were on.
For search forms, as you fill out the form I use AJAX queries to return the first few results and a number indicating how many records that were returned.
For AJAX frameworks, I use mootools. http://www.mootools.net.
Please ignore if not using ASP.NET. Your platform wasn't clear from your question.
Depending on when you created your web application, your web config file may need some tweaks to use ASP.NET Ajax. The easiest way to see is to create a new web site with the ASP.NET Ajax template and compare the web config, copying over configuration items as needed to bring the old one up to date.
If "spicing it up" is all you're after then develop the fully functional app without AJAX first. From here you can unobtrusively add AJAX functionality and ensure that the app degrades well for non JavaScript-enabled browsers.
I've started using jQuery for JavaScript on my site. It takes away all the worry of cross-browser JavaScript differences - things like class and classname, and getElementById. It also includes some very handy and simple functionality for AJAX postbacks. It's very easy to learn and extremely lightweight when used well.
I've seen some good use of AJAX right here on Stack Overflow, things like the tag selector and the question lookup when you type a question title. I think these simple things work best; we're just adding to the user experience with small additions to functionality that are intuitive, we're not flooding the screen with drag/drop handles etc.
I would differ from the first poster. Adding Ajax isn't always as easy as 1,2,3. It really depends on what you are after.
Adding things such as a colour animation can be made fairly easy, but if you are after things such as auto populating a text box, this requires extra code. It's not as easy as adding just something client side. You would also need to add in server-side support to fetch the partial query results.
Going beyond that, it can become even more complex keeping your client-side script in sync with server-side support.
But with the spirit of simplicity in mind there are libraries you can use to 'spice' up a website with animations and other eyecandy that can be implemented fairly easily which have been mentioned already.
I've often had to Ajax-enable an old-fashioned ASP.NET 2.0 sites. The easiest way I've found to do that is to create a new Ajax-enabled site and copy and paste certain sections of the web.config into your old project's web.config.
Just compare the two and see what's missing in your old one. You'll obviously also need to add references to AjaxExtensions and AjaxControlToolkit.