Lets say I have three webpages - one for big cars, one for middle sized cars, and one for little cars.
Each page is almost identical and consists of a form where you can select to filter a list of cars by colour etc and a submit button. On the client side the only difference is the title.
On the server side the only difference is in the where clause, for example:
... where car_type = "big" and color = %s, Response.Form['color']
But how can I save myself creating three different asp scripts for each page? How do I pass around which car_type I have?
I was thinking maybe by using a query string, but the query string data will be lost when the user presses the submit button.
Thanks,
Barry
You've found one solution yourself. Might not be the best one, though. When programming you always want to minimize redundancy, to avoid code duplication, because it'll invariably become a maintenance hassle, if not nightmare. So you really want to avoid creating three identical pages with just a tiny parameter difference.
Why don't you simply create one single page containing a select menu for the type of vehicle to search for? You could attach an onselect handler using Javascript to that menu which would reload the page if that's necessary. (And it might not even be.) In some menu, you could have links pointing to this page (search.asp or whatever) containing the vehicle type like this:
search.asp?type=L
search.asp?type=M
search.asp?type=S
Just an idea. Toy around with the code and that way you'll learn a lot. ASP is an old technology but I think a very good one for learning web applications. Do read the docs to learn about the facilities it affords you to avoid duplicating code. Here's a collection of things I found useful.
One way to do this is to use the query string the first time the page is accessed and then a hidden field to pass on the car type on filtering.
Related
I'm going to display a product detail from a database. But I can't decide whether to use an $.ajax post to a WebMethod that returns a JSON string, or a traditional Page.Load with sqldatareader in codebehind.
I know how to do both, coding is not the issue. I'm wondering what would be faster and more secure?
It depends on what kind of data you are showing on the page. (more of howmuch data)
Lets say if you are showing a fixed amount of data like, summary, product detail then its better to fetch data from server side and bind in label in Page Load event.
But if you are about to display the list of item (which may vary depending on the user input) for example product list, order list, employee list. in that case it is good to fetch the rows using ajax. reason is to display the fixed number of rows on the page (lets say 10) and there should be a pagination to jump to the next/pre page. now when user click next or previous it should not post back the page and should get the rows using ajax.
Each method has its advantages and disadvantages.
AJAX advantages and disadvantages
Advantages:
Forces you to separate the concerns in the code a bit more, you will have the data gathering and the data display in different places
The code will be more testable due to this additional modularity
Disadvantages:
Slower due to the additional HTTP request
Harder to deal with the back button and with bookmarking
Search engine optimization will be harder due to data not being right in the html
Suppose I have a list of a couple of thousand organizations and a user needs to be able to select one of them. The list is too large to populate in a dropdown at page load, and the user often knows what they want but it's not the first part of the organization name. That is, they know "Collections" but not that the precise name of the organization is "Department of Collections". So the user will need/want to type in some information.
It's easy enough to use an autocompleting textbox of some kind, but I don't want to allow the user to type in random text - they have to choose one of the organizations explicitly.
What's the best solution?
IMO I will simplify the UI to:
a textbox to enter the string
a drop down to set the filter options like: "contains | starts with | ends with"
a button "Find"
Then, I will populate a view based on the search string & let the user choose the valid item or refine the search
IMO with something like an auto-complete, you will end up writing a lot of parsing code to get to the string & then there might be server-side load considerations...
HTH.
In additional check if 'facetted navigation' is something you need. Ref.: http://www.alistapart.com/articles/design-patterns-faceted-navigation/
So it seems to me your main challenges are to
Express that the user needs to select an organization from the list (and only from the list).
Express that there are a lot of organizations on the list.
Provide some means for the user to quickly find the organization on the list.
I would say present a selector control that fits in with the rest of your design with a search box just above it. You should then page the list as there will be lots of pages with that many elements indicating that the user should definitely use the search. The search essentially acts like the auto complete, but instead of the found options changing the text, it will change the contents of the paginated list. If you do this on a character by character basis (or throttle using Reactive Extensions), it's very clear that you're just filtering the list to make selection easier.
You could use a CustomValidator to ensure that the TextBoxes content in contained in your collection.
You could use the Ajax AutoComplete Control: http://www.asp.net/ajax/ajaxcontroltoolkit/Samples/AutoComplete/AutoComplete.aspx. You can opt to only do a lookup if the user has typed in a certain number of characters.
You'd create a static Web Method to query the collection (you could use LINQ) and return matching organizations.
You'd obviously need to validate the textbox input afterwards.
Is it possible to structure your list a bit more like a tree, so that it is not a single list. E.g. Could you have a grouping like "Government Depts" and then add Dept of Collections to that. Then ask you users to first select the top level grouping then show them a shorter lists of organizations in that group?
It sounds to me as if your data list should really be in either a database or at least stored well away from the UI.
Wherever its really stored, place a keyword for each entry, say "Collection". The list of keywords could be available as part of your auto-complete functionality. Then search on the keyword alone.
If you could divide items in categories, would using some kind of tree control help?
So, when user clicks on a node you load only items in that node. And so on.
I'd break it into two paths...
Use an autocompleting textbox, for the person who types the correct title (i.e., Department of Collections); and a separate search button to search for possible matches. The search button would take you to a results page to select the desired choice. This functionality would be similar to the way search on MSDN works.
Initially a tree view sounds cool, but are you certain that a single classification will reduce the data into manageable sets? If 80% of your data gets classified as "government dept" this doesn't really help things.
The problem is you want criteria that allows users to quickly split a large list into smaller sets that are easier to consume. Additionally, there should be enough flexibility to react to changes in data.
I'd suggest using a tagging pattern like iTunes. In my library "rock" describes 80% of my collection - but is still a useful categorization for something like random shuffle. I also have the ability to stack tags so I can use genre="rock", decade="1990" and quickly sift my data down to whatever is of interest.
In the UI, I'd recommend a section that allows the user to apply "filters" which is nothing more than selecting specific values for tags. Break the list out into pages and allow them to see a tally of potential matches.
Scenerio:
- Navigate to screeen XYZ and see there are 10,000 companies to pick from
- Click "classification" and select "Government dept" and the list updates to indicate there are now 1,000.
- Click "region" and select "South" and see my list drop to 200.
- Sort list by name and then select (or scroll through, whatever)
I'm developing a website (using asp.net-mvc) with a SqlServer 2005 database.
I have numerous database tables which drive content pages for the site e.g. I have a table called Activity:
Activity
-----------
ID
Name
So for each activity record, there would be a corresponding 'Activity' page. The same applies for other tables e.g. Location and Person etc.
For the purposes of SEO I want to allow storing of additional info for pages such as html meta title/descritpion/keyword info, and perhaps even page content.
I'm considering two main options to do this:
1) Modify Activity, Location and Person tables to include the relevant fields to hold this additional info
or
2) Create a PageInfo table to hold all this info in the same place, then simply add a PageInfoID field to the above mentioned tables
What are the pros and cons of these approaches and are there any better ways of doing this?
(One con I can think of for option 2 is that you can't really enforce the 1:1 relationship, so you could, theoretically, have a PageInfo record used by an Activity record and a Person record.
If i may suggest.. you may be going about this SEO thing the wrong way.
Rather than trying to pack each page with additional meta-data per 'Activity' object to get better search results from the page, i think you should concentrate on simply putting the 'Activity' data into the page with clean, semantic, valid XHTML and CSS. This way, search engines will worry about finding out which part of each page is of the most importance and index/rank that accordingly.
Also, trying to add these 'page meta' objects to the domain model of your system will create all sorts of conceptual (and indeed practical) problems for your design and it will certainly be confusing to users who will struggle to understand what the importance of the difference between say an Activity Title verses a Page Title is. Let the bots figure our keywords from your content, dont try to do it yourself - this type of over-optimisation will actually end up resulting in worse page rankings than better ones.
When and why would it be a good choice to keep the view of two different sets of information on the same page, and just change what's visible depending on different parameters?
For example, an application I'm working on has three levels of users: Admin, Director and Project Manager. We have a Managers.aspx page which follows this flow of control:
If user is admin, load gridview list of directors with several simple CRUD-like properties. This includes a link for each director that, when clicked, will load a new gridview with several properties of all of the Project Managers belonging to the selected director.
If user is director, load straight to the list of Project Managers that belong to this director, in the exact fashion as described in the second half of the "if user is admin" clause".
This is all done on one Managers.aspx page. Why? What advantage does this hold? When else might this type of situation arise? Personally, this seems like a job for two separate pages. One listing the directors, and another listing the Project Managers.
Thanks in advance :)
As you pointed out, most of the logic for those two requirements is the same: get a list of users, present them in a gridview, apply simple CRUD functions. Doing this as two separate pages would require all that code to be repeated twice, and then kept in sync.
The only real difference between the two screens is which users it shws by default... That's one if-statement of difference in a pageful of code..
As stobor indicates - when you don't want to write the same code twice.
Using the one page solution, the decision about which view to display is made on that one page. If you separate the different views out to different pages, you have to make this decision every time you need to display this data. So rather than one single if/else in Managers.aspx to determine the view, you have multiple if/else statements on multiple pages which are intended to decide whether to load AdministratorManagers.aspx or DirectorManagers.aspx.
Provided your application is robust enough, and you're not doing something stupid like determining which page to show based on a querystring value, there is no real problem using one single page to display different views. In fact, many websites do this. What you don't want to do is use seperate but identical controls for each view, because then you're just going to end up with messy code. It may make sense to create custom controls called 'AdminView' and 'DirectorView' to at least allow you to think of the two views as separate entities, but you'll have to decide for yourself whether this will be a headache-saver or a waste of time.
This is a purely theoretical question (at least until I start trying to implement it) but here goes.
I wrote a web form a long time ago which has a configurable section for getting information. Basically for some customers there are no fields, for other customers there are up to 20 fields. I got it working by dynamically creating the fields at just the right time in the page lifecycle and going through a lot of headaches.
2 years later, I need to make some pretty big updates to this web form and there are some nifty new technologies. I've worked with ASP.NET Dynamic Data just a bit and, well, I half-crazed plan just occurred to me:
The Ticket object has a one-to-many relationship to ExtendedField, we'll call that relationship Fields for brevity.
Using that, the idea would be to create a FieldTemplate that dynamically generated the list of fields and displayed it.
The big questions here would probably be:
1) Can a single field template resolve to multiple web controls without breaking things?
2) Can dynamic data handle updating/inserting multiple rows in such a fashion?
3) There was a third question I had a few minutes ago, but coworkers interrupted me and I forgot. So now the third question is: what is the third question?
So basically, does this sound like it could work or am I missing a better/more obvious solution?
Did you try creating a FieldTemplate that had a "ListView" of all the Fields? (the ListView would use Dynamic Data to determine which FieldTemplate to display for each field.)
I don't see why this would not be possible. Although, "out of the box", you may have to hit "edit" on each row of the new FieldTemplate's ListView to edit the values. It would be like replacing the "Order Details" link in the Orders List, with an inline List of the "Order Details".
1.) Not very nicely. Can you imagine showing a DateTime, Integers, Phone numbers, Urls, etc with just ONE user control, like text.ascx? Why not have multiple field templates and use UIHint to specify usage per column?
2.) Yes.
3.) Define basically?
regarding one to many relationships, you might have a look at the ListDetails.aspx Page Template in Dynamic Data. Hope this helps.