I am trying to develop an interface that binds to a complex backend model. What I need is a way for scripting to enable me to have a page load different page fragments based on what list row a user clicks on. As an example, on the left side of the page there would be a vertical list displaying different sections in a large assessment 'document' (mental health assessment) (each section would be it's own data model [e.g. presenting problems family history, trauma history, etc...). In the main section of the page to the right, you would have room for a page fragment or some type of container that would contain the actual page or page fragments associated with each section listed in the list on the left. When you click on the section name in the list to the left, scripting would be able to have the correct page fragment or page loaded inside the container.
The data model needs to be this complex because there are multiple types of "documents' and the system needs to be able to dynamically load a list of document sections and allow the user to load the form for each section type.
THIS IS FROM Markus Malessa: The dynamic page content is definitely possible, however since it sounds like a lot of your items are going to be based on hard data, the models really are not dynamic, so you really can't build in dynamic data at run time for example. Rather than visible/invisible properties I might suggest navigating to different pages instead and maybe having many-to-many relations to your list item and if your list item has OldFamilyHistory and NewFamilyHistory data relations incorporate a popup to select which page you may want to navigate to.
Related
I am trying to let an info part's dynamic link work so that it only opens the queried values in a list on the new form.
Basically now, if i click Installation No. on the form part below.
Then this form opens up with all the Installations, not only the related Installations.
What i want to happen is when the Installation No is clicked then the list should look like when the "more" button is clicked or like the image below.
It seems like this is the standard function but i want to know if there is a way to change it.
Does anyone know a solution to this or know if there is any?
Dynamic links should work on info part forms provided prerequisites are met:
A data relationship exists between two tables, usually as one-to-many (one parent row relates to many child rows).
Each table has a field of the same extended data type.
In the parent table, the extended data type field values uniquely identify each row.
The extended data type has a relation defined on it for the field in the parent table.
Each table is a data source for one of the two forms.
The parent form contains a button that launches the child form.
I have a Cognos report and i have created 3 pages and 1 common prompt page. According to a radio selection in the prompt page i show the appropriate among these 3 pages.
In each page i have a block that is the header and there i just show title, current date and the selected values of the prompt controls (parameter values).
This header is the same among all pages and i want to find a way to create only 1 header section and then assign it on the top of each page. So if later i want to change anything in the header i will do it in one place.
Any ideas?
Re-using parts of a report (either from the report or other report in Cognos Connection) can be achieved with the help of layout component refenrences which are inserted into your report page and which refer to other existing components.
To use them proceed as follows:
Indentify the layout component(s) to be re-used (e.g. a table or a text or more or less anything less).
In the property list of that component go to the name and give it a unique name.
In the report page that is supposed to re-use the component drag an instance of the layout component reference to the appropriate location in the page.
Specify the target of the reference by choosing the report and within the report the named component (same name as given above).
Example
A block component (which could be incorporated into a header) is to be re-used. Give the block a name, e.g. my_block:
From the toolbox drag the layout component reference
to the report page. A dialog box opens which permits choosing the target component:
I have four different tables and I want the data from each table to be shown on four different tabs?
Create four subforms, each based on a different table. Place one subform on each tab's page. If your tables are related, you'll need to either base your main form that contains the tab control on a table or query that contains your key column.
While #Joey's answer is certainly the way to place different tables on different tabs, it can lead to a slow-loading form. In general, I prefer to have one subform control into which I can load different forms as required. The user does not see any difference, in that there is not much difference between clicking a button and clicking a tab.
Me.TheSubFormControlName.SourceObject = "frmForm1"
You can also set the link child and link master fields at runtime, if required.
I have a single web page with master detail form/input layout. Currently the form works in a way like
User opens the page containing both master/detail data entry controls and enters the master information (The details save button is disabled)
When he saves the master information, the save master button gets disabled and save details is enabled
User continues to enter multiple details which get populated in a gridview at the bottom of page
All works well
Problem is that, the master part contains a lot of data entry controls (drop down lists gridviews etc)
How do I facilitate the user much more then the current layout? Should he be redirected to a new page after he enters the master record ? How can I improve on this?
If the user doesn’t need to refer to the entire master to complete the detail, and isn’t navigating among multiple masters to view/edit their details, then you don’t need a master-detail, and you can divide the input into two or more windows. A window for the details can repeat a few fields from the master that users need to complete the details.
Assuming it is desirable to keep everything on the same page, I think I see few things you can do:
Use edit-in-place for both the master and detail, so you don’t need space for both editing/creating a record and space to display it. Every field should only appear once.
Pack your controls more tightly together. You can do this without appearing too cluttered if you adopt a quieter visual style (e.g., lose the reverse-video and the rules). Allocate about 20 vertical pixels per single-row control
Adopt an object-selection-action syntax so you don’t need to take space repeating the same command buttons/links for every record. That leaves mores space for fields.
Put your tables in their own panes with vertical scrolling. The tables you have now are already pretty short (5 or fewer rows), but limiting them to 5 or fewer visible rows will keep the window from being too long for cases when there are a lot of rows.
Assuming you have edit-in-place, use wider tables, each set in their own pane with horizontal scrolling in order to reduce the height by moving fields out of the “overflow” spaces and into the tables. Be sure you have row headers that do not scroll away.
Divide fields up into tabs, especially on the master. That reduces the space the master needs to a fraction. You can have tabs within a portion of the master if your users need to keep key fields constantly visible.
Put some fields within the master or detail in expanders or secondary windows, especially for fields the user doesn’t necessary need to interact with (e.g., where usually the default values are correct). Show an aggregate, abbreviation, or summary of what the users don’t see to cue them on when they do need to interact with the fields.
Consider using a “paging” interface for your stack of multi-row text boxes at the bottom of the master so they’re “stacked” in the z-dimension rather than the y-dimension and thus take up the space of a single text box.
Consider using more compact drop-down lists rather than radio buttons, especially for fields the user is less likely to change (e.g., the default is very often correct). A dropdown list is more work to set a value (takes two clicks) but no more to see the value, and you can weigh the editing effort against navigation effort (scrolling, tab-clicking, etc.)
Consider putting the entire master in its own scrolling pane so the detail is always in view at normal window size and the user can scroll the master to whatever portion is relevant for entering details.
If users are telling you that everything in the window must be constantly in view, then you’re going to have to dig deeper, prioritize fields, and make trade-offs because that’s not going to happen unless your client buys everyone a suite of big-ass monitors. Some fields will be out of view, even it that just means scrolled out of view.
There can be various options:
Page may show master and summary (gridview) of details. Save button will only work for master data. Add/Edit details will happening in a modal pop-up.
Have a tabbed view - one tab will show master while other tab will show details. There will be one save button per tab. Tab switching will happen on client side.
Have both master and details always open for editing. Any changes in details will be temporarily held in view-state/session-state. The save button for master will save changes for both master and details. No need to disable any UI.
We typically prefer #1 - IMO, its simple UI from user's perspective.
I have a very simple webforms app that will allow field techs to order parts from the warehouse.
Essentially it work like so:
User selects a category from a filter dropdown, which then binds items of that category to a gridview control
User finds an item in the gridview and inputs a desired quantity (in a text box in a template field in each row)
User repeats 1 & 2 as needed
User sees a summary of the complete requisition
User confirms items and submits the requisition for processing
My no-brainer UI design so far is the generic dropdown-above-a-gridview where there's a category drop-down list that filters a gridview, like in the eye-catching asp.net ado tutorials:
http://static.asp.net/asp.net/images/dataaccess/15fig01vb.png
Each gridview row (in my app, not in the image above) lists an item's details and can accept a quantity input in the template textbox if the user wants to requisition that item.
Given that a user will want items from different categories during a single usage session, I'm trying to figure out a good, user-friendly way to allow users to input a quantity for an item, have a warm fuzzy feeling that their input has been accepted/stored, then change the category filter (thus binding the gridview to a different set of data) and select other items from the gridview as many times as necessary before summing up their order and submitting it.
I've thought about putting another grid below the first and adding items to it dynamically as the user selects each item. But that seems awkward. Ditto with an unordered list or similar simple structure under the grid.
I've also thought about just storing the user's picks in view state or session state and displaying a summary on another page, kind of like a shopping cart sort of functionality. Maybe do that and use some sort of ajaxy goodness on the main page to display something warm and fuzzy when a quantity is input?
WWYD? What Would You Do?
TIA.
I strongly agree with your first choice: users need to see somewhere what they have chosen or they will probably keep choosing it over again thinking it failed. Waiting to display it on a summary page shouldn't even be an option. I don't see much wrong with binding to another grid, although a repeater is also a decent option. Well, there are many options. Anyway, if there is room to do this off to one side or another - especially the left- I definitely would, rather than at the bottom. Also, bonus points for enabling users to change the quantities (or delete all) of an item they already selected, wherever you choose to display this.
I like the idea of a search, but be careful with auto-complete. Google style is good where it displays results below, but I've seen people develop some that are way too aggressive and love to write over what you're typing: this is awful. Good luck.
Probably because both your choices are fine - it comes down to personal preference. The shopping cart idea is well known. But sometimes it gets old if you have to keep going back and forth between the cart and the item selection.
What's wrong with the separate grid? -That way you keep the selection list separate from the ordered items list?
Why tie the user to selecting the correct category and then selecting the quantity and hitting a button?
Why not use some type of autocomplete search so they can type in the produce name they want? Then a user could type "widg", get a drop town of choices, hit tab to go to a quantity field, enter a number, and then hit enter.
Display a quickie preview with the aucocomplete too, like as single row of your data.
Then throw all these into another grid at the top of the page if its a critical part of the application, maybe at the bottom if you think the actual grid results are important.
The reason I don't like category drop downs is people who are familiar with their jobs or company usually know the names and even skus numebers for what they are trying to do. Having them select a category instead of typing just slows them down. Also I hate running into the "which category is this?" moment. For example, is a chicken a pet, food, livestock, or food producer?