I have a data grid in an ordering system to represent all line items ordered. There is a fair amount of calculations needed to determine the pricing. I allow the user to edit an order and make changes to the QTY only on the data grid. How do I program the changes to refresh the pricing on a different column other than the one being changed?
If you don't want to refresh the whole thing you can string multiple partial refreshes together. I googled for "XPages multiple partial refresh" or something and found this :
How to do a partial refresh of multiple items in Xpages correctly
Which basically points to an article from the late, great Tim Tripcony which is saved here : http://avatar.red-pill.mobi/tim/blog.nsf/d6plinks/TTRY-84B6VP
There are other examples out there as well.
Related
In the Project Tracker template there is a feature where statistics for a certain project's items are displayed. You can filter the project items, but the statistics will only show those statistics for all the project items, i.e. the filters do not affect the statistics.
I would like to add the feature of filters affecting those statistics in a similar implementation of mine. My current solution passes the keys of those project items (affected by filters, too) to a calculated data source, which then calculates the statistics using those item keys, essentially applying the filters used in the page.
My issue is that my calculations are restricted by the query page size. For example, if I apply filters that limit the number of items to 15 records, but the page size is 10 records, I will only have statistics of those first 10 items, which is not useful. I'd need to have the statistics on all the records that are left after filtering.
One way to solve this would be to get rid of the query page size and leave it at 0. However, similarly to the Project Tracker template, I'm displaying the project items on the page in a table, and if I do that, the page becomes too heavy.
How can I circumvent the query page size? I'm thinking I could
limit the items displayed in the page by some other way than query page size (i.e. hiding items from the UI)
use a different datasource for the statistics, but in some way copying the filters used in the datasource that is displaying the project items
Both of these ways I could think of, I can't seem to implement. I don't know how I could hide items from the UI to make it less heavy, as query page size pretty much does it. I have also tried copying the filters from a datasource to a similar one, but that does not seem to work.
EDIT: I might have come up with a way to solve this myself, but I still need to implement it. Now I'm using the page size restricted Items Ds to apply the filters on, and the statistics are build from this data source. If instead, I use a non-restricted Ds called AllItems, and apply the filters on it, and then pass the item keys to a page size restricted Ds (to show the items in UI) AND to a calculated Ds (for the stats). Will make a response once I've verified it works.
I solved the issue myself.
To produce (refreshable) statistics subject to filtering but not restricted by page size, I used the following datasource structure:
In this structure, the filters practically flow to the data sources below, as they are passed the ItemKeys that fit the filter. What this completes is that my Statistics (used in piegraphs etc.) can be filtered dynamically and account for all the records that fit the filter, while the UI does not get crowded over too many records, as the data source used in UI has a query page size limitation.
I feel like I am fighting against the current when I develop ASP.NET Webform apps. I frequently run into the same problems, and while I eventually find some kind of workaround i'm never fully satisfied with the results.
Here is an example of a typical problem:
The design requires a grid or grid-like result set. This result set is pulled from a database, however, there are additional controls on each row that are not data bound, but their contents are used to insert data into other records.
A good example of this would be displaying a list of products, then adding selected products to a shopping cart based on values entered into quantity fields, and options selected per product. Throw into the mix that you have to allow multiple lines to be added to the cart at the same time, and it starts to get more complex.
Let's add to that mix that you can't select certain products together (mutually exclusive), that you can only select a certain number of one product, but not another, that prices may change while the user is selecting their items, that you you get an overall discount per item based on quantity purchased (both per item and overall order), that you are using a line of credit and cannot exceed the line of credit, nor can you buy more of a given item than an arbitrary amount set in your account or in the product by your account representitive (think certain over the counter medications that the government limits how many you can buy), etc.. etc.. etc..
What starts out as a simple grid with an add to cart becomes a hopeless mess of business logic, which then of course requires validation and notification to the user of various errors in their choices.
How does one deal with very complex data entry schemes in asp.net? How do you even begin to design a piece of software to do all this?
EDIT:
Please don't suggest changing the interface, as the interface is not the problem. Users are fine with it, and they demand that it function the way it does. I'm looking for help on how to design and solve the problem of implementing it.
Don't put anything other than the basic validation in your code behind. The code behind should just take what the user entered, build a business object (or collection of business objects) and let those business objects validate themselves.
Each business rule should be a single function call on the business object that deals with just the one rule and nothing else. You then simply call them one after another and keep track of which ones pass and which ones fail.
When a validation fails, the business objects can provide the code behind enough information that it can display the correct errors and highlight the fields that have errors.
Some options to consider:
Separate out your validation logic so you can call it from both client-side and server-side code (enables next point).
Use AJAX to perform server-side validation and provide immediate feedback as the user performs various tasks, ie increases quantity.
Provide abundant and clear instructions/feedback to the user both before and after any actions are performed. Before: warn that product X can't be bought with product Y (especially if Y is already in the cart). After: explain the problem exactly and suggest ways to correct, eg "why don't you remove product Y?")
Fail gracefully, ie if only one product fails validation then ensure all other products are added.
Simplify the entry process, eg only allow one product to be added to the cart at a time.
The last point is important. A complicated data entry process can confuse users before they start, and makes trying to understand the numerous validation errors difficult. And this is even before you start coding the validation logic.
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.
I have a web page that loads some data via a SQL query into a datagrid. I was asked to add a new column. During testing I discovered that pulling this extra column of data from the database slows the query down substantially. What used to be a sub-second query now takes about 3-4 seconds. I've checked the database and all the appropriate indices are in place, and a database change wouldn't be practical here.
Anyway the slow down in the page loading could really impact productivity.
If it's possible and practical, this is what I would like to do. I'd like to render the datagrid as before with the original query, but leave and extra column blank. Then after the page is rendered use Ajax to go back to the server and get the data for the remaining column and populate it. That way, those users who don't need the extra column to do their work, don't have to wait so long for the page to render, but those who need it can just wait a few seconds and the data will be there.
The problem is, I don't have the faintest idea how to put this together. Any suggestions?
Give the user an option to display the extra column or not. Then have two queries that can bind to the GridView, one that returns the extra column and one that doesn't. Then it is up to the user to decide which "view" they want. So that they do not have to decide every time they open or refresh the page, you persist their selection.