Design help needed

[Scott Emerick]

Hi All,

I am having a real brain block here and thought maybe someone can nudge me in the right direction.

What I need is a grid or repeating section that would dynamically populate from records in a table and allow me to save all the rows as a new record.

This screen is for entering inventory counts, so I need the items listed in a grid type format, enter the current count, then save all rows as new record in history table.

Any help would be appreciated

Thanks,

Scott

[lvasic]

Re: Design help needed

It sounds like you want a Header/Detail setup. Two tables with your totals saved in the Header table.

[Scott Emerick]

Re: Design help needed

Actually no ... I just want detail records .. I want to populate the grid with inventory items .. ID, Description, ect. .. from my inventory items table then add a column to enter physical count, then save all rows as new records in the history table. I can fake it by creating the records when the grid opens, but then if the user cancels out I have a bunch of blank records in the table that I then need to remove. I am trying to keep it all on screen until user hits save .. and at that point the records are created.

Scott

[Steve Workings]

Re: Design help needed

A repeating section, with textbox control for those columns you need data input, and label controls for all other data shown?

[GGandhi]

Re: Design help needed

i think it is better you do this at the database level than in alpha.

the grid is based on a table and it will have a maximum of all fields ( plus any calculated expression) from that table and it will save to that table. dialog on the other hand is free to save all the data to some table you assign to, but to load data that table will be bound to that dialog and it will defeat your purpose.

you could however create a new history table in your database end with all the fields from the original table plus the count column and populate that history table with data from the original table and empty value for the count. and then design the grid based on that table and you will get all the data and of course empty count column and they will fill it out and save it.
this seems logical to me unless there is better idea.

[Nate Mitchell]

Re: Design help needed

Scott, personally, I would take Steve's approach but handle the populate manually (not through data binding).
I typically fall in line with Gandhi and handle this kind of request on the db side, but in this case, you don't actually want to create records until the user initiates the transaction.

To throw one more idea out there, when the ux loads, I would make a call to the DB, get my list of records and iterate through them to create the javascript needed to 1-set the repeating section row count and 2-populate each of the repeating sections rows. The sample xbasic in onDialogInitialize illustrates this pretty clearly. For example, say you have a repeating section with a text box called Test1. You would call the following to create the rows and populate them.

dim js as c
js = <<%txt%
var rows = 3;
var setFocusToFirst = true;
var nullOutExistingData = true;
var repeatingSectionId = 'REPEATINGSECTION_1';
{dialog.object}._setRepeatingSectionRowCount(repeatingSectionId,rows,setFocusToFirst,nullOutExistingData);
var _d = {};

_d['TEST1'] = 'val1';
_d['TEST1:2'] = 'val2';
_d['TEST1:3'] = 'val3';
{dialog.object}.prepare();
{dialog.object}.populate(_d);
{dialog.object}.refreshClientSideComputations();

%txt%

e.javascript = js

On save, I would typically handle something like this manually as well, create an xb function to write the rows back to the db.
Definitely more work, but keeps your db clean.

[lvasic]

Re: Design help needed

I would use a grid and a batch process. Then when you process the batch if there are records you don't want you can delete them. My experience with the repeating section is that it is not robust enough and there is too much overhead. I just rewrote something recently taking it out of the repeating section and back to a grid. I feel like I have more power and flexibility in a grid. (There's my two cents of experience)

[RichCPT]

Re: Design help needed

Is the number of item types so small that the user is really going to be able to enter all the inventory counts at one time? What if the user isn't able to enter all the counts at one time and wants to save what they have entered and then come back later to enter more item counts?

[Al Buchholz]

Re: Design help needed

This screen is for entering inventory counts, so I need the items listed in a grid type format, enter the current count, then save all rows as new record in history table.

While that sounds like a good idea, an inventory management person or auditor would reject that idea as bad practice.

Too easy to just enter the current count.

[Scott Emerick]

Re: Design help needed

Thank you all for your input ...

Steve - That's the way I thought about going since I am dealing with a unbound format using a UX and repeating section, was just trying to see if there was a simpler way.

G - That's way too much to maintain but thanks for the thought

Nate - yes I agree with you and think the repeating section is probably the best.

Lee - I agree with you as far as the grid vs. repeating section, but it just might be easier to use the unbound UX in the long run.

Rich - Yes the item list is small because it is broken down into categories hence why I said I need to populate it dynamically.

Al - I totally agree with you, but this is what the client is used to with there access system that I am converting, soooo, I'm kinda stuck doing it there way. You know how that goes.

Thank you all for your thoughts and input, it was the nudge I needed.

Scott

[ecalan]

Re: Design help needed

Scott, I think you have some great suggestions and just thought I would add a little to the mix. This is an interesting problem as you want to populate the grid/list/repeating section with data from a table different than you are saving to. Here are my additions to the mix.

1. Use 2 list controls - one bound to the inventory items and the second bound to inventory history. Use an unbound textbox for the count. Then use Javascript to copy the record from list 1 to list 2 adding the data from the unbound box to the count field in the new record for list 2. Selwyn did some videos on moving rows from list to list which should be helpful. List 2 would not even have to be visible in the final published version and the saving after move could all be handled by script.

2. If the inventory is simple as you said, an easy solution would be to use a gridlist/list/repeating section bound to the history table and populate the item fields with dropdowns or lookups bound to the item table.

3. I am not an SQL expert, but I believe you could also populate directly from the history table with "select unique" incorporated into the query (the way dorpdowns work). Of course, you would have to add a way for new inventory items to be added to the history table but it should not be to difficult to incorporate an "initial count" action (which could be 0). The Javascript for the save function would include adding a new record with values taken from the row and then saving that record.

[Scott Emerick]

Re: Design help needed

Eric,

Thanks for your thoughts. I wish it was as simple as binding to the history table, but A) what if the table is empty? and B) the goal is to create new records, so where binding would help populating, I would still need to write code to create new records.

I am talking with my client to see what their needs really are and maybe I can take a different approach then what they are used to.

Thanks again

Scott

[ecalan]

Re: Design help needed

Another idea:

Use a UX bound to the history table set to New Record. On the component place a list bound to the items table. On select for the list use setValue to fill the fields on the component for the history table which will leave the count field empty for filling.

Sorry, I like these little puzzles.

[ecalan]

Re: Design help needed

The empty history table issue is why I suggested setting an action to add an "opening entry" action to add to the history table that could even have a 0 count value. But, I think you are correct and the manipulation of the new record row in this scenario might not be simple.