| Re: Iterative interfacing between client and server [message #169819 is a reply to message #169817] |
Mon, 27 September 2010 15:49  |
sheldonlg
Messages: 166
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 9/27/2010 11:22 AM, Captain Paralytic wrote:
> On 27 Sep, 15:49, sheldonlg<sheldonlg> wrote:
>> On 9/27/2010 9:03 AM, Captain Paralytic wrote:
>>
>>
>>
>>
>>
>>> On 27 Sep, 03:06, Graham Hobbs<gho...@cdpwise.net> 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
>>
>>> I'm not sure what you mean by: "to be javascript edited at client
>>> machine", but in general you are describing a pretty standard
>>> approach, until you reach the part that says:
>>> "passing it to a Windows cmd file (calling dozens of pgms) for further
>>> processing and returning data to php1"
>>
>>> It is more normal to perform one's processing in the programming
>>> language of the file that receives the form data. Running "dozens of
>>> [Windoze] programs", sounds like it could be a time consuming task,
>>> fraught with the possibilities that one of them has an error that you
>>> somehow have to handle and return to the user. It is occasionally
>>> necessary to execute a shell program, but most people try to avoid it.
>>
>> Furthermore you have the question of synchronicity. You have to wait to
>> get the response back from all of these external processes before
>> returning to the caller's page. That means you need a way to know when
>> the external process has completed. In general (with exceptions), it is
>> a bad idea.
> Doesn't that simply depend on how it is executed. Since this is a cmd
Absolutely.
> file, it suggests that the external programs will be called
> sequentially, so all that is needed it to wait for the cmd file to
Not necessarily. What, for example, if the command file being executed
has asynchronous actions? Then, even if you wait for each command to
return, you cannot be sure that everything underneath is completed.
> exit. Not that this makes the idea any better mind you!
Exactly.
--
Shelly
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]