Re: [Phrame-devel] MVC sample application

[Tony B. <to...@to...>]

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
> 
> --- Tony Bibbs <to...@to...> wrote:
> > On Sat, 22 Mar 2003, Jason Sweat wrote:
> > > require_once('config.php');
> > > require is a directive, not a function, so
> > > require_once 'config.php'; 
> > > is better form, mentioned in the PEAR coding
> > conventions as acceptable either
> > > way, but I have been dinged in professional
> > writing elsewhere for including the
> > > parens.
> > 
> > I made this change, thanks for pointing it out.
> > 
> > > 
> > > $_CONF is a bad name for a variable.  It looks
> > like a superglobal, but clearly
> > > is note.  It also ad-hears to the PEAR coding
> > conventions definititions of a
> > > define, not a global variable.
> > 
> > Actually PEAR says globals should start with
> > underscore, followed by 
> > package name followed by variable name.  Since the
> > use of $_CONF was not 
> > specific to the MVC package, rather, for use in the
> > app itself, I renamed 
> > it to $gConf for now.
> > 
> > > 
> > > If you have these constants defined:
> > > // General configuration settings
> > > define('_BASE_URL', 'baseurl');
> > > define('_MVC_BASE', 'dirbase');
> > 
> > Per PEAR coding standards all _<varname> constants
> > are now named 
> > MVC_<varname>
> > 
> > > in Controller::Controller()
> > >        $_SESSION['MVC_message'] = '';
> > > Should 'MVC_message' also be a define?  I tend to
> > like to use defines for all
> > > "magic" indexes, that way there is less risk of me
> > mis-typing an assignment
> > > index.
> > 
> > Good point, I have added MVC_MESSAGE and MVC_ERRORS
> > as constants
> > 
> > > 
> > > I would move the $configData initialization into
> > the config.php script.  This
> > > makes the "bootstrap" (index.php) file more
> > understandable, and it is after
> > > all, configuration, which seems like it belongs in
> > the "config" script. 
> > 
> > Ok, what I have done is I have moved all the config
> > data to mvcconfig.php.  
> > In preparation for XML support I have also created a
> > mvcconfig.xml.  
> > Individual apps can name these file what ever they
> > want.  Point here is 
> > you are right, the config data should be pulled.  I
> > also refactored a few 
> > things so that the ArrayLoader and XMLLoader work
> > the same.  The way I had 
> > before required unique logic in the LoaderFactory
> > which , obviously, 
> > doesn't make much sense.
> > 
> > > The discussion of the $var[foo][bar] vs $var =
> > array('foo'=>array('bar'=>...));
> > > came up on the Phrame list earlier.  I said I was
> > ambivilent then, but looking
> > > at it:
> > 
> > I too am ambivilent. I think in the end the XML
> > configuration will be the 
> > default as it is easier to read and easier for
> > developers to learn.
> > 
> > I will repost the updated code here as soon as the
> > XML configuration is 
> > working.
> > 
> > -- 
> > 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
> 
> 
> -------------------------------------------------------
> 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
> 

-- 
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