| Re: Iterative interfacing between client and server [message #169902 is a reply to message #169896] |
Wed, 29 September 2010 17:25   |
sheldonlg
Messages: 166
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 9/29/2010 11:42 AM, Graham Hobbs wrote:
> On Wed, 29 Sep 2010 07:17:14 -0700 (PDT), Captain Paralytic
> <paul_lautman(at)yahoo(dot)com> wrote:
>
>> On 29 Sep, 04:16, Graham Hobbs<gho...@cdpwise.net> wrote:
>>> On Mon, 27 Sep 2010 07:39:07 -0400, Jerry Stuckle
>>>
>>>
>>>
>>>
>>>
>>> <jstuck...@attglobal.net> wrote:
>>>> On 9/26/2010 10:06 PM, Graham Hobbs wrote:
>>>> > Hello,
>>>
>>>> > Am still new at this, need to understand a concept before I start
>>>> > coding. While the following is an over simplification, at the moment I
>>>> > am more concerned with a) 'can it be done', b) preparing a design
>>>> > document, so ..
>>>
>>>> > 1. my website will be driven by server pgm php1
>>>> > 2. client accesses the one page website
>>>> > 3. client enters/edits data in Forms ( to be javascript edited at
>>>> > client machine) then submits
>>>> > 4. pgm php1 receives the form data, passing it to a Windows cmd file
>>>> > (calling dozens of pgms) for further processing and returning data to
>>>> > php1
>>>> > 5. php1 then returns the same page to the client with mostly the same
>>>> > Form data but with additions and changes
>>>> > 6. client views the Form data
>>>> > 7. Repeat 3 thru 7 until client happy with results.
>>>
>>>> > So is my concept:
>>>> > - feasible?
>>>> > - reflects the way it's normally done (i.e. practical)?
>>>
>>>> > Please, thanks in advance
>>>> > Graham
>>>
>>>> It can be done. I don't think it's very practical, though.
>>>
>>> ---
>>> Thanks for your answers. So it can be done but my way is not the way
>>> to go:-(.
>>> not very practical - Jerry
>>> it is a bad idea - Shelly
>>> not that this makes this idea any better - Capt Para
>>>
>>> But am not a lot clearer on the 'best way'. Simplifying I hope,
>>> suppose a user accesses my one page website, s/he sees unpopulated
>>> fields (Forms?) for:
>>>
>>> Student Number
>>> First Name
>>> Surname
>>> Faculty
>>> Major
>>>
>>> So ..
>>> 1. The user enters Student Number, clicks Submit
>>> Server uses Student Number to access an sql table
>>> Server sends page with first name, surname, faculty, major populated
>>> goto 1.
>>>
>>> Is this a practical web application?
>>>
>>> Thanks again
>>> Graham
>>
>> So you are suggesting:
>> 1) User submits a request.
>> 2) Server supplies a response.
>>
>> This is what every web page in the world does and you are asking if
>> this is a practical web application.
>>
>> I'm sure you can work out that it is.
> ---
> Yes to your 1 and 2 and is very clear. That's half of what I asked..
> What I'm asking is 'can this be an iterative transaction'.
>
> When I program CICS transactions I give the user a screen, he enters a
> student number, a CICS pgm presents the results and sends a populated
> screen; user updates some fields clicks Enter, changes are made to the
> database, the same screen is represented with an 'update successful'
> msg, user makes more changes, enter, database update, represent screen
> etc. Then user enters anew student number and the same process occurs
> (or user logs off).
>
> Points are taken with respect to logon ID/password - more scope for my
> project.
>
> OK, maybe my original question might have been 'can I pgm in
> php/html/javascript to emulate such a CICS transaction'?
> Is this what is being suggested as impractical?
I'd suggest this:
For a student:
1- Have the user log in. A successful login would bring back the
student id which you would set in a session variable.
2 - Have a link to a page to present the user information. It would
first query the database with that value for the student and then
present him with his information via html.
For faculty:
1 - The faculty member logs in and a session variable is set that
indicates he is faculty.
2 - Have a link to a page for student information. On that page what
appears at first is a drop-down list with all the student names and
empty values for all the properties. The value of each <option> would
be the students id in the student table. There would be an onchange to
invoke an AJAX call using that value of the option..
3 - The AJAX would get the information from the database and on return
it would display all the properties of the student in the proper fields.
Alternatively for the faculty, if you don't want AJAX or javascript, you
could just have have all that but no onchange. Instead, have a button
that submits it and have the submission use the value from the list to
find all the data from the database and then repaint the entire screen
using all those values as initial values.
This is rather easy stuff and you will need to get familiar with these
because they are done _all_ the time.
BTW, what I said was a bad idea was using shell functions where not
essential.
--
Shelly
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]