How to combine three methods into one?

Greetings mates,
I have three methods:
- A search method has control ID of btnSearch that searches the database. If record exists, load the form with the records. If no record exists, present a blank form for inserting records. This works perfectly.
- The second method called btnPreview which I get help with here, allows user to preview the records whether this is a new record or existing record before submitting to the DB. Again this works very well.
- The third method called btnSave is intended to be used to submit all the previdwed records into the database.
My doubt is how to I integrate all three methods and get them to go from search method to preview method to submit method. Can all three be combined into just one, if yes, how?
I don't believe I need coding assistance here; just how to approach this.
Just to add to the three bulleted items above, in the preview method, I have another sub called fillSummary().
Private Sub FillSummary()
lblNumbersUpgraded.Text = ddlNumber.SelectedValue
'rest of the form fields
End Sub
This is where the form fields data are previewed for accuracy.
Then on btnPreview() method,
Protected Sub btnPreview_Click(sender As Object, e As EventArgs)
FillSummary()
End Sub
Many thanks in advance.
Hi @Reza Aghaei ,
Sorry about the confusion.
I am not seeking coding suggestions.
More or a process flow suggestion, I think.
Ok, let me try to clarify as much as possible.
We have a search method, btnSearch(..)
This method queries the database for records. Our department receives requests regularly and each request is stored on the DB for future references. If not, the user then stores the request as new request.
Though this is not the entire code because it is long but it has been tested and works well. My problem here is that this method just does a search only.
Then there is a Preview method.
Protected Sub btnPreview_Click(sender As Object, e As EventArgs)
lblPreviewApplicantName.Text = txtApplicant.Text
//more code
End Sub
This works fine as well.
Finally, those records will need to be inserted back into the database using Save method
btnSave_Click(...)
//code
End Sub
My question is, is it possible to merge these methods into one?
For instance, search for existence of records, if exists, update the records, If not, insert into the database. However, before inserting or updating, preview the records first.
I can write code that does all of those but how can I combine all three separate methods into just one?
I hope this is clearer.
Hi @Simflex
It is achievable.
First, you upload the data and then compare it to the database. If record exists, load the form with the records. If no record exists, present a blank form for inserting records.
Finally, save to the database.
If you have more details you would like to share, you can leave a comment below.
Best Regards
Qi You
@QiYou-MSFT , I don't think I am explaining myself well.
Currently, everything you described is working for me.
My code can query the database, If record exists, it loads the form with the records. If no record exists, presents a blank page. I can also preview the records. The issue is all of this is happening in ONE form. I cannot submit the record without querying the database again because the method to submit the data to the database is different.
I need to be able to query the db, if record exists, modify, preview submit.
If no record exists, insert, preview, submit. How do I do all of this in ONE method, where user enters search parameter, search db and perform all the steps described above and submit the record?
It sounds like multiple postbacks are needed to performs these tasks. If multiple postbacks are needed then it is logical to break up the logic into multiple methods. From a design, testing, and maintenance perspective, methods should perform one specific task not multiple tasks. However, one method might call several other methods.
What seems a little odd is preview and submit. If you are using standard Web Forms patterns, then a postback is need to preview user data and a postback is needed to save/update user data. That's at least two button clicks.
@AgaveJoe , thanks always for your response.
I am using standard webform with Panel control to divide the pages into sections.
The Search as indicated, loads results as well as open new blank form into one Panel.
The Preview section is also control by another Panel.
Right now, I am testing using a third section for the submit to see if it works.
By the way, all your assistance has helped get me to where I am so far.
Thank you.
May I ask, why exactly do you feel the urge to handle all three separate tasks from withing one method?
Some of you guys are not even reading my questions.
I do NOT have the urge to use three separate tasks.
I am here asking for help with what the approach is.
Sign in to comment
1 answer
Sort by: Most helpful
Ok, I actually think that "one" UI is fine here. But there is a bit of confusing:
Hum, above is not clear. You search for some record, and say pick the one you want. You then display that record for editing. But "then" you use the term "records" ????
so, it not clear how we gone from a record to now the term records???
Perhaps this is a type of invoice, where we have say a parent record (the invoice information), and then say some child rows of data that makes up the details of that invoice?
But this "context" flip in your narrative from I find or display a record, and then go on to say you THEN display records? Don't you mean you display the one record? (so, it not clear how we gone from "a Record" to now "records"? That's just not clear.
And I think where things are falling apart here?
You say you search for a record, and if not found, then show a blank record for editing. That is VERY rare of a UI. since what happens if I miss search, then why would I display a blank record for editing when I really just want to search again?
it seems to me, that just about "every" system I ever used has some type of search, then display results.
However, if no results, then user can search some more until they find what they are looking for. However, say they don't find, or can't find? Then you have users just hit a handy dandy add button.
The result?
Both the "view to edit" and the "add to edit" will result in BOTH cases me winding up on the SAME page to edit that information (either blank or new). As a result, the UI is 100% consistent here, but more important the code behind to edit that "existing" record can and will thus display the SAME ui choices.
Say:
So, now, the operations are combined, but only difference is we don't out of the blue toss the user into some blank edit for JUST because their search failed.
So, the classic edition loop (for just about EVERY system from accounting to whatever system I have ever used) is thus:
of course, in above, we also have a "add" button. The add button will simple jump to that edit page, and thus again allow the SAME ui to edit the one record, and the save button in effect is really a "add new record + save". But, the users tend not to think that way.
Give this sample link a try. It is ONE page to edit some sample data:
http://www.kallal.ca/WebSite11/WebForm2
I used a pop up to edit, but there is no reason why I could not just say "hide" the grid" when editing, and re-show the grid when the user exits out of the editing.
So, in the above example, note how the SAME code and more important the SAME UI exists for a add new record, and that of a edit existing. I don't have 2 sets of code here. The same code used to save a record is used in both cases. (it checks for a database PK id, and if "0", then I add this record as new.
so, I still might not be grasping your issue, but give the above edit a record example, it might give you some ideas.
@Albert Kallal , thank you very much for your response.
In one of my posts, I indicated that I am using Panel control to divide up the sections.
It is kind of like using Multiview control where each view performs a certain function.
In my case, I am using Panel with some ajar modal extender where I use something like Installation.show() or Installation.Hide depending what that panel is doing. So, everything is on ONE page.
This is what got me to come here and ask if this is the best approach or there is a better approach.
Now, to address your question about search.
I think this common practice, though handled differently by different developers.
In my case, there is a search box.
If for instance, you enter a value into that box and hit the search button, if the record associated with that search exists, the values will be loaded into one of those panels.
If the value does not exist, then we can confidently assume that there is no record for that parameter you searched with. Therefore, the user is sent to a blank form to create a record for the account.
In each instance, whether it is an existing record where user can make changes if s/he wishes or a new record being created, there is a preview button. You click that preview button, you get to review either the new record you just created for accuracy or existing record you just modified before submitting back to the database.
Hope this explains it better.
Ok, but at the end of the day, giving a user a add button seems to quite much resolve this issue. I mean, say even on this forum, or any system? When the search fails, it don't jump to you adding some new record. The user should decide and make that choice. And as I noted, looking at my UI example, there is thus no confusing as to what some blank area of the screen is for, since we don't show nor have that area anyway. And I would assume that such a design should allow for multiple search results. once again, no need to chew up valuable screen space with some blank record area - the user then has multiple choices for a given task in view at the same time - and that tend to lead to confusing.
As noted, just about every system from accounting systems, or whatever? They tend to let you search. And in fact a good UI will encourage users to search first, and try a few times to find what they are looking for (that way you don't encourage users to just start adding records - and that tends to make users enter records and data that already exists. So, from a "human" engineering point of view, make the searching the most easy, and give that option to the user first. Don't display some area to add new records, and besides, why waste that screen real estate. The less UI choices at once, including some blank areas to add new records tends to "encourage" users to enter data anyway.
Let me or the user decide that they want to add a new record. Users can't edit any data without first finding such data. Thus, it stands to reason that you give users a great search UI, and it one that most will spend the whole day in using for their given task.
And regardless of the above? As you can see, the example I have combines the same search, edit into one process and adding ALSO then becomes the exact same UI, and that once again allows the users to develop "memory" muscle so to speak.
As always, there are many ways to approach this, but if you given that example a try, you see how there not a difference between editing a record or that of having added a new one - the UI and process is 100% exactly the same to the user, and that reduces learning curves.
And the huge bonus? the same code that edits the record is also used when adding the record - so you save developer cost and time.
As noted, you looking for some ideas here, and the UI example I presented is one such approach and example. There really no one way to do this, but the above UI is one I used for 20+ years, from desktop to web based - it never really changed.
Search, view list of matches, edit, and then you back to that search results. And bonus is if say they need to work on some city or some area, they can filter, get the results, and thus this supports good "work flows", since a user can work on a "set" of filtered data, or maybe even their pending jobs. So, my solution to combine the edit, and add new has been to simple have a add new button, and darn near 99% of software I used works this way anyway, so you not surprise your users with such a UI.
If you have say an example of software or a system that worked the way you suggest, them I am all ears? (I can't think of one). And I would be hard pressed to re-write the over 30+ years of looking at basic CRUD operations in our industry. They all tend to work quite much like the UI example I posted.
I not really sure any re-invention of the wheel so to speak can occur here, but I would just look at some existing software systems you used. They may not be always the best way to do things, but they certainly are not going to surprise any user of such software, since everything else they used will tend to work the same anyway.
@Albert Kallal , this is very nice!
I tried clicking it yesterday but it would not load. I had to copy the URL and opened it in a new browser. The UI is awesome.
Can I have sample code?
Sure, I have to post it some place. But, I have to figure out a way to "include" the database. I suppose I could re-write the code to "attach" to the local database. Busy day, but I'll post back here when I have a url. I did use/create a user control for the popout editor, but it not really anything special. What I consider "gold" in that example is the 2 routines I have called fWirter, and fLoader. They automatic map the table to the form controls - so I never have to re-write that code again to display and edit any record on a form - it all automatic, and can be used for any record editing, not just that example.
Thank you so much.
If you need email address if that helps, please let me know.
@Albert Kallal , please don't forget about me sir.
I know this is a huge favor.
I thank you very much for your assistance.
Ok, I had wanted to "clean" up the example. I also wanted to document a few of the routines. As noted, that "really" useful bit of code is the fwriter, floader, and MyRst, MyRstP, and one called save table. These routines are "general" and save boatloads of code.
And I wanted to provide the data. Right now it wants sql server, and I wanted to just push everything out to sqlite. that way, you could have downloads, hit f5, and it would "just work" and run. As it stands now, you have to "jump" into a ocean of code so to speak. This might be more harm than help.
However, I am just WAY too pressed for time, so I just pushed it up to git-hub - the whole project. I do use git hub a lot, and it certainly a easy spot to park for the time being.
Download the zip file version. It is full of ideas, but without a "guide book", I am not really sure it will be all that much of a help.
I would suggest you check our the web form called "GridWihtoutCustom", since it does not have the hotel part as a user control. The user control was a "proof" of concept. that whole example is just scratchy test code. Anyway, the the link is here for you to download.
https://github.com/kallal/WebSimple.git
Oh ok.
Thank you very much anyway.
Well, there is really nothing special in that code. I created a gridview (used the wizard). then simple added a style to the button. The rest is just plan jane code, and a simple edit button with some plain jane code to launch the pop dialog.
The only "extra" part was adding the jQuery.UI pop dialog.
So, no, there was nothing special in that code, and never was. That example is quite much typical of any UI one would adopt and make up all the time.
As you noted, your just fishing for some ideas - and that "quickly" cobbled together example was in fact something I made for another post.
I mean, there are "many" ways to approach such editing problems, and that gridview example is a typical approach to "edit" of data.
However, there are some "gold bars" in that example, and I think the most useful gold bar is those routines that shuffle data from the controls to the database. That code is beyond handy, and note how little code the actual page has as a result. These ideas and concepts will bear fruit for years to come.
In other words?
Are people actually still hand coding the movement of data to the controls? That is simple too much work, so those "helper" routines that do this are of great value (since they can be used to help editing of any data). But, other then those routines, the simple GV and edit? Nah, nothing special at all, and the "ideas" by seeing the posted animated gif was more of value here.
This is more about "concpets" then some bit of code posted.
It was fun to make that example. Only "down side" here is that I did not include the database. I can if you wish post a copy of the database (say as a zipped .bak file) into that simple example if you wish. It only 3 tables anyway - busy day, but I'll post the database as a .bak file tomorrow.
@Albert Kallal ,
Thank you so much Albert for this.
For some reason, I did not get an alert on this message.
Sign in to comment
Activity