One of the first things I noticed when using a Web Browse with NetTalk, is that locators don't work very well. At least, they didn't work the way I wanted them to. What I decided I really wanted, was for my end-user to come to the page with the browse, enter in some search criteria, then have the browse filtered on that criteria. So for example, if I had a customer list, rather than display the customer list as a browse first, I would present them with a screen of searchable fields that they could fill in, click "Find", then display the browse using their entries as a filter.
For an example of this, go to
http://connect.gopositive.com:4155 login is demo password is demo . Click on the Customer List tab. First you will see a list of searchable field. Type "jane" into the first name field, or "john" into the last name field and click "Find". The next screen you see will be the filtered list. Here is the trick... this is all done with the same procedure!
So, here is how it is done.
First, create a NetWebForm procedure. I called the form CustomerFramingForm. This will serve as the container for the searchable fields and the browse. Set the Form Style however you want (I used "Tab") and the Form Source as "Memory".
On the Fields tab, click Insert and set your Tab Heading as desired. I used 'Customer'.
Next you will create several local variables that will hold your searchable fields. Here is a screen shot of the fields you saw on my customer list:
The fields from l:Account to l:EMail are the search fields. They are used to build the filter that is used. I created another local variable called l:Filter2 to hold the filter based on what is filled in. I then use l:Filter2 as a condition to show or hide fields on this screen. If l:Filter2 is blank, then you will see the search fields. If it is filled in, then you won't see these fields. You could not have this condition, and always display the search fields if you want.
The Query and l:Reset fields are Submit buttons. The l:Reset button is hidden if the l:Filter2 is blank, and displayed if it is filled in.
Here is how the Query button prompts are filled in:
Notice that the URL will call the SAME PROCEDURE that I created. Here is how that is possible.
At the top of the procedure in the embed "Procedure Setup", the following code is added:
l:Filter2 = p_web.GetSessionValue('CustomerFilter')
IF p_web.GetValue('cusaccount') <> ''
p_web.SetValue('l:Account',p_web.GetValue('cusaccount'))
l:Filter2 = ''
END
IF l:Filter2 = ''
IF p_web.GetValue('l:CompanyName')
l:Filter2 = CLIP(l:Filter2) & ' AND CUS_NAME LIKE <39>%' & p_web.GetValue('l:CompanyName') & '%<39> '
END
IF p_web.GetValue('l:Account')
l:Filter2 = CLIP(l:Filter2) & ' AND CUS_CustID LIKE <39>%' & p_web.GetValue('l:Account') & '%<39> '
END
IF p_web.GetValue('l:FirstName')
l:Filter2 = CLIP(l:Filter2) & ' AND CUS_Fnam LIKE <39>%' & p_web.GetValue('l:FirstName') & '%<39> '
END
IF p_web.GetValue('l:LastName')
l:Filter2 = CLIP(l:Filter2) & ' AND CUS_LNam LIKE <39>%' & p_web.GetValue('l:LastName') & '%<39> '
END
IF p_web.GetValue('l:Address')
l:Filter2 = CLIP(l:Filter2) & ' AND CUS_bad1 LIKE <39>%' & p_web.GetValue('l:Address') & '%<39> '
END
IF p_web.GetValue('l:Phone')
l:Filter2 = CLIP(l:Filter2) & ' AND CUS_phn1 LIKE <39>%' & p_web.GetValue('l:Phone') & '%<39> '
END
IF p_web.GetValue('l:Email')
l:Filter2 = CLIP(l:Filter2) & ' AND CUS_EMail LIKE <39>%' & p_web.GetValue('l:Email') & '%<39> '
END
p_web.SetSessionValue('CustomerFilter',l:Filter2)
END
So what is happening here?
l:Filter2 = p_web.GetSessionValue('CustomerFilter')
First, we check to see if a SessionValue containing the filter is already set. Why? This allows us to move to different pages but still maintiain our filter.
IF p_web.GetValue('cusaccount') <> ''
p_web.SetValue('l:Account',p_web.GetValue('cusaccount'))
l:Filter2 = ''
END
This looks to see if the value "cusaccount" is being passed in. We have some invoice history screens that show the customer name on it. You can click on the name, and it will bring you to this page. This allows us to lookup the customer and display them (the account number is unique).
IF l:Filter2 = ''
IF p_web.GetValue('l:CompanyName')
l:Filter2 = CLIP(l:Filter2) & ' AND CUS_NAME LIKE <39>%' & p_web.GetValue('l:CompanyName') & '%<39> '
END
etc...
This is where the filter is built. l:Filter2 will be used later on where PROP:Filter is set.
p_web.SetSessionValue('CustomerFilter',l:Filter2)
Finally, this sets the SessionValue so we can go away and come back later, and still have the same customer filter. It is also passed on the the CustomerTable procedure (the actual customer browse we are going to filter).
That is all the code necessary for the CustomerFramingForm.
You may have noticed that there is a Browse called CustomerTable also in this procedure. It is hidden if l:Filter2 is blank, and visible when it is not.
In the CustomerTable procedure, all that is required is to retrieve the filter we have just built, and apply it. This code is added to the "Procedure Setup" embed:
l:Filter2 = p_web.GetSessionValue('CustomerFilter')
IF l:Filter2 = ''
packet = '<H2>Enter your customer search criteria and click "Find".</H2>' !'<!-- Net:NoQuery --><13,10>'
do SendPacket
Return
END
And finally, at the Start of "Browse Filter" embed:
l:Filter = CLIP(l:Filter) & ' ' & l:Filter2
ThisView{prop:Filter} = CLIP(l:Filter) & ')'
(I created another local variable here called l:Filter, because there is some additional filtering that we do with that variable. You should just construct the filter as your needs require).
Phew, almost done! How do we clear the filter?
With the "Reset" button from our CustomerFramingForm. This is set up as a Submit button, and calls another Form procedure (in this example, "CustomerResetForm".
This is poorly named on my part, as it is actually a NetWebPage. I added the following code right before "do Footer" using the Embeditor:
p_web.SetSessionValue('CustomerFilter','')
packet = clip(packet) & '<!-- Net:CustomerFramingForm -->'
DO SendPacket
All this does, is clear the session and call the CustomerFramingForm again. Since the session is cleared, the filters are blank, and the searchable fields appear again. Remember, you don't have to hide the searchable fields. In fact, if you look at the Inventory List in my sample web app, you can see that the fields are there all the time.
OK, so that is ONE WAY that this can be done. I have an idea for another way that will allow you to create one procedure that can handle all of your Queries for different browses. I'm still playing with that though, so I will share those ideas with you another time!
Let me know if you have any questions, or if you have ideas for improving this technique!
Topic: Advanced Searching with NetWeb Server (Read 20078 times)