It seems you have a very difficult workflow, but have at least established how your data should look.
So, ignore the tables a little for now, try to visualise what the user will see on the screen. How would your users like to enter their data into the forms? What data needs to be entered, by whom, at what point? How will those screens look? Once you have a better idea of the workflow and how the screens might appear, you should be able to design some forms and get down to processing the data. Try sketching some flowcharts and mock-up some screens to see how the gui could work. Web2py has all the ingredients you need to split a big horrible job in smaller easier ones. It is extremely flexible for specifying queries depending on your 'decision-tree'. On May 16, 8:13 pm, Vineet <vineet.deod...@gmail.com> wrote: > Villas, > Your direction is perfect. > While programming in VFP, in some of my forms, I had designed multiple > steps (wizard). > After breaking down the form into logical steps, further breaking down > is not possible. > Let me give a concrete example here. (back end database is MySQL). > > Consider an automobile workshop for repairing vehicles. > A jobcard is prepared for every vehicle attended to. > It contains complaints, repair operations, spare parts required, > mechanic details, dates & times of vehicle in/repaired/billed/out, > etc. > These things are picked-up from their respective masters data from > separate tables. > The jobcard 'wizard' is divided into steps like 'receive the vehicle', > 'enter repair operations', 'enter spare parts requirement', > 'enter spare parts issued', 'billing', etc. > > Now, for an example, consider the step of 'enter repair operations'. > Here, the data is saved through a transaction into multiple semi- > normalised tables (e.g. separate tables for warranty repairs, paid > repairs, free-services, tax-details, mechanic details, etc.). > When a user re-opens earlier jobcard, he/she may change an amount, > delete a repair operation, add another one, and so on... > For every table, it is not possible to break-down the form in steps, > since it would become messier & impractical. > > Now I hope you can judge as to why I am trying so much to get around > the issue of handling multiple tables from a single form (or through a > step in a form-wizard). > > Should you need any other detail for helping me, pl. let me know. > In the meantime, I am figuring out how to fit Simon's idea in the app. > > Thanks, > Vineet > ===================================================
