So let me see if I've got this. State machines basically follow this cycle, after an initial setup:
- Look at your state and look in a table for what to do.
- Do stuff, probably depending on input, and figure out what state to go to next.
- Transition to the next state
Now both C::A and C::P maintain state information by telling the browser "when you submit this form back to the server, come back in as state X". This is pretty much driven by the way HTTP works (the other choice is to use session ID variables and database lookups, but that tends to lead to un-web-like applications), so it's not surprising that they look alike in that respect. The difference is where in the state machine cycle the browser comes in.
C::A seems from your description to put the browser into the last step; its state machine loop would be:
- Look at your state and look in a table for what to do.
- Do stuff, probably depending on input, and figure out what state to go to next.
- Tell the browser to come back in as the next state.
- Wait for the browser
Whereas C::P seems to be:
- Look at your state and look in a table for what to do.
- Do stuff, and tell the browser to come back in as the second half of this state.
- Wait for browser
- Do some more stuff, probably depending on input, and determine what the next state should be.
- Transition to the next state
Now, from just this description I'd expect the two application frameworks to be equivalent in the sense that an application could be switched between them by renaming some states and shuffling a bit of logic. The discussion so far would suggest that there are stronger differences. I'm not sure from this description which approach makes it easier to develop and maintain applications. The C::P approach seems more in line with what I'd want to do in typical data-entry or shopping cart web applications, but I'm wary of dismissing the C::A approach just because it doesn't immediately align with my current thinking. Lots of very useful tools don't align with my first impression of the problem domain.
--
@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/;
map{y/X_/\n /;print}map{pop@$_}@/for@/
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|