NYCPHP Meetup

[charles at softwareprototypes.com]

Until we get IPv6 and a client's IP address can be used as a  session
ID, YES, just pass the session ID and ONLY the session ID in a hidden
variable.

If the field coming in is isEmptyOrNil, you initialize the session
objects, the state machine and context objects. If the field
isNotEnptyOrNil, you load that session's context data from storage
(files are fine but it may actually be faster to bind to a database
and load an XML object since the previous session values may still be
in the database cache pool.)

Saving to a data store (file or data base) is performed using values
saved in the session context and NOT from what ever's coming from the
client machine. 

The GUI state machine must validate all incoming data and transfer it
to the 'context state' data store. From there it can be transferred
to a persistent data store (file or database.)

This state-store mechanism makes reestablishing the session and the
dialog trivial. This also allow the implementor to break the
conceptual link between a user session and the dialog flow. 

The page you're dealing is only the page you're dealing with. It is
only a part of a larger GUI state machine procession context which
itself is a part of a dialog flow within a dialog state machine.

Wheels within wheels.

This is how it is done on mainframes to reestablish context, maintain
run-units aka units-of-work, and it also allows you to apply error
security and recovery to whatever granularity you wish/need. It also
allows for secure call-back mechanisms, run-unit ownrship transfer
(to switch or prevent the switching betwen client machines,)
two-stage commits, logging and recovery (just store the stats machine
objects with versionning information.)

On (re)entry you (re)establish your GUI ans context variables and
jump to the appropriate position in the GUI state machine aka call
the appropriate function call /application object message send of the
GUI event loop.

Just because you're working in php doesn't mean you don't have an
event loop for your application.

-Charles-A.

---- Original Message ----
From: ejp at well.com
To: talk at nyphp.org, 
Subject: Re: [nycphp-talk] PHP Object handling. A rant.
Date: Sun,  2 Jun 2002 01:45:10 -0400

>O gosh, just pass the value in a hidden field. It's fool proof right?
>
>:-) e
>
>
>
>charles at softwareprototypes.com wrote:
>
>> Object oriented systems are notoriously hard to debug.
>> 
>> Smalltalks have excellent interactive debugging but that only works
>> if the IDE is present. On packaged apps. you don't ship the IDE. If
>> you do, the footprint becomes huge and your users have to be
>> Smalltalk developpers who know what to do with a Walkback Window.
>> 
>> The only ones who have a decent handle on the process are IBM with
>> VisualAge Smalltalk which is the same thing as saying OTI's
>> ENVY/Developper which is the engine. The entire stack and all 
>objects
>> in RAM are serialized and streamed to a file when an application
>> crash occurs. That's a lot of over-head for a crash and those files
>> are huge and buggers to work with without the specialised tools.
>> 
>> What he's bitching about though, is the stateless nature of the web
>> and the fact that the entire system and the application that he's
>> working on has to be designed as a state machine which is forced to
>> recoved its relevant state information at every invocation and 
>which
>> has to stuff its state information at every exit.
>> 
>> I say he's got it easy compared to programming in CICS or IDMS-DC
>> where the problems of releasing every resource between invocation 
>are
>> compounded by a limit of 32k-words of memory per process.
>> 
>> Read a "Programming in Command -level CICS COBOL" for an
>> appreaciation of the problem.
>> 
>> His beef has dick-all to do with object-orientation and everything 
>to
>> do with the fact that he doesn't know how to implement a state
>> machine or handle dialog flow.
>> 
>> Ripping out the object-oriented code won't help him. His problem is
>> that he's not thinking in objects so his logic flow is spanning
>> object methods and he doesn't know what to do.
>> 
>> State machines are perpendicular to structure in the same way that 
>a
>> mobile is perpendicular to its hanging three dimensional structure 
>or
>> that a true aquatic ballet is perpendicular to the position of the
>> swimmers in the pool. If you only look at the surface, you're 
>missing
>> the true dimension of the problem and can't get the point of the
>> exercise.
>> 
>> The GUI is a state machine but only for the GUI. The rest of the
>> objects implement their own state machines as required.
>> 
>> To wax poetic, as I once did in "The Hot-Line on Object-Oriented
>> Technology" software development is like choreographing the dance 
>of
>> electrons in n-dimensions. This poor flat-lander has two left feet.
>> 
>> -Charles-A.
>> 
>> 
>> 
>>>From: Jerry Kapron <jkapron at NewAgeWeb.com>
>>>Organization: New York PHP
>>>Reply-To: talk at nyphp.org
>>>Date: Sat,  1 Jun 2002 01:25:48 -0400
>>>To: NYPHP Talk <talk at nyphp.org>
>>>Subject: [nycphp-talk] PHP Object handling. A rant.
>>>
>>>Is it really that bad? ->
>>>
>> http://www.itchyfeet.org.nz/local/phprant.php
>> 
>>>