phrame-devel

Re: [Phrame-devel] MVC sample application

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

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

Re: [Phrame-devel] MVC sample application

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

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

[Phrame-devel] Any more input?

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

Jason, Arnold...

Any more input, thoughts, suggestions?

Sorry to be pushy...same ol' time crunch.

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

Re: [Phrame-devel] MVC sample application

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

--- Tony Bibbs <to...@to...> wrote:
> Again, this is not meant to be a jab at Phrame. I have talked to Arnold 
> and I'm hoping his work, the work attached and contributions from folks 
> like Jason can be quickly be merged into the 'best-of-all-worlds' to 
> quickly produce a production quality implementation.  Again, a good 
> portion of my motiviation is time related with respects to another 
> project so any feedback you can give in the short term would be appreciated.

Notes listed here as I came across them:

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.

$_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.

If you have these constants defined:
// General configuration settings
define('_BASE_URL', 'baseurl');
define('_MVC_BASE', 'dirbase');
then why do you need:
$_CONF['site_url'] = 'http://www.example.com/MVC/contactmanager';
$_CONF['path_mvc'] = '/path/to/MVC/';

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.

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.   BTW,
I initialize a global db connection in my application_setup.php files (the
equivalent of your config.php file) so this does not seem out of place to me. 
(DB detour:
I actually insulate my developers from knowing the database passwords by
creating a function in our standard php library that returns a connected
database object from a parameter specifying the type of connection they want.)

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:
// Models
$configData[_MODELS]['validate'][_NAME] = 'ValidateContact';
$configData[_MODELS]['validate'][_FORWARDS]['showAgain'][_TARGET] = 'edit';
$configData[_MODELS]['validate'][_FORWARDS]['showAgain'][_TYPE] = 'view';
$configData[_MODELS]['validate'][_FORWARDS]['saveIt'][_TARGET] = 'saveContact';
$configData[_MODELS]['validate'][_FORWARDS]['saveIt'][_TYPE] = 'model';

$configData[_MODELS] = array(
    'validate' => array(
        _NAME  	  => 'ValidateContact',
        _FORWARDS => array(
            'showAgain' => array(_TARGET => 'edit',        _TYPE => 'view'),
            'saveIt'    => array(_TARGET => 'saveContact', _TYPE => 'model')
            )
        )
    );

Some part of the programmer in me hates seeing the _MODELS and _FORWARDS and
'string keys' repeated over and over :)  I guess it would be easier for a
newcomer to php to understand perhaps?  Everyone is free to setup the array
however they like, so it does not matter much.

It is now 11:00PM and my brain is starting to get fuzzy.  Rather than continue
line by line, I jumped back and tried to get a picture of the whole
refactoring.  One major problem I see is the removal of Actions from the
design.  I admit many of my actions are relatively trivial pieces of code that
only interact with a single model, and could thus be capture as a function of
that model rather than a separate class.  And I also can see potential
elimination of the Forms and just access the superglobals directly.  

However, I do have a number of instances where my actions access a number of
models simultaneously, and I believe your refactoring would make this very hard
to implement.  For instance, I have a 3 step "wizard".  Each step is a separate
"Action" class under frame.  Each action interacts with three different models.
 The main model dealing with the database, a second model tied mainly to the
$_SESION tracking the inputs between the steps (the "wizard" model) and a user
model to track security.  I am not sure how this would be refactored under your
MVC.

Maybe it is just me being used to seeing things in a "Phrame" format, but I am
uncomfortable seeing things labeled "delete" and "saveContact" as models.  I
see these as being methods of a Contact model, implemented through delete and
save actions.

My last initial concern is also related to changing too much from the original
Struts implementation.  Prior to discovering Phrame, I had found Struts and had
purchased a book on the subject to better understand the MVC pattern.  If I
ever decide to migrate any of my developers or projects from PHP to Java, I see
some advantage to having the PHP/Phrame familiar developers having and easier
time migrating to Java/Struts.  Perhaps this is a very minor concern for you,
but it did at least occur to me.

It looks like you have put a lot of work and thought into your redesign.  I
agree with your sentiment that we should be able to combine all our efforts and
produce and outstanding MVC framework.

Regards,

Jason

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

Re: [Phrame-devel] MVC sample application

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

--- Tony Bibbs <to...@to...> wrote:
>Again, a good 
> portion of my motiviation is time related with respects to another 
> project so any feedback you can give in the short term would be appreciated.

I was able to get the app running.  Hopefully I will have some time to look at
your changes and comment.

Jason



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

[Phrame-devel] MVC sample application

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

OK,

The attached .zip has the MVC code I was eluding to as well as a sample 
application.  The sample app requires MySQL and PEAR::DB.  There is a 
README that outlines how to install it.

Again, this is not meant to be a jab at Phrame. I have talked to Arnold 
and I'm hoping his work, the work attached and contributions from folks 
like Jason can be quickly be merged into the 'best-of-all-worlds' to 
quickly produce a production quality implementation.  Again, a good 
portion of my motiviation is time related with respects to another 
project so any feedback you can give in the short term would be appreciated.

Please note the XML configuration provided is not working yet...I will 
send an update that handle a XML config file shortly. Oh and don't flame 
me about credits to Phrame missing from the README, I'm not making this 
publicly available anywhere.

Thanks to you all.

-- 
+-------------------+--------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|to...@to... |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  | 

+-------------------+--------------------------------------------------+

Re: [Phrame-devel] Please read: MVC input sought

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

I started to reply but felt it best if I simply just make the code 
available despite not having a suitable example yet.

Here is the code:

http://cvs.geeklog.net/chora/cvs.php/MVC_Base?login=2

Sample on it's way sometime soon...

--Tony

On Thu, 20 Mar 2003, Jason Sweat wrote:

> --- Tony Bibbs <to...@to...> wrote:
> > 2) I have worked security into this MVC implementation.  Security checks 
> > are still up to the developer to implement but the default policy will 
> > be used to determine the default security policy.  If set to _TRUSTED, 
> > the default policy is to allow access to anyone.  If set to _UNTRUSTED, 
> > all models/views will have security checks enabled by default.
> 
> I don't really understand the need here.  Should the view/actions just query
> the appropriate model to determine if they should run?  For example, you might
> have a User model that would indicate if a) the user was logged into the site
> and b) if they had editing permission.
> 
> In the request to view you might:
> if (!$o_user->IsLoggedIn()) {
>    trigger_error('you must be logged in to view this page');
>    header(ERROR_REDIR);
> }
> 
> or in the action to update something, you might do
> if (!$o_user->IsEditor()) {
>    trigger_error('you must have editing rights to change this page');
>    header(ERROR_REDIR);
> }
> 
> This seems like a very application specific issue, what advantage is there to
> moving it into the framework?
> 
> > 3) A big problem with Phrame is it will load a lot of unneeded code to 
> > process a request.  Specifically, all the actions in phrame are loaded. 
> >   By using the path config information for the views/models, you can 
> > dynamically include the right code on demand.
> 
> Did you look at the comment I posted this past weekend
> (http://sourceforge.net/mailarchive/forum.php?forum_id=13113&max_rows=25&style=flat&viewmonth=200303&viewday=14)?
> In it, I documented how to have Phrame only load actions/forms/views/models as
> required.  In my case, actions include specific models that are used in each
> action, so by loading all the actions all the models would be loaded anyway.
> 
> 
> > 7) the Phrame Mappings and Forwards classes have been dropped.  Forwards 
> > are simply implemented as an array.  When a request is received, only 
> > the forwards for the model or view is loaded.  Similarly, only the 
> > mapping information for the current request is loaded.
> 
> Doesn't that eliminate the "loose coupling" advantage that copying Struts gave
> you in the first place?
> 
> > 9) Many applications output views differently. Some echo or print the 
> > HTML directly to the browser, others build the HTML in a string and at 
> > the end echo that single string.  The view implementation is a 
> > configuration setting that lets you specify which behaviour is supported 
> > and the controller will act accordingly.
> 
> This is why I think a view factory needs to be application specific as well...
> 
> Regards,
> 
> Jason
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
> http://platinum.yahoo.com
> 

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

Re: [Phrame-devel] Please read: MVC input sought

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

--- Tony Bibbs <to...@to...> wrote:
> 2) I have worked security into this MVC implementation.  Security checks 
> are still up to the developer to implement but the default policy will 
> be used to determine the default security policy.  If set to _TRUSTED, 
> the default policy is to allow access to anyone.  If set to _UNTRUSTED, 
> all models/views will have security checks enabled by default.

I don't really understand the need here.  Should the view/actions just query
the appropriate model to determine if they should run?  For example, you might
have a User model that would indicate if a) the user was logged into the site
and b) if they had editing permission.

In the request to view you might:
if (!$o_user->IsLoggedIn()) {
   trigger_error('you must be logged in to view this page');
   header(ERROR_REDIR);
}

or in the action to update something, you might do
if (!$o_user->IsEditor()) {
   trigger_error('you must have editing rights to change this page');
   header(ERROR_REDIR);
}

This seems like a very application specific issue, what advantage is there to
moving it into the framework?

> 3) A big problem with Phrame is it will load a lot of unneeded code to 
> process a request.  Specifically, all the actions in phrame are loaded. 
>   By using the path config information for the views/models, you can 
> dynamically include the right code on demand.

Did you look at the comment I posted this past weekend
(http://sourceforge.net/mailarchive/forum.php?forum_id=13113&max_rows=25&style=flat&viewmonth=200303&viewday=14)?
In it, I documented how to have Phrame only load actions/forms/views/models as
required.  In my case, actions include specific models that are used in each
action, so by loading all the actions all the models would be loaded anyway.


> 7) the Phrame Mappings and Forwards classes have been dropped.  Forwards 
> are simply implemented as an array.  When a request is received, only 
> the forwards for the model or view is loaded.  Similarly, only the 
> mapping information for the current request is loaded.

Doesn't that eliminate the "loose coupling" advantage that copying Struts gave
you in the first place?

> 9) Many applications output views differently. Some echo or print the 
> HTML directly to the browser, others build the HTML in a string and at 
> the end echo that single string.  The view implementation is a 
> configuration setting that lets you specify which behaviour is supported 
> and the controller will act accordingly.

This is why I think a view factory needs to be application specific as well...

Regards,

Jason

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

[Phrame-devel] Please read: MVC input sought

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

Folks,

I had the pleasure to pour through the Phrame code in painstaking detail 
trying to see how refactoring it might proceed.  As I spent more and 
more time I found things in Phrame that simply didn't make sense to me. 
  In the end, I took some of my wants and needs along with the good 
ideas from Phrame and did a ground-up MVC implementation.  I hope this 
doesn't appear to be a slap in the face to anyone on this list and that 
a keen eye is given to my implementation for the differences.  I look at 
what I have as a combination the good things in Phrame with a number of 
  changes to reduce the payload and complexity.

Ok, now for the notable differences:

1) config files has some basic configuration:
- $configData[_DIRS][_MVC_BASE]: This is the location of the MVC codebase
- $configData[_DIRS][_VIEWS]: Directory where views can be found
- $configData[_DIRS][_MODELS]: Directory where models can be found
- $configData[_BASE_URL]: The base URL related to the controller
- $configData[_DEFAULT_SECURITY_POLICY]: Set default policy for objects

2) I have worked security into this MVC implementation.  Security checks 
are still up to the developer to implement but the default policy will 
be used to determine the default security policy.  If set to _TRUSTED, 
the default policy is to allow access to anyone.  If set to _UNTRUSTED, 
all models/views will have security checks enabled by default.

3) A big problem with Phrame is it will load a lot of unneeded code to 
process a request.  Specifically, all the actions in phrame are loaded. 
  By using the path config information for the views/models, you can 
dynamically include the right code on demand.

4) Use of session data was completely removed. The main justification is 
not all applications will use PHP4 sessions and even then, jamming stuff 
into the session that isn't user specific is a waste of server resources 
  IMHO.

5) Forwards come in two basic types, 1) redirects, 2) model/view 
forwards.  As the first implies, URL redirects is supported and working. 
  However, often it is desireable to forward processing off to a 
different model or view managed by the current controller.  With that 
said, you can now forward processing on to another model or view 
requiring no URL redirect.

6) Refactoring, I mentioned this a few times.  I saw a need for a model 
and view factory.  Both have been implemented.  Additionally, I added a 
LoaderFactory class.  The loader factory allows for any number of 
configuration sources without requiring changes to the core code.  I 
added this after hearing thoughts on supporting XML config files.  My 
implementation will require the configuration data, regardless of 
format, to be converted into a PHP array.  Right now I have an 
ArrayLoader which is working but adding an XMLLoader is trivial at this 
point.

7) the Phrame Mappings and Forwards classes have been dropped.  Forwards 
are simply implemented as an array.  When a request is received, only 
the forwards for the model or view is loaded.  Similarly, only the 
mapping information for the current request is loaded.

8) Documentation, though not a big deal, PHPDoc comments are included 
and I will be publishing this documentation along with the code when I 
get a chance.

9) Many applications output views differently. Some echo or print the 
HTML directly to the browser, others build the HTML in a string and at 
the end echo that single string.  The view implementation is a 
configuration setting that lets you specify which behaviour is supported 
and the controller will act accordingly.

At this point I am not releasing the code until I have implemented a 
fairly 'real world' example using this implementation and generated the 
PHPDoc documentation.  I anticipate having this available to this list 
sometime in the next day or so.

-- 
+-------------------+--------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|to...@to... |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  | 

+-------------------+--------------------------------------------------+

[Phrame-devel] Phrame mods - ViewFactory, ShowViewAction

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

Hello all,

Had some time tonight to work with some ideas I have had recently.  I wanted to
modify Phrame to 
a) not have to include all the models/ actions/ forms/ and views/ directories
(to improve application performance)
b) create a view factory (each of my views is a separate class that has a
Render method that accepts a smarty object)
c) create a default action to be process if no other action was specified (in
my case, ShowViewAction)

Seems to be up and working.  Here are some of the changes I have been working
with:

to ActionController.php:
134c134
<       function _processMapping($mappings, $request)
---
>       function &_processMapping($mappings, $request)
138c138,143
<               $actionMapping = $this->_actionMappings->get($name);
---
>               if ($this->_actionMappings->containsKey($name)) {
>                       $actionMapping = $this->_actionMappings->get($name);
>               } else {
>                       $name = $this->_options[_DEFAULT_ACTION];
>                       $actionMapping = $this->_actionMappings->get($name);
>               }
155c160
<       function _processForm($mappings, $request)
---
>       function &_processForm($mappings, $request)
164a170,171
>                               //JES
>                               require_once "forms/$type.php";
189c196
<       function _processValidate($actionMapping, $actionForm)
---
>       function _processValidate(&$actionMapping, &$actionForm)
210c217
<       function _processAction($actionMapping, $actionForm)
---
>       function &_processAction(&$actionMapping, &$actionForm)
215a223,224
>                       //JES
>                       require_once "actions/$type.php";
236c245
<       function _processForward($actionForward)
---
>       function _processForward(&$actionForward)
246a256
>               exit;

to Constants.php (changed the whole file to avoid E_ALL notices):
<?php
//request contant(s)
define('_ACTION', 'action');
define('_VIEW', 'view');
//session constant(s)
define('_CONTROLLER', '_controller');
define('_ERRORS', '_errors');
define('_FORM', '_form');
//mappings constant(s)
define('_ACTION_FORMS', '_actionForms');
define('_ACTION_MAPPINGS', '_actionMappings');
define('_TYPE', '_type');
define('_NAME', '_name');
define('_INPUT', '_input');
define('_VALIDATE', '_validate');
define('_ACTION_FORWARDS', '_actionForwards');
define('_PATH', '_path');
define('_REDIRECT', '_redirect');
//options constant(s)
define('_CACHE', '_cache');
define('_ERROR_REPORTING', '_errorReporting');
define('_ERROR_HANDLER', '_errorHandler');
//JES
define('_DEFAULT_ACTION', '_defaultAction');

?>

to include.php:
<?php
require_once 'util/Object.php';
require_once 'util/ArrayList.php';
require_once 'util/HashMap.php';
require_once 'util/Stack.php';
require_once 'util/ListIterator.php';
//require_once 'ext/Xml.php';
require_once 'Constants.php';
require_once 'Action.php';
require_once 'ActionController.php';
require_once 'ActionForm.php';
require_once 'ActionForward.php';
require_once 'ActionMapping.php';
require_once 'MappingManager.php';
require_once 'ViewFactory.php';
?>

MappingManager.php was posted to the list earlier.  The new ViewFactory.php is:
<?php
/**
 *	view class directory
 */
define('PHRAME_VIEW_CLASS_DIR', 'views/');
/**
 *	class to create Phrame Mapping arrays
 *
 *	@author		Jason E. Sweat	
 *	@since		2003-01-13
 */
class ViewFactory extends Object
{
	/**
	 *	constructor
	 *
	 *	@return void
	 */
	function ViewFactory()
	{
		trigger_error("ViewFactory is a virtual class, please extend for your
application");
		return false;
	}

	/**
	 *	abstract function to return class based on view
	 *
	 *	Must be overridden in the application, should always return a valid class
file.
	 *
	 *	@return void
	 */
	function _GetViewClass($psView)
	{
		$s_error = 'ViewFactory::_GetViewClass is a virtual method, please extend for
your application';
		trigger_error($s_error);
		die($s_error);
	}
	
	/**
	 *	factory function
	 *
	 *	@return object	the view object
	 */
	function &Build($psView)
	{
		$s_view_class = $this->_GetViewClass($psView);
		require_once PHRAME_VIEW_CLASS_DIR.$s_view_class.'.php';
		$o_view = new $s_view_class;
		return $o_view;
	}
	
}

When defining the applicaiton options, I added
,_DEFAULT_ACTION	=> 'ShowView'

and my ShowViewAction is:
class ShowViewAction extends Action
{
    /**
     *    perform the action of showing a view
     *
     *    @param    object    $poActionMapping    the action mapping object
     *    @param    object    $poActionForm        the form object
     *    @return    object     ActionForward
     */
    function Perform(&$poActionMapping, &$poActionForm)
    {
	$o_view_factory = new SeiViewFactory;
	$o_view = $o_view_factory->Build($poActionForm->Get('view'));
	$o_smarty = new Smarty;
	
	//any default assignments
	
	//render the template
	$o_view->Render($o_smarty);
	
	
	//$o_action_forward = &$poActionMapping->Get('debug');
	//return $o_action_forward;
    }
	   
I hope you find some of these changes of interest.

Regards,

Jason 

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

Re: [Phrame-devel] php.MVC digester

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

Here is a good article on the digester:

http://www.onjava.com/pub/a/onjava/2002/10/23/digester.html

Arnold

--- Tony Bibbs <to...@to...> wrote:
> Ok, in that case is would seem you would need a
> simple configuration 
> factory to create right object for accessing the
> configuration variables.
> 
> --Tony
> 
> On Fri, 14 Mar 2003, Jason Sweat wrote:
> 
> > I have not yet looked at the code, but I belive it
> is just the way to take an
> > XML configuration file (for mappings, etc.) and
> transforming it into an array
> > usable by the Phramework.
> > 
> > I would like to keep this particular code (loading
> configurations) abstract
> > enough in Phrame that you could choose to get your
> configuration and mappings
> > from any source you choose: PHP script arrays,
> retrieved from a database or the
> > XML configuration file.  Phrame might "officially"
> support the XML version, but
> > it would be nice to allow a developer to easily
> switch out to their
> > configuration strategy of choice.
> > 
> > My $0.02 :)
> > 
> > Jason
> > 
> > 
> > --- Tony Bibbs <to...@to...> wrote:
> > > OK, call me the dummy, what does this digester
> stuff do.  Admittedly I'm 
> > > knew to struts and relatively so to MVC.  
> > > 
> > > --Tony
> > > 
> > > On 14 Mar 2003, Dan Loda wrote:
> > > 
> > > > In an earlier post I read in the archives,
> Arnold mentioned possibly
> > > > utilizing the digester from php.MVC. I think
> using digester would be a
> > > > good thing, though the code from that project
> is rather poor, so I
> > > > ported it myself (based on the digester
> distributed with struts-1.0.2).
> > > > 
> > > > Hopefully, when I free up some more time, I'll
> bring it up to speed with
> > > > the latest release (commons-digester-1.4.1, I
> believe).
> > > > 
> > > > I haven't fully tested it yet, but so far so
> good.
> > > > 
> > > >
>
http://webweaver.org/dan/php/digester/W2C_XML_Digester-1.0b.tgz
> > > > 
> > > > 
> > > 
> > > -- 
> > > 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:Crypto
> Challenge is now open! 
> > > Get cracking and register here for some mind
> boggling fun and 
> > > the chance of winning an Apple iPod:
> > >
>
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> > > _______________________________________________
> > > Phrame-devel mailing list
> > > Phr...@li...
> > >
>
https://lists.sourceforge.net/lists/listinfo/phrame-devel
> > 
> > 
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Web Hosting - establish your business
> online
> > http://webhosting.yahoo.com
> > 
> 
> -- 
> 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:Crypto Challenge
> is now open! 
> Get cracking and register here for some mind
> boggling fun and 
> the chance of winning an Apple iPod:
>
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> Phrame-devel mailing list
> Phr...@li...
>
https://lists.sourceforge.net/lists/listinfo/phrame-devel


__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

Re: [Phrame-devel] php.MVC digester

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

Ok, in that case is would seem you would need a simple configuration 
factory to create right object for accessing the configuration variables.

--Tony

On Fri, 14 Mar 2003, Jason Sweat wrote:

> I have not yet looked at the code, but I belive it is just the way to take an
> XML configuration file (for mappings, etc.) and transforming it into an array
> usable by the Phramework.
> 
> I would like to keep this particular code (loading configurations) abstract
> enough in Phrame that you could choose to get your configuration and mappings
> from any source you choose: PHP script arrays, retrieved from a database or the
> XML configuration file.  Phrame might "officially" support the XML version, but
> it would be nice to allow a developer to easily switch out to their
> configuration strategy of choice.
> 
> My $0.02 :)
> 
> Jason
> 
> 
> --- Tony Bibbs <to...@to...> wrote:
> > OK, call me the dummy, what does this digester stuff do.  Admittedly I'm 
> > knew to struts and relatively so to MVC.  
> > 
> > --Tony
> > 
> > On 14 Mar 2003, Dan Loda wrote:
> > 
> > > In an earlier post I read in the archives, Arnold mentioned possibly
> > > utilizing the digester from php.MVC. I think using digester would be a
> > > good thing, though the code from that project is rather poor, so I
> > > ported it myself (based on the digester distributed with struts-1.0.2).
> > > 
> > > Hopefully, when I free up some more time, I'll bring it up to speed with
> > > the latest release (commons-digester-1.4.1, I believe).
> > > 
> > > I haven't fully tested it yet, but so far so good.
> > > 
> > > http://webweaver.org/dan/php/digester/W2C_XML_Digester-1.0b.tgz
> > > 
> > > 
> > 
> > -- 
> > 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:Crypto Challenge is now open! 
> > Get cracking and register here for some mind boggling fun and 
> > the chance of winning an Apple iPod:
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> > _______________________________________________
> > Phrame-devel mailing list
> > Phr...@li...
> > https://lists.sourceforge.net/lists/listinfo/phrame-devel
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Web Hosting - establish your business online
> http://webhosting.yahoo.com
> 

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

Re: [Phrame-devel] php.MVC digester

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

I have not yet looked at the code, but I belive it is just the way to take an
XML configuration file (for mappings, etc.) and transforming it into an array
usable by the Phramework.

I would like to keep this particular code (loading configurations) abstract
enough in Phrame that you could choose to get your configuration and mappings
from any source you choose: PHP script arrays, retrieved from a database or the
XML configuration file.  Phrame might "officially" support the XML version, but
it would be nice to allow a developer to easily switch out to their
configuration strategy of choice.

My $0.02 :)

Jason


--- Tony Bibbs <to...@to...> wrote:
> OK, call me the dummy, what does this digester stuff do.  Admittedly I'm 
> knew to struts and relatively so to MVC.  
> 
> --Tony
> 
> On 14 Mar 2003, Dan Loda wrote:
> 
> > In an earlier post I read in the archives, Arnold mentioned possibly
> > utilizing the digester from php.MVC. I think using digester would be a
> > good thing, though the code from that project is rather poor, so I
> > ported it myself (based on the digester distributed with struts-1.0.2).
> > 
> > Hopefully, when I free up some more time, I'll bring it up to speed with
> > the latest release (commons-digester-1.4.1, I believe).
> > 
> > I haven't fully tested it yet, but so far so good.
> > 
> > http://webweaver.org/dan/php/digester/W2C_XML_Digester-1.0b.tgz
> > 
> > 
> 
> -- 
> 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:Crypto Challenge is now open! 
> Get cracking and register here for some mind boggling fun and 
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> Phrame-devel mailing list
> Phr...@li...
> https://lists.sourceforge.net/lists/listinfo/phrame-devel


__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

Re: [Phrame-devel] php.MVC digester

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

OK, call me the dummy, what does this digester stuff do.  Admittedly I'm 
knew to struts and relatively so to MVC.  

--Tony

On 14 Mar 2003, Dan Loda wrote:

> In an earlier post I read in the archives, Arnold mentioned possibly
> utilizing the digester from php.MVC. I think using digester would be a
> good thing, though the code from that project is rather poor, so I
> ported it myself (based on the digester distributed with struts-1.0.2).
> 
> Hopefully, when I free up some more time, I'll bring it up to speed with
> the latest release (commons-digester-1.4.1, I believe).
> 
> I haven't fully tested it yet, but so far so good.
> 
> http://webweaver.org/dan/php/digester/W2C_XML_Digester-1.0b.tgz
> 
> 

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

[Phrame-devel] php.MVC digester Continued

[Dan L. <da...@we...>]

Whoops! Didn't mean to send that last one so quick!

Both of these packages are needed (packaged with Pear):

http://webweaver.org/dan/php/digester/W2C_XML_Digester-1.0b.tgz
http://webweaver.org/dan/php/digester/W2C_XML_Parser-1.0b.tgz

I hope to contribute to this project!

-- 
Dan Loda <da...@we...>
webweaver.collective

[Phrame-devel] php.MVC digester

[Dan L. <da...@we...>]

In an earlier post I read in the archives, Arnold mentioned possibly
utilizing the digester from php.MVC. I think using digester would be a
good thing, though the code from that project is rather poor, so I
ported it myself (based on the digester distributed with struts-1.0.2).

Hopefully, when I free up some more time, I'll bring it up to speed with
the latest release (commons-digester-1.4.1, I believe).

I haven't fully tested it yet, but so far so good.

http://webweaver.org/dan/php/digester/W2C_XML_Digester-1.0b.tgz

-- 
Dan Loda <da...@we...>
webweaver.collective

Re: [Phrame-devel] Use of session...

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

--- Tony Bibbs <to...@to...> wrote:
> On Thu, 6 Mar 2003, Arnold Cano wrote:
> 
> > I do prefer having a single mechanism for handling
> > views (a special action).  I did a lot of research
> > determining if push or pull mvc would be a better
> > approach to take and found this article:
> > 
> >
>
http://www.ingrid.org/jajakarta/turbine/en/turbine/turbine-2/pullmodel.html
> > 
> > I'm not sure about the idea of combining actions
> with
> > forms.  The original idea behind keeping them
> separate
> > is that the action mechanism (the command pattern)
> > should only be concerned with handling command
> logic. 
> > Keeping the forms separate from this enabled the
> > framework to validate form data before an action
> was
> > even involved in the process of handling the
> request
> > and allowed for form reuse between actions.
> 
> I think we are arguing over semantics.  You could
> have a base abstract 
> object that both the action and form object inherit
> from.  Call it what 
> you want.  In the end, the separation you are
> seeking between the 'action' 
> and the 'form' is really more logical.  Again the
> real value is the fact 
> you now have the display portion of a view tied to
> the validation in one 
> object.
> 

Sorry, I think I misunderstood what you were
describing at first.  Please describe your idea again
so I can understand what benefits could be gained from
this.

> > 
> > I like the idea of creating a secure action.  We
> > should also create other useful base actions such
> as a
> > DispatchAction that would allow the use of ACID
> > methods in a single action through the use of the
> > _PARAMETER action mapping attribute.
> 
> Good!
> 
> > 
> > There are many places that refactoring could
> happen
> > and I agree that we should implement the use of
> > factories for the actions, mappings, forms, and
> > forwards.  The use of the session to hold the
> > controller is not required and I think changing it
> to
> > use a static variable (the singleton pattern) is a
> > great idea.
> 
> Great!
> 
> --Tony
> 

Another idea I've been tossing around is changing the
mapping associative array into an xml configuration
file for configuring the framework.  We could
implement the flyweight pattern... illustrated here:

http://www.webreference.com/programming/php/php4xml/chap10/3/2.html

We could also think about utilizing the digester code
implemented in the php.MVC project?

Arnold


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Re: [Phrame-devel] Use of session...

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

On Thu, 6 Mar 2003, Arnold Cano wrote:

> I do prefer having a single mechanism for handling
> views (a special action).  I did a lot of research
> determining if push or pull mvc would be a better
> approach to take and found this article:
> 
> http://www.ingrid.org/jajakarta/turbine/en/turbine/turbine-2/pullmodel.html
> 
> I'm not sure about the idea of combining actions with
> forms.  The original idea behind keeping them separate
> is that the action mechanism (the command pattern)
> should only be concerned with handling command logic. 
> Keeping the forms separate from this enabled the
> framework to validate form data before an action was
> even involved in the process of handling the request
> and allowed for form reuse between actions.

I think we are arguing over semantics.  You could have a base abstract 
object that both the action and form object inherit from.  Call it what 
you want.  In the end, the separation you are seeking between the 'action' 
and the 'form' is really more logical.  Again the real value is the fact 
you now have the display portion of a view tied to the validation in one 
object.

> 
> I like the idea of creating a secure action.  We
> should also create other useful base actions such as a
> DispatchAction that would allow the use of ACID
> methods in a single action through the use of the
> _PARAMETER action mapping attribute.

Good!

> 
> There are many places that refactoring could happen
> and I agree that we should implement the use of
> factories for the actions, mappings, forms, and
> forwards.  The use of the session to hold the
> controller is not required and I think changing it to
> use a static variable (the singleton pattern) is a
> great idea.

Great!

--Tony

Re: [Phrame-devel] Use of session...

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

I do prefer having a single mechanism for handling
views (a special action).  I did a lot of research
determining if push or pull mvc would be a better
approach to take and found this article:

http://www.ingrid.org/jajakarta/turbine/en/turbine/turbine-2/pullmodel.html

I'm not sure about the idea of combining actions with
forms.  The original idea behind keeping them separate
is that the action mechanism (the command pattern)
should only be concerned with handling command logic. 
Keeping the forms separate from this enabled the
framework to validate form data before an action was
even involved in the process of handling the request
and allowed for form reuse between actions.

I like the idea of creating a secure action.  We
should also create other useful base actions such as a
DispatchAction that would allow the use of ACID
methods in a single action through the use of the
_PARAMETER action mapping attribute.

There are many places that refactoring could happen
and I agree that we should implement the use of
factories for the actions, mappings, forms, and
forwards.  The use of the session to hold the
controller is not required and I think changing it to
use a static variable (the singleton pattern) is a
great idea.

Arnold

--- Tony Bibbs <to...@to...> wrote:
> If you ask me, the display of a view or form is
> nothing more than a 
> special action, right?
> 
> If so, why not just treat it as such?  The
> controller should only be 
> concerned with building actions, executing them and
> handling any resulting 
> action mappings.  In fact I think you could refactor
> things a bit in 
> Phrame to make more sense:
> 
> Action: Abstract action class (already exists)
> 
> Secure Action: Inherits from Action, is also
> abstract but has some 
> security related methods (new)
>    
> Form: again, this is an action that can inherit from
> Action or Secure 
> action.  Only difference is the perform() method
> would show the form and 
> you'd have a validate() method that would validate
> the form. (new but code 
> exists in other existing objects)
> 
> From the developers perspective you now only edit
> one action to modify the 
> form and tweak the validation which, IMHO, is a huge
> time saver.
> 
> Please note this is just a matter of refactoring the
> current code.  I 
> don't think this would require any new code...just a
> matter of moving 
> things around a bit.
> 
> Also, I think you should think of adding a
> ActionFactory object.  This 
> implements the traditional Gang of Four Factory
> pattern and only generates 
> actions based on the request.  Thus your
> ActionController would have 
> something like:
> 
> $action =& ActionFactory::getAction($_REQUEST);
> $action->perform();
> 
> If you take my suggestion and make the form a
> special action it works the 
> same for business logic or view logic...
> 
> Thoughts?  Concerns?  Arnold, you alive?  I'm
> worried I may have turned 
> you off...
> 
> --Tony
> 
> On Wed, 5 Mar 2003, Jason Sweat wrote:
> 
> > It is not nescesary.  The only thing I keep in the
> $_SESSION is the error list.
> >  In my implementations I have not added it to the
> session.  Here is an example
> > PHP script from one of my implementations.  There
> is some other neat stuff I
> > have been waiting to see the next version of
> Phrame for to see if my changes
> > are compatible, like the $controller->ShowView()
> method.
> > 
> > <?php
> > /**
> >  * 	depot inventory dashboard web site
> >  *
> >  *	implemented using the MVC pattern, using Phrame
> 
> >  *
> >  *	@author		Jason E. Sweat
> >  *	@since		2003-02-13
> >  *	@package	Depot
> >  *	@version
> >  *	<pre>
> >  *		$Log: depot_inv.php,v $
> >  *		Revision 1.3  2003/02/13 19:09:39  sweatje
> >  *		inital start at conversion to MVC framework
> >  *		
> >  *	</pre>		
> >  *
> >  */
> > error_reporting(E_ALL);
> > 
> > /**
> >  * common definitions for this applicaiton
> >  *
> >  * includes the mappings, options and errorHandler
> function from the phrame
> > sample application
> >  */
> > require_once('depot_inv_setup.php');
> > 
> > //initialize error handler
> > if (!array_key_exists(_ERRORS, $_SESSION)) {
> >     $go_errors = new Stack();
> >     $_SESSION[_ERRORS] = $go_errors;
> > }
> > 
> > $go_controller = new
> DepotInvController($go_map->GetOptions());
> > 
> > if (array_key_exists(_ACTION, $_REQUEST)) {
> >     //release control to controller for further
> processing
> >    
> $go_controller->Process($go_map->GetMappings(),
> $_REQUEST);
> > } else {
> >     //release control to controller for displaying
> a view
> >     $go_controller->ShowView();
> >     exit;
> > }
> > 
> > //debugging code
> > trigger_error('Action with no redirect?');
> > if (true) {
> >     print "<pre>";
> >     var_dump($_SESSION);
> > }
> > 
> >  
> > ?>
> > 
> > 
> > 
> > 
> > --- Tony Bibbs <to...@to...> wrote:
> > > Is it really necessary to stick the controller
> in the session?  I'm trying 
> > > to see the value in jamming a potentially large
> amount of stuff into a 
> > > session which, I think, unnecessarily hogs
> server resources.  Is the 
> > > initialization overhead of the controller really
> that bad?  Also, if it 
> > > is, why put it in each user's session?  Why not
> make it a static variable?
> > > 
> > > I hope someone responds to my earlier posts, I'm
> ready to start tweaking 
> > > things but would like some feedback first.
> > > 
> > > -- 
> > > 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: Etnus, makers
> of TotalView, The debugger 
> > > for complex code. Debugging C/C++ programs can
> leave you feeling lost and 
> > > disoriented. TotalView can help you find your
> way. Available on major UNIX 
> > > and Linux platforms. Try it free. www.etnus.com
> > > _______________________________________________
> > > Phrame-devel mailing list
> > > Phr...@li...
> > >
>
https://lists.sourceforge.net/lists/listinfo/phrame-devel
> > 
> > 
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Tax Center - forms, calculators, tips, more
> > http://taxes.yahoo.com/
> > 
> 
> -- 
> 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
> 
> 
> 
> 
=== message truncated ===


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Re: [Phrame-devel] Use of session...

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

If you ask me, the display of a view or form is nothing more than a 
special action, right?

If so, why not just treat it as such?  The controller should only be 
concerned with building actions, executing them and handling any resulting 
action mappings.  In fact I think you could refactor things a bit in 
Phrame to make more sense:

Action: Abstract action class (already exists)

Secure Action: Inherits from Action, is also abstract but has some 
security related methods (new)
   
Form: again, this is an action that can inherit from Action or Secure 
action.  Only difference is the perform() method would show the form and 
you'd have a validate() method that would validate the form. (new but code 
exists in other existing objects)

From the developers perspective you now only edit one action to modify the 
form and tweak the validation which, IMHO, is a huge time saver.

Please note this is just a matter of refactoring the current code.  I 
don't think this would require any new code...just a matter of moving 
things around a bit.

Also, I think you should think of adding a ActionFactory object.  This 
implements the traditional Gang of Four Factory pattern and only generates 
actions based on the request.  Thus your ActionController would have 
something like:

$action =& ActionFactory::getAction($_REQUEST);
$action->perform();

If you take my suggestion and make the form a special action it works the 
same for business logic or view logic...

Thoughts?  Concerns?  Arnold, you alive?  I'm worried I may have turned 
you off...

--Tony

On Wed, 5 Mar 2003, Jason Sweat wrote:

> It is not nescesary.  The only thing I keep in the $_SESSION is the error list.
>  In my implementations I have not added it to the session.  Here is an example
> PHP script from one of my implementations.  There is some other neat stuff I
> have been waiting to see the next version of Phrame for to see if my changes
> are compatible, like the $controller->ShowView() method.
> 
> <?php
> /**
>  * 	depot inventory dashboard web site
>  *
>  *	implemented using the MVC pattern, using Phrame 
>  *
>  *	@author		Jason E. Sweat
>  *	@since		2003-02-13
>  *	@package	Depot
>  *	@version
>  *	<pre>
>  *		$Log: depot_inv.php,v $
>  *		Revision 1.3  2003/02/13 19:09:39  sweatje
>  *		inital start at conversion to MVC framework
>  *		
>  *	</pre>		
>  *
>  */
> error_reporting(E_ALL);
> 
> /**
>  * common definitions for this applicaiton
>  *
>  * includes the mappings, options and errorHandler function from the phrame
> sample application
>  */
> require_once('depot_inv_setup.php');
> 
> //initialize error handler
> if (!array_key_exists(_ERRORS, $_SESSION)) {
>     $go_errors = new Stack();
>     $_SESSION[_ERRORS] = $go_errors;
> }
> 
> $go_controller = new DepotInvController($go_map->GetOptions());
> 
> if (array_key_exists(_ACTION, $_REQUEST)) {
>     //release control to controller for further processing
>     $go_controller->Process($go_map->GetMappings(), $_REQUEST);
> } else {
>     //release control to controller for displaying a view
>     $go_controller->ShowView();
>     exit;
> }
> 
> //debugging code
> trigger_error('Action with no redirect?');
> if (true) {
>     print "<pre>";
>     var_dump($_SESSION);
> }
> 
>  
> ?>
> 
> 
> 
> 
> --- Tony Bibbs <to...@to...> wrote:
> > Is it really necessary to stick the controller in the session?  I'm trying 
> > to see the value in jamming a potentially large amount of stuff into a 
> > session which, I think, unnecessarily hogs server resources.  Is the 
> > initialization overhead of the controller really that bad?  Also, if it 
> > is, why put it in each user's session?  Why not make it a static variable?
> > 
> > I hope someone responds to my earlier posts, I'm ready to start tweaking 
> > things but would like some feedback first.
> > 
> > -- 
> > 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: Etnus, makers of TotalView, The debugger 
> > for complex code. Debugging C/C++ programs can leave you feeling lost and 
> > disoriented. TotalView can help you find your way. Available on major UNIX 
> > and Linux platforms. Try it free. www.etnus.com
> > _______________________________________________
> > Phrame-devel mailing list
> > Phr...@li...
> > https://lists.sourceforge.net/lists/listinfo/phrame-devel
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
> 

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

Re: [Phrame-devel] Use of session...

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

It is not nescesary.  The only thing I keep in the $_SESSION is the error list.
 In my implementations I have not added it to the session.  Here is an example
PHP script from one of my implementations.  There is some other neat stuff I
have been waiting to see the next version of Phrame for to see if my changes
are compatible, like the $controller->ShowView() method.

<?php
/**
 * 	depot inventory dashboard web site
 *
 *	implemented using the MVC pattern, using Phrame 
 *
 *	@author		Jason E. Sweat
 *	@since		2003-02-13
 *	@package	Depot
 *	@version
 *	<pre>
 *		$Log: depot_inv.php,v $
 *		Revision 1.3  2003/02/13 19:09:39  sweatje
 *		inital start at conversion to MVC framework
 *		
 *	</pre>		
 *
 */
error_reporting(E_ALL);

/**
 * common definitions for this applicaiton
 *
 * includes the mappings, options and errorHandler function from the phrame
sample application
 */
require_once('depot_inv_setup.php');

//initialize error handler
if (!array_key_exists(_ERRORS, $_SESSION)) {
    $go_errors = new Stack();
    $_SESSION[_ERRORS] = $go_errors;
}

$go_controller = new DepotInvController($go_map->GetOptions());

if (array_key_exists(_ACTION, $_REQUEST)) {
    //release control to controller for further processing
    $go_controller->Process($go_map->GetMappings(), $_REQUEST);
} else {
    //release control to controller for displaying a view
    $go_controller->ShowView();
    exit;
}

//debugging code
trigger_error('Action with no redirect?');
if (true) {
    print "<pre>";
    var_dump($_SESSION);
}

 
?>




--- Tony Bibbs <to...@to...> wrote:
> Is it really necessary to stick the controller in the session?  I'm trying 
> to see the value in jamming a potentially large amount of stuff into a 
> session which, I think, unnecessarily hogs server resources.  Is the 
> initialization overhead of the controller really that bad?  Also, if it 
> is, why put it in each user's session?  Why not make it a static variable?
> 
> I hope someone responds to my earlier posts, I'm ready to start tweaking 
> things but would like some feedback first.
> 
> -- 
> 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: Etnus, makers of TotalView, The debugger 
> for complex code. Debugging C/C++ programs can leave you feeling lost and 
> disoriented. TotalView can help you find your way. Available on major UNIX 
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Phrame-devel mailing list
> Phr...@li...
> https://lists.sourceforge.net/lists/listinfo/phrame-devel


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

[Phrame-devel] Use of session...

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

Is it really necessary to stick the controller in the session?  I'm trying 
to see the value in jamming a potentially large amount of stuff into a 
session which, I think, unnecessarily hogs server resources.  Is the 
initialization overhead of the controller really that bad?  Also, if it 
is, why put it in each user's session?  Why not make it a static variable?

I hope someone responds to my earlier posts, I'm ready to start tweaking 
things but would like some feedback first.

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

[Phrame-devel] One other thing

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

You should allow programmers to tell the controller if it will accept GET 
or POST or both.  All the code uses $_REQUEST which is the 'both' 
scenario.  For security reasons I can see a desire to lock it own to POST 
only.  This should be configurable via the constructor and take one of 
three constants.

Actions, these may want a "var $_secureAction" boolean that let's you 
denote a secure action versus an insecure.  Then you can stub a method to 
the class called _securityCheck() or something like that which would be 
implemented by children do do the actual security checks per the apps 
business rules.  Arguably this could be all handed down to another 
abstract class that inherits from Action but I think modeling security in 
shows forethought and will definitely get used.

Ok, more later...

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

[Phrame-devel] Initial Input

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

This is a lengthy email but it is important as I have put a bit of thought 
into this and would appreciate any thoughts.

Generally speaking I am happy with the code in Phrame.  Initially I have 
this one big problem.  In the example provided, index.php includes all the 
actions needed (only one in this case).  This will unnecessarily load code 
that is not really needed to process the current request.  With 
Java you have then handy 'import' statement.  We need to mimic that 
as close as we can.  Instead consider these options:

1) Since we have _TYPE, you could assume that there is a PHP file with 
that name.  So, in our example you have:
   
$mappings[_ACTION_FORMS]['form'][_TYPE] = 'CalcForm';
   
From this you could assume that CalcForm.php exists so in the 
ActionController simply do this:
        
require_once($mappings[_ACTION_FORMS]['form'][_TYPE] . '.php');
    
NOTE: this may require a new attribute _PATH in the mappings to 
indicate the exact path where the forms or actions could be found.

2) Add a new attribute, _PHP_FILE, which would hold the name of the php 
file for that form or action.

Next up is the ActionController I need to spend some quality time with 
this code. I'm not really understanding all the code fully and until I 
implement my own example it probably won't make sense.  I will do this 
tomorrow and shoot back any questions.

Finally, I have modified all the Phrame source code to be compliant 
with PEAR coding standards.  Here are some items consistently wrong:

1) PHPDoc comments missing.  I added all that I could
2) class variables and method that should be private should have 
underscore '_' as prefix (e.g. var $_myPrivateVar or function 
_myPrivateMethod).  This let's us quickly identify what is private even 
though PHP won't enforce it.
3) PEAR requires tabs in code to be the equivalent of 4 spaces.  This may 
be a pain in the rear but trust me, PEAR won't take them any other way. I 
fixed this already but this is something other should note.
4) Some other minor things...
 
Use:

Function foo()
{
}

NOT:

function foo() {
}

OR

function foo() {}

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

Re: [Phrame-devel] Phrame CVS

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

Hi Arnold,

Hope your workload will allow for some development time for Phrame soon.

With regards to your request for cvs layout, might I suggest

phrame
phrame/util
phrame_doc
phrame_ex

I know you have expressed reservations about the util classes, and how closely
they are assoiated with Phrame, so perhaps you might also concider:
phrame
phrame_doc
phrame_ex
util

and use a relative path for the include:
require_once '../util/HashMap.php';

You might also want to do what some other projects have done with dblogin
includes...test for a file (not in cvs) that would contain a path prefix for
the util files, otherwise use a default.  This would allow for some flexibility
if someone wanted to move the files elsewhere.

HTH

Jason

--- On 02/12/2003 Arnold Cano <arn...@ya...> wrote:
> I appreciate everyones patience for the new beta
> release of Phrame that fixes quite a few outstanding
> design issues.
> 
> 1. Redesigned uses of include() to require_once() on
> demand
> 2. Refactored core classes
> 3. Utilized references throughout
> 4. Separated the utils classes from the core classes
> 5. Added support for dispatch actions through the
> 'parameter' attribute 
> 6. Added support for per action error handlers
> 7. Added a pure php example to the Phrame examples
> ...
> 
> Unfortunately, my current workload does not leave with
> me with much time to develop Phrame as much as I'd
> like.  I will be adding the stable and beta release
> mentioned above to the sourceforge cvs as soon as I
> can.  Any ideas on the layout of the cvs structure
> would be appreciated.
> 
> Thanks,
> 
> Arnold


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/