Re: [Phrame-devel] Actions/Forms in original Phrame code

[Arnold C. <arn...@ya...>]

--- Tony Bibbs <to...@to...> wrote:
> I am going back and rethinking what was said about
> actions and I have a 
> few questions.  In my scenario, actions (views or
> commands), work 
> independent of the controller.  In fact the
> controller marshalls the 
> creation and execution.  So why in Phrame does the
> action have a reference 
> to the controller?  To me that breaks the basic OO
> rule of encapsulation.

The intial intent of holding a reference to the
controller was so that planning could begin on
management and configuration objects that could
manipulate mapping information on the fly.  These
services would have been something like "priviledged"
actions.  I never really got too far into this so
removing the circular dependency is probably a good
idea seeing as the current php implementations don't
handle circular references well.

> Now for the forms.  Why is validation done at a
> 'form' level?  My problem 
> with this is say you have a 'article' object. 
> Articles can be submitted 
> by normal users and also by administrators but the
> access they have to 
> specific properties may differ.  Thus you may have
> two different forms, 
> one for the user view, one for the admin view.  In
> the Phrame model, you 
> would have to code similar validation logic into
> both forms, right?  In 
> the code I built validation is just another command
> which is completely 
> reusable.

The forms were designed to be containers for form
data.  Therefore, permissions and such could either be
handled in the validate() method of each form or in
the action.  In either case, the validation could be
abstracted and shared if more than one object needed
to perform certain types of validation (similar to the
validator plugin for struts).
 
> You know, the more I think about it, the more I see
> remakable similarities 
> in the two code bases and  while you guys where
> questioning 
> fundamental differences in the designs, the more I
> think about it I don't 
> see how they differ that other than in the names of
> some of the classes 
> (i.e. semantics).

I agree that the designs are similar, however, I don't
consider big changes such as these semantics.  There
will be a bit of work porting existing phrame
applications to this new phramework.  I think we
should minimize api changes if possible and make the
required changes worth the work (and I think they
will).

> Don't read into this too much, I'm still committed
> to reworkign some of 
> the code per your suggestions but the action object
> in particular is one I 
> don't see a huge value in as that is covered by my
> command object (similar 
> methods).
>
> Also, have you thought about modifying the actions
> so it separates post 
> requests form get requests?  I ask because it is
> quite feasible that an 
> app would not want to process an get requests and in
> both packages there 
> is no distinction since the $_REQUEST superglobal is
> used.  

I can see where not being able to determine the
difference between get/post could be a problem.

> 
> -- 
> Tony Bibbs          "I guess you have to remember
> that those who don't
> to...@to...  hunt or fish often see those of
> us who do as      
>                     harmlessly strange and sort of
> amusing. When you  
>                     think about it, that might be a
> fair assessment." 
>                     --Unknown
> 
> 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
>
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Phrame-devel mailing list
> Phr...@li...
> https://lists.sourceforge.net/lists/listinfo/phrame-devel

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