NYCPHP Meetup

[Rudy Gamberini]

Hans,
Was it by design that you picked db interaction (Model), Browser interaction
(View), Application logic (Controller).  Sounds a lot like MVC architecture.

I have been building dynamic sites for a while now and have been use MVC as
my approach. It is implement via three state machines, Business State
Machine (Controller), Forms State Machine (View) and a Message State Machine
(not part of the MVC).  Underneath it all is the database which goes almost
without saying (Model).

I been using NetObjects Fusion as my html tool of choice and it has provided
a framework that is very object like.  Hardly ideal but workable.

I try to be as object oriented in my approach as possible meaning that most
visual objects carry with them their behavior.  As the business state
changes the objects respond accordingly either by making themselves visible
or changing configuration.  I have found that by focusing my design to
individual objects, the implementation is greatly simplified.  While a
complex page may consist of many individual objects they are all being
driven by the business state machine.

Just food for thought.

Rudy

-----Original Message-----
From: talk-bounces at lists.nyphp.org
[mailto:talk-bounces at lists.nyphp.org]On Behalf Of Hans Zaunere
Sent: Monday, September 08, 2003 11:23 AM
To: NYPHP Talk
Subject: [nycphp-talk] Development methodology WAS: why does
setcookiefail?????




Chris Shiflett wrote:

> --- Adam Maccabee Trachtenberg <adam at trachtenberg.com> wrote:
>
>>But seriously, my suggestion is whenever you're getting frustrated
>>to take a deep breath, a five minute break, then come back and put
>>together a step-by-step list of what you're trying to
>>accomplish. Once you're armed with a list, you can then verify that
>>each step is getting the correct input and providing the correct
>>output. Often times, merely the process of figuring this out will
>>trigger what you should do to fix the bug.
>
>
> This is great advice. The setcookie line of questioning perfectly
illustrates
> why erroneous assumptions can make simple problems into very complex ones.
>
> For example, consider this calculation:
>
> (25 * 4) * 10
>
> There are basically three pieces of data here that are combined together
in two
> operations to produce the final output. Now, consider this question:
>
> Does anyone know WHY I can multiply 100 by 10 and get 1250??? See if you
can
> explain THAT one!!!
>
> After scores of messages back and forth, it is realized that the error was
that
> the following calculation was actually being performed:
>
> (25 * 5) * 10
>
> So, if the question asked had been why 5 was being returned by something
> instead of 4, the answer would have been much easier (and less
misleading).
>
> Breaking things down is essential to solving problems. This should have
been
> the first test to prove the assumption wrong:
>
> 100 * 10
>
> This would have given 1000, not 1250, so the erroneous assumption should
never
> even be mentioned in the question. A little effort up front can save a lot
of
> time for everyone.
>
> Hope that helps.

This is great stuff.  Let's get something like this formalized and added
into the Fundamentals website, alongside the Ten Commandments.  Website
development is unqiue, in that there are several very seperate, yet equally
vital, parts of the equation (for example, browser interaction, DB
interaction, and application logic).  If any of these are broken, the whole
system breaks, yet it can be difficult to know where the problem stems from.

H

_______________________________________________
talk mailing list
talk at lists.nyphp.org
http://lists.nyphp.org/mailman/listinfo/talk


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 8/19/03

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 8/19/03