Proper way to design a 'skeleton' script? More...

[McGruff]

I might have missed a naming discussion a while back but do you think the InputController should be renamed "Request"? The current name kind of threw me initially until I realised what it was.

I'd make validateRequest and filterRequest "private" (the php4 way prefixed with an underscore...) if that isn't already your intention.

Also - these things are a matter of personal preference - I'd rename processRequest to isValid. Then you have:

   // set everything up..
   
   if($request->isValid()) {
       // continue with the script
   } else {
       // bad syntax 400 page
   } 

[kyberfabrikken]

The Front Controller is a pretty straightforward design, and we have managed to settle on a more or less consensus about how to implement it in php. We have had discussions about which level of complexity to support (should it add filters for example), but if we decide on a given feature-set and complexity-level, I think we would always end up with more or less the same result. I'm afraid that the Application Controller isn't as easy a task.
A few hundred posts back we had a discussion about what exactly this term covers. I think we're still not in the clear here. Could we perhaps try to find a clear definition of what an Application Controller is, before moving on ? If anybody has a good article we might take offset in that ?

Anyway - regarding forms I agree that filtering and validation are two basic mechanisms that are truly useful in as good as all applications. As I see it, they are a set of utilities that are used in conjunction with the concept of a form. For most applications it makes sense to use the form as a pivot for a set of classes, which it seems to me is more or less what you are talking about, when you say ApplicationController ?

I think that the overall layout of this construct should follow the basic MVC seperation. A FormModel (probably equal to the DataSource), a FormView (which is the code that renders the form) and a FormHandler. I'm sure we can agree on the responsibilities of the first two components, while the latter (the FormHandler) may be an object of discussion.

The FormHandler may be a generic object, which the application-programmer provides with a FormModel and a FormView. The FormHandler would use the information from the FormModel (which describes fields, and the rules/filters applying to theese) to validate the form and decide to either a) display the FormView or b) execute a command, which is provided by the application-programmer. The relationship between FormHandler<->Command may be through inheritance (the programmer would extend FormHandler and implement a hook-method) or through composition (the programmer would pass the Command as a parameter to the FormHandler)

We may choose to let the FormHandler actually decide between displaying a view (FormView) or dispatching to the Command, but I prefer to leave this to the FrontController. The FormView would thus be an entrypoint when displaying the form, while the FormHandler would be the entrypoint for the submit of the form. Depending on the validity of the submit, the FormHandler may either execute the Command or redirect back to the FormView.

Is this an overall model we can decide on ?
Is there anything more to the concept ApplicationController than this ? If so - what ?

[Ryan Wray]

It may be nice to branch off into a seperate thread to discuss the Application Controller -- considering this thread was really only concerned with a Front Controller. That way any comments about the Front Controller can be seperated from the Application Controller, and people can become aware that the Application Controller is being developed, instead of maybe getting lost in the development of the Front Controller leading up to it.

What do you think?

Oh, and excellent work guys!

[kyberfabrikken]

What do you think?

I agree.

[arborint]

The Front Controller is a pretty straightforward design, and we have managed to settle on a more or less consensus about how to implement it in php. We have had discussions about which level of complexity to support (should it add filters for example), but if we decide on a given feature-set and complexity-level, I think we would always end up with more or less the same result. I'm afraid that the Application Controller isn't as easy a task.

A few hundred posts back we had a discussion about what exactly this term covers. I think we're still not in the clear here. Could we perhaps try to find a clear definition of what an Application Controller is, before moving on ? If anybody has a good article we might take offset in that ?

I don't know if there is a good definition, but I get the sense that an Application Controller can handle pages, forms and groups of relateed pages and forms. This is different from a controller that manages only one or a few predefined states like a Form Controller. As I have said, I think a Form Controller is an example of as specific case Application Controller.

Anyway - regarding forms I agree that filtering and validation are two basic mechanisms that are truly useful in as good as all applications. As I see it, they are a set of utilities that are used in conjunction with the concept of a form. For most applications it makes sense to use the form as a pivot for a set of classes, which it seems to me is more or less what you are talking about, when you say ApplicationController ?

I think where a Form Controller focuses specifically working like HTML forms work, an Application Controller treats a form and any other page (or groups of pages) as the same thing -- a collection of related states.

I think that the overall layout of this construct should follow the basic MVC seperation. A FormModel (probably equal to the DataSource), a FormView (which is the code that renders the form) and a FormHandler. I'm sure we can agree on the responsibilities of the first two components, while the latter (the FormHandler) may be an object of discussion.

If you want to implement MVC using these parts it should be easy to do, but I'm not sure it should be required. The Skeleton Front Controller doesn't force MVC, but it can help implement it.

There was some discussion whether to implement a Form Controller first as the problem was familiar to most people and then expand it to an Application Controller.

[arborint]

I think that the overall layout of this construct should follow the basic MVC seperation. A FormModel (probably equal to the DataSource), a FormView (which is the code that renders the form) and a FormHandler. I'm sure we can agree on the responsibilities of the first two components, while the latter (the FormHandler) may be an object of discussion.

The FormHandler may be a generic object, which the application-programmer provides with a FormModel and a FormView. The FormHandler would use the information from the FormModel (which describes fields, and the rules/filters applying to theese) to validate the form and decide to either a) display the FormView or b) execute a command, which is provided by the application-programmer. The relationship between FormHandler<->Command may be through inheritance (the programmer would extend FormHandler and implement a hook-method) or through composition (the programmer would pass the Command as a parameter to the FormHandler)

I think if we built a Form Controller it should be probably create some sort of View Helper object that the View would use to get the form values, error messages, etc. You could consider it the "Form Model" as well I guess. I don't think the Form Controller should know anything about the View other than the minimum any controller would need to know.

As for the Model, it would probably be good to define a Gateway interface as the "Form Model". We could supply a simple Table Data Gateway that would be sufficient for forms that just do SELECT, UPDATE, INSERT on a single table.

This would probably be a similar configuration to if you used the Application Controller to manage a form, so these related classes (for the example) could also be used for that.

We may choose to let the FormHandler actually decide between displaying a view (FormView) or dispatching to the Command, but I prefer to leave this to the FrontController. The FormView would thus be an entrypoint when displaying the form, while the FormHandler would be the entrypoint for the submit of the form. Depending on the validity of the submit, the FormHandler may either execute the Command or redirect back to the FormView.

I think the Front Controller would dispatch the Form or Application Controller, which would then dispatch the appropriate "handler". As I recall we ended up calling any Command that has the method: execute($request, $response) is called a Handler. Our Front Controller ended up being a Handler that dispatched Handlers, and the other Controllers will probably be the same.

[33degrees]

The FormHandler may be a generic object, which the application-programmer provides with a FormModel and a FormView. The FormHandler would use the information from the FormModel (which describes fields, and the rules/filters applying to theese) to validate the form and decide to either a) display the FormView or b) execute a command, which is provided by the application-programmer.

I don't really see the point of creating a FormModel that's distinct from an ordinary model; the latter should contain all the information the FormHandler needs to validate the form, since the model should be validating the data it recieves in the first place.

[arborint]

I don't really see the point of creating a FormModel that's distinct from an ordinary model; the latter should contain all the information the FormHandler needs to validate the form, since the model should be validating the data it recieves in the first place.

There are a couple of reasons why we might want to create a "FormModel". One might be as a Value Object to use while controlling the form until there are no errors. Then the FormModel would be used as the source of data for the Model. For example the FormModel might maintain data in the session while the Model used a database.

Another might be to provide a simple Table Data Gateway to use as the Model for forms that only access a single database table which is a pretty common scenario. My experience is that it certainly make it easier for single table forms to only need to provide the table name, key field, field names, etc. to a generic Table Data Gateway than to rewite it every time. Plus it makes it so you can describe the table easily in data to create a RoR style CRUD interfaces.

[arborint]

I might have missed a naming discussion a while back but do you think the InputController should be renamed "Request"? The current name kind of threw me initially until I realised what it was.

Well I don't think it is done yet. What we have so far is a Request Processer which is a pretty handy piece of code that we may want to split out later to use standalone. But an Input Controller does a little bit more. The problem is: I'm not exactly sure what that "more" is because ultimately it is the common code refactored out of Controllers that use the Input Controller as a front-end.

Overrunner and I were discussing building a Form Controller next to show an example that people were familiar with. Most of the coders here have probably written some sort of Form Controller. That might give us a hint on both common code and the direction for an Application Controller.

I'd make validateRequest and filterRequest "private" (the php4 way prefixed with an underscore...) if that isn't already your intention.

As this code will probably be used/inherited by another controller, I thought there might be the possiblity that one might want to put some code between the two calls. Plus I think if we ever get to the end of the "skeleton script", we should go back, refactor, standardize naming, etc. and then do a proper PHP5 version.

[kyberfabrikken]

There are a couple of reasons why we might want to create a "FormModel". (...) For example the FormModel might maintain data in the session while the Model used a database.

Another might be to provide a simple Table Data Gateway to use as the Model for forms that only access a single database table which is a pretty common scenario. (...)

And it may act as a pseudo-model for forms, where there really isn't an underlying model. The FormModel may also describe specifics to the form, such as rules/filters and field editing-types. (Should a TEXT column be edited through a <textarea> or through some wysiwyg gizmo, for example).

Either way ... can't we keep the discussion in the thread I put up yesterday. (here)

[33degrees]

And it may act as a pseudo-model for forms, where there really isn't an underlying model. The FormModel may also describe specifics to the form, such as rules/filters and field editing-types. (Should a TEXT column be edited through a <textarea> or through some wysiwyg gizmo, for example).

Field editing types are a bad example, IMO, because that definitely belongs in the View layer. That's sort of my issue with the FormModel concept in general; In my view of MVC, models are never tied to specific views. If the view needs something that it can't get from the model, it should use a helper class.

There are a couple of reasons why we might want to create a "FormModel". One might be as a Value Object to use while controlling the form until there are no errors. Then the FormModel would be used as the source of data for the Model. For example the FormModel might maintain data in the session while the Model used a database.

This is a good point, but there a different ways of dealing with this; one would be to have the model use different data mappers for persisting to different sources. That way the model could maintain data in the session until there are no more errors, then store it in the database.

Another might be to provide a simple Table Data Gateway to use as the Model for forms that only access a single database table which is a pretty common scenario. My experience is that it certainly make it easier for single table forms to only need to provide the table name, key field, field names, etc. to a generic Table Data Gateway than to rewite it every time. Plus it makes it so you can describe the table easily in data to create a RoR style CRUD interfaces.

I'm not sure exactly what you mean by rewrite it every time? Regardless, I'm very reticent to provide multiple ways of accessing the same data; in my experience, I've never come across a problem whose best solution was to do so. In any case, I do think we need to work on the ApplicationController before getting into how the model layer will work.

[arborint]

but there a different ways of dealing with this; one would be to have the model use different data mappers for persisting to different sources. That way the model could maintain data in the session until there are no more errors, then store it in the database.

True, but we need to provide some generic capability for things like an email form where the model is an Emailer class and there is no database.

I'm not sure exactly what you mean by rewrite it every time? Regardless, I'm very reticent to provide multiple ways of accessing the same data; in my experience, I've never come across a problem whose best solution was to do so. In any case, I do think we need to work on the ApplicationController before getting into how the model layer will work.

I meant that for the simple case of a form for a single table, that a generic Table Data Gateway class that you could extend by specifying a few properties would make doing the many forms really easy.

[Dr Livingston]

Umm...

I meant that for the simple case of a form for a single table, that a generic Table Data Gateway class that you could extend by specifying a few properties would make doing the many forms really easy.

I forget myself when it comes to domain design patterns, so excuse me, but what I would do if there was only the one database table, would be to have a generic object which would deal with the Create, Read, Update and Delete.

This generic object would therefore, use Reflection to access the properties (already these properties would hold the data from a form prior to being passed to the generic object) from another object, instead of using Inheritance as a solution, no?

I like using Reflection btw

[kyberfabrikken]

Field editing types are a bad example, IMO, because that definitely belongs in the View layer. That's sort of my issue with the FormModel concept in general; In my view of MVC, models are never tied to specific views. If the view needs something that it can't get from the model, it should use a helper class.

The FormModel, as I described it, would be an internal Model, not the application-wide model. The MVC paradigm would in this case apply to the form (In an abstract sense), rather than the whole application. So you may argue that the FormModel is really a ViewHelper. (Did that make any sense at all btw.?).
Anyway - rather than taking it from the bottom and up, I'd rather see a discussion on the overall structure of this so-called ApplicationController, than the implementation-specifics. What exactly is it we're dealing with here?

Either way ... can't we keep the discussion in the thread I put up yesterday. (here)

Seriously ?

[DougBTX]

So you may argue that the FormModel is really a ViewHelper. (Did that make any sense at all btw.?).

Sure it made sense

Example: you want ViewHelpers to make <input> fields which get data from the Models. Error message helpers can then just get data from the Models in the same way, so it fits to put validation in the Models.

Douglas

[33degrees]

The FormModel, as I described it, would be an internal Model, not the application-wide model. The MVC paradigm would in this case apply to the form (In an abstract sense), rather than the whole application. So you may argue that the FormModel is really a ViewHelper. (Did that make any sense at all btw.?).

I would say that yes, it's a ViewHelper, and it should be called a ViewHelper

True, but we need to provide some generic capability for things like an email form where the model is an Emailer class and there is no database.

Nothing wrong with having an Email model that doesn't save to a database, this is precisely why I suggest using DataMappers to do the persistance instead of using the ActiveRecord approach. What I'm against is having, say, a CustomerModel as well as a CustomerFormModel, the latter of which is used only by the CustomerForm class.

I meant that for the simple case of a form for a single table, that a generic Table Data Gateway class that you could extend by specifying a few properties would make doing the many forms really easy.

The potential need for this approach really depends on how the Model layer is implemented, and I agree with kyberfabrikken that now is not the time to be looking into this. Let's keep working from the top down.

[arborint]

I forget myself when it comes to domain design patterns, so excuse me, but what I would do if there was only the one database table, would be to have a generic object which would deal with the Create, Read, Update and Delete.

That's what I was proposing, a simple Table Data Gateway class that would be the Model for the simple single table Create, Read, Update and Delete case (which are pretty common). Just inherit and go.

[arborint]

I would say that yes, it's a ViewHelper, and it should be called a ViewHelper

I agree it is more a ViewHelper than a FormModel (which I noted originally).

Nothing wrong with having an Email model that doesn't save to a database, this is precisely why I suggest using DataMappers to do the persistance instead of using the ActiveRecord approach. What I'm against is having, say, a CustomerModel as well as a CustomerFormModel, the latter of which is used only by the CustomerForm class.

The potential need for this approach really depends on how the Model layer is implemented, and I agree with kyberfabrikken that now is not the time to be looking into this. Let's keep working from the top down.

The only reason to mention them is that we have been doing examples for people to see how things work. That's easy for a Front Controller that just dispatches other code, but now we will need some simple Model implementations to provide as examples.

[arborint]

Hey Overrunner (or anyone else interested) did you take a look a last round of the code here? Are these Filters/FilterChain and Rules/Validator classes agreeable to everyone? I guess I am looking for any further design changes not small stylistic ones.

Are these Rule/FIlter classes and the FilterChain/Validator style request processing the right way to go? Or are there better ways to solve this problem?

I know I will start using Overrunners Rule classes rather than my own because the ability to have Match rules it a definite improvement over the non-Datasource ones I currently use. I have found places (e.g. password, verify_password) where it will improve the code.

[Ezku]

Hey Overrunner (or anyone else interested) did you take a look a last round of the code here? Are these Filters/FilterChain and Rules/Validator classes agreeable to everyone? I guess I am looking for any further design changes not small stylistic ones.

Yeah. (I'd like to see InputFilter, InputRule etc instead, though.)

Are we moving to the new thread or staying here? I'd like us to separate the ApplicationController discussion from the FrontController one, just in order to be organized.

[Overunner]

Are these Filters/FilterChain and Rules/Validator classes agreeable to everyone?

Yepp. But I think you should let the concrete Filters inherit from the base class, otherwise the base class would be pretty much useless

Are we moving to the new thread or staying here? I'd like us to separate the ApplicationController discussion from the FrontController one, just in order to be organized.

I think we should move the discussion to the new thread here

[Captain Proton]

Either way ... can't we keep the discussion in the thread I put up yesterday.

The response sounds familiar

[arborint]

The response sounds familiar

If Overrunner and Ezku want to move it then let's move it. They have been actively involved.

[dagfinn]

This is old, but I just noticed it.

function getTime() {
    $microtime = microtime();
    $microtime = explode(" ", $microtime);
    $microtime = $microtime[1] + $microtime[0];
    return $microtime;
} 

==

function getTime() {
    return array_sum(explode(' ', $microtime));
} 

==

function getTime() {
    return microtime(TRUE);
} 

[Ezku]

function getTime() {
    return microtime(TRUE);
} 

From TFM: Note: The get_as_float parameter was added as of PHP 5.0.0.