Re: [Phrame-devel] MVC sample application

[Jason S. <jsw...@ya...>]

Regarding the forms, I saw them as a nice method of accessing the superglobals.
 Most of my application had a single unmodified ActionForm, and then perhaps
one or two classes with a custom way of accessing the.  In most cases these
were when I wanted to do "table at a time" rather than "row at a time" updates.
 I would have a series of key_1, val1_1 val2_2, key_2, val1_2, val2_2... posted
to the form, which would then loop over the posted inputs and assemble them
into an array for processing the updates in a loop, calling (in the update
action) the Model::Update() once of each of the key_* processed.

The thing I believe I would miss the most was Actions.  In describing Phrame to
my developers, I used the analogy that each web request is a sentence.  The
Action is the verb, the Model is the noun.  Views were a bit of a stretch in
this analogy, but I said they were "adjectives" because they described the
"Nouns" (models).  An action with a "forward" was just writing a paragraph
instead of a sentence.

So, you might have:
"UpdateContact" (verb-action) affecting "Contact" (noun-model) forwards to
ViewContactList.
"ShowView" (verb-action) affecting "Contact" (noun-model) displays the
"ContactListView" (adjective-view describing Contact-model).

This has helped my developers.  They are not very web savvy, but are good SQL
programmers.

If I am interpreting your MVC example correctly, I would have to tell them the
controller will "forward" to models, which either are the date (query the list)
or manipulate the data ("updateContact").  This feels like a big conceptual
shift from the original Phrame design.

Am I missing something?

Jason


--- Tony Bibbs <to...@to...> wrote:
> The form class probably needs to be added back in. I will work on that.
> 
> The forward could be though looking at the class definition and doing some 
> 'what-ifs' in my head I don't know how I'd ever want to extend that.  
> That's not to say that one wouldn't , I jsut can think of a good example 
> which is why I went with the KISS model and left it as an array for now.
> 
> In my implementation a forward has only two attributes, the type and the 
> name.  The paths are not necessary because those are managed by the 
> controller. Right now the types can be 'redirect', 'view' or 'model' but 
> looking at your code I will probably modify the config field so that 
> instead of [MVC_TYPE] you have [MVC_REDIRECT] and pass it a boolean which 
> your forward class does (and it makes more sense).  IF it isn't a redirect 
> you can assume the [MVC_NAME] will be the name of the next view or command 
> otherwise it will be a URL relative to the controller base URL property.
> 
> What I said probably doesn't make much sense so let me make a few minor 
> changes per your feedback and send you all the resulting code.
> 
> --Tony
>  
> On Wed, 26 Mar 2003, Arnold Cano wrote:
> 
> > I've taken a look at the code and example application.
> >   Good stuff!  I have a question however... why were
> > the forward and form objects discarded?  They provided
> > a useful abstraction that could be extended (if
> > required) as opposed to passing primitives.  It seems
> > as though we've taken a few steps back in some areas
> > and leaps forward in others.
> > 
> > Looking forward to hearing your ideas.
> > 
> > Arnold


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com