Front Controllers, Page Controllers, Intercepting Filters

[HarryF]

Question is, why are you tring to tackle this puzzle without a central connecting php script?

As codezilla has already said, in my words - because it's a pain in the a$$. My own site uses that approach - I used the 2.x version to ezpublish to build it. It has advantages in that you can give alot of power to the apps user without needing to write any PHP but the price is flexibility. If I want to use phpBB as the forum for phppatterns, the first hurdle I have to overcome is how phpBB will fit with being accessed via index.php.

This comes back to my opinion that Apache is PHP's front controller. Considering that example I posted above;

<?php
// index.php

switch ( @$GET['module'] ) {
    case 'news':
        include 'news.php';
    break;
    case 'forum':
        include 'forum.php';
    break;
    default:
        header('http/1.1 404 Not Found');
        die('Page not found');
    break;
}
?>

I can eliminate that script and my app should keep on working - news.php and forum.php being passed the requests directly from Apache.

The other issue with a central script is, unless you're careful (e.g. using the filesystem to check a page controller exists), it leads to slow down while PHP wades through something like a massive switch statement.

[JonR]

Hi,

If you had a Request class (handles all POST and GET), would you consider that a filter also? In a framework like this, would it be OK to consider all classes being used (part of the core framework) as a InterceptingFilter class?

I can't remember where unfortunately, but somewhere along one of the trails I followed off from this thread (probably two posts up from this one...) someone describes filters as massaging incoming/outgoing data. That's my current understanding, a layer between data input/output and your application logic. So yes, I'd consider a Request class a filter.

As to the other classes, I suppose it depends on what they do . I certainly think that there are a lot of things that could be delegated to filters, depending on how configurable the filters are. I guess that essentially an application is a filter on the data coming in and going out.

Also, would it be a problem if all InterceptingFilters had access to the filter manager? like:

$filterManager =& $this->fm;

That way you could access an InterceptingFilter previously loaded.

I don't know about this. On this page http://msdn.microsoft.com/practices/...ceptingFilter/ (linked from the WACT wiki) it says that filters shouldn't know about the presence of other filters, allowing them to be rearranged easily. Maybe filters should be a good expression of doing one thing and doing it well.

Cheers,

Jon

[JonR]

Hi,

The other issue with a central script is, unless you're careful (e.g. using the filesystem to check a page controller exists), it leads to slow down while PHP wades through something like a massive switch statement.

This is something else I'm wondering about. Well, there's a tenuous connection anyway... For these intercepting filters, I guess there will be certain filters that you want for every request (e.g. kill magic quotes), but others that you need only on certain pages (e.g. auth). The tenuous connection is the use of config files to declare filter requirements, similar to Struts/Phrame style mapping files for the front controller actions.

I guess it would be nice to be able to define general, always used filters in a config file, registry, whatever, but then be able to add other filters as required on a per page basis. I don't immediately see an easy way to deal w/ the ordering of the filters tho, plus maybe the config file parsing would slow things down too much?

Cheers,

Jon

[HarryF]

I guess it would be nice to be able to define general, always used filters in a config file, registry, whatever, but then be able to add other filters as required on a per page basis. I don't immediately see an easy way to deal w/ the ordering of the filters tho, plus maybe the config file parsing would slow things down too much?

That goes into notions Selkirk has raised before about central config files. It doesn't have to be that way. A (possibly non ideal) solution would be to have a file along side every page controller which contain info about what filters should run as well as anything the filter need e.g.;

example_page.php
example_page.ini <<< config info here

Code generation might make this easier (and faster).

[escape164]

I currently use a breed of FrontController and I can sympathize with both sides. On the one hand, it's great. But, on the other, it really forces my development into a box that does not allow easy change. I have used a pageController in the past as well, and that has worked very effectively for me.

However, for me it's a case of how large and complicated the application is going to be. For example, I have one site that has many different 'sub-application' modules. These are all under a modules/ directory and are accessed directly with the URL $site_www_dir/modules/$moduleName/. From here I use a FrontController because it's a specific well-defined area within my entire website.

Anyways, just comments thrown into the mix.

[Resolution]

Why not simply use two controlers?

one controller for the unique controls, the other for the common controls.

simple enough?

[Selkirk]

How about some guesses at requirements for how intercepting filtes / controllers should work in PHP?

1. Should not restrict the use of URLs
2. Should be possible to use Apache ... tricks
3. Should be possible to execute a page controller without the frontcontroller.
4. Does does not depend on any Apache specific features or php.ini settings.

A requirements list is a good idea. I was orginally going to suggest making two seperate lists. One for Intercepting Filters and one for Controllers.

Then, I saw where you were going with this in your next post...

Think it can be done automatically (fully automatic on Apache by using the 404 trick).

This is basically a front controller, right? I think any implementation of front controller would be able to support an implementation of intercepting filters.

The basic problem is how do we centralize some logic (e.g. logging, authentication) without requiring all PHP scripts be included by some central PHP script.

Or requiring each script to include a centralized PHP script?

My fundamental opinion is Apache itself is the Front Controller when working with PHP, as opposed to a Java Servlet, where you'd implement a Front Controller with Java itself.

I don't see Apache as a front controller. I see PHP/Apache as a container. Just like Java Servlets are run in a container.

When an HTTP request comes into a Java Servlet, the servlet needs to select which code gets executed next.

It does this via a web.xml file which contains a line which maps the url to a "logical page:"

<servlet-mapping>
<servlet-name>FrontController</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>

When an HTTP request comes into Apache + PHP, Apache effectively selects the PHP script to execute for you (if one exists for the requested URL).

PHP uses a physical file mapping technique, rather than a logical class mapping technique. In many ways this is easier when that is what you want. (put the file in a directory. No config file to edit.) However, in a FrontController situtation, you want to map many requests to a single php script. There is no sanctioned way to do this with a physical mapping. Thus, we have to resort to tricks because the "PHP Container" is not flexible.

In Java, Intercepting Filters are built into the container as well. Servlets are not aware of when they are being filtered. Filters are registered in the same web.xml file that the container uses to decipher urls. Define a filter:

<filter>
  <filter-name>Compression Filter</filter-name>
  <filter-class>CompressionFilter</filter-class>
  <init-param>
    <param-name>compressionThreshold</param-name>
    <param-value>10</param-value>
  </init-param>
</filter>

Call a filter for a specific servlet:

<filter-mapping>
  <filter-name>Compression Filter</filter-name>
  <servlet-name>FrontController</servlet-name>
</filter-mapping>

The servlet in the previous example is naive. It has no idea that it is being filtered.

To do the equivalent naive filtering in PHP/apache, I believe that you must use the auto_prepend_file and auto_append_file directives in the php.ini file. doing this via php.ini file is NO different than the doing the same thing in the web.xml file in java, except that you have to add apache configuration in order to achieve more fine grained targeting:

<Files ~ "*.do">
php_value auto_prepend_file /path/filter.php
</Files>

This type of config file editing is par for the course in java web applications.

So why is it that we have no .htaccess/.ini dependencies on our requirements list?

Take a look at the include based filters in my previous post. Everyone who has responded with an answer has suggested that I should use classes in that implementation.

However, if the requirement is to wrap "naive" code, I do not see the value of wrapping the filters in classes. Please enlighten me.

Question is, why are you tring to tackle this puzzle without a central connecting php script?

Indeed. I believe that this is one of codezillas requirements. I can understand why one would want to support wrapping "naive" scripts.

However, in WACT, I don't think we will really have any "naive" scripts. Thus, I think for WACT an interceptor implementation could rely on a Front Controller or Page Controller doing a little bit of filter management on the behalf of the application logic.

So for implementing a Front Controller in PHP, we have a few tricks to overcome physical mapping of urls:

get parameter
path after url
mod rewrite
404 tricks

My thought is that a Front Controller implementation for WACT should really be independent of which url mapping "trick" was used. In otherwords, the trick would not be defined inside the front controller, but inside the PHP/apache container before the front controller was called.

In my previous filter post, I had a filter which mapped a "path after url" into a get parameter. What do you think of that, Harry. As opposed to the request/uridata technique?

In a way, this makes the Front controller a container within a container.

[Selkirk]

One more thing, Codezilla. Because your include back takes place inside of a method, any global variables defined in the filtered file will no longer have global scope.

[sweatje]

One more thing, Codezilla. Because your include back takes place inside of a method, any global variables defined in the filtered file will no longer have global scope.

unless specifically designated as global, they will just not accidentally end up as global becuase you started using them in the global scope.

[Resolution]

The basic problem is how do we centralize some logic (e.g. logging, authentication) without requiring all PHP scripts be included by some central PHP script.

Ok. I get it. insted of a CENTRAL class being the traffic cop you want the object STRUCTURE to do all the heavy work - ie all the logic? If that be the case then I may have the possible solution worked out in my head.

Only the solution may break your requirements because it reqiures PHP5, and code morphing.

Should I post any way?

cheers

PS: This page got the mind in better focus. http://www.clipcode.net/components/snippets.htm

[codezilla]

If you had a Request class (handles all POST and GET), would you consider that a filter also? In a framework like this, would it be OK to consider all classes being used (part of the core framework) as a InterceptingFilter class?

I don't. First of all, I consider all Request data to be read-only. This isn't to say you should never modify the contents of $_REQUEST -- Selkirk's MovePathParamToGetParam() is a reasonable exception. Secondly, don't confuse the concept of "filtering" (i.e. taking some data and "filtering out" the anything that doesn't match a certain criteria), with the Intercepting Filter design pattern (i.e. taking a request and applying pre and post processing logic, essentially filtering the request). Either way, IMHO, the Request itself isn't a filter though it may be filtered.

[codezilla]

Fair enough . I'm curious as to why you stress that point?

Just to emphasize the point that I've never encountered a Cannot redeclare error (in this situation at least), and hopefully never will. So I don't consider the potential for receiving a Cannot redeclare error as an argument against my method (for my purposes at least, it may be completely valid for others).

[codezilla]

As codezilla has already said, in my words - because it's a pain in the a$$.

LOL. I'm glad someone else feels that way!

[codezilla]

However, if the requirement is to wrap "naive" code, I do not see the value of wrapping the filters in classes. Please enlighten me.

I'm probably repeating myself and you probably don't buy into my reasoning, but I like the class based intercepting filter approach mostly because I can put preprocessing and postprocessing code together (in the run() method,) and I can activate/deactive filters very easily during development. The bottom line for me is that, it makes it all easier to manage.

[codezilla]

One more thing, Codezilla. Because your include back takes place inside of a method, any global variables defined in the filtered file will no longer have global scope.

True, but like the Cannot redeclare issue this is a non-issue for me -- I don't use globals. Regardless, if a variable needs to be in the global scope, shouldn't it be declared that way (i.e. $GLOBALS['exampe'] = 'value')?

[codezilla]

Should I post any way?

Go for it! Just because I can't use it doesn't mean someone else can't.

[codezilla]

Question is, why are you tring to tackle this puzzle without a central connecting php script?

Indeed. I believe that this is one of codezillas requirements. I can understand why one would want to support wrapping "naive" scripts.

Exactly. My whole focus is simplicity and flexibility. However, I am opting for at least a little bit of complexity by using the class based Intercepting Filter approach, in order to leverage some of the power of OOP, but I very much like the idea of "naive" scripts, as Selkirk puts it. My background and skills aren't sophisticated enough to come up with a full-blown, robust app framework like Selkirk's WACT. And when I have tried using some of the other various php frameworks out there, my experience has been similar to escape164's:

On the one hand, [FrontControllers are] great. But, on the other, it really forces my development into a box that does not allow easy change. I have used a pageController in the past as well, and that has worked very effectively for me.

[lastcraft]

Hi...

Think it can be done automatically (fully automatic on Apache by using the 404 trick).

Er...what 404 trick?

yours, in ignorance again, Marcus

[JonR]

Hi,

Er...what 404 trick?

In Harry's earlier post:

http://www.sitepointforums.com/showp...6&postcount=20

right at the bottom.

Cheers,

Jon

[Resolution]

Just for the record - so we all follow the conversation.

I was reading back through your prior posts and I have a few questions concerning your design specifications.

I agree that it makes more sense to set the initial time in the TimingFilter constructor. However, I disagree that preprocessing should (in general) occur in the constructor. This would result in preprocessing happening for all the filters in the FilterChain, whether they are executed or not. If, for example, there were an AuthenticationFilter (high in the FilterChain) that determined the user should be redirected to a login page, it would be a waste for the PageCachingFilter (lower in the FilterChain) to perform pre-processing since it would never be executed. In other words, each filter should have the ability to cease execution of the FilterChain and commence post-processing (by not calling $fc->next()), therefore preprocessing should only occur if it needs to.

1. Why would authorization be ABOVE page caching?
2. what states do you expect each filter have? (pre,post)
3. If an EXIT occurs at the top of the chain what do you expect to happen and in which states?

But I need them to be called in the opposite order as they were registered because the first filter to do pre-processing should be the last to do post processing, the second should be next to last, etc. Like so: Decorator sequence diagram [microsoft.com]

4. What exactly do you want to do with these scripts in regard to function on a server?
5. What other deign patterns do you see that are needed in your vision of the functionality of these scripts? a la Decorator pattern

1. I'm making assumptions about the location and naming of the filters.
2. There's no way to pass parameters to the Filter constructors.

I also commented out extends InterceptingFilter in each filter class on my development machine.

6. What happens if a class that's NOT a filter is included AS a filter?
7. Why did you remove the extends?

Quote: Resolution

Question is, why are you tring to tackle this puzzle without a central connecting php script?

Personally, I feel that forcing everything through a single file (e.g. /index.php/extra/parameters) is unnecessarily complicated. I think it's much simpler (and therefore better for my purposes) to let each "atom" of functionality be its own page (generally speaking). Using a single script may be more powerful in many situations, but for the projects I work on, I need the flexibility and simplicity to have each page stand on its own. I've tried it both ways and find the page-centric version much easier to build and maintain.

I don't think I explained this properly, we may be miscommunicating. I am not speaking in terms of the NUKE series (and now Xaraya) of CMS (Content Managment Systems) where one index.php functions as the sole input/entry (Front Controller) into the application.

8. If you plan on using a Page Controller are you still going to use the interceptiong Filter pattern?
9. If so, will you need to tailor EACH Page Controller's filter set to match the following functions?
10. Ie. Authentication or Pagecaching may not happen on EVERY page so how do you plan to expand on this idea when the site grows in size and Page Controllers? Code morphing?

Quote: HarryF

As codezilla has already said, in my words - because it's a pain in the a$$.

LOL. I'm glad someone else feels that way!

HEY! LOL.. I got PROOF this works, damn well..


Ok.. Hope that was bite sized.
Everything down form there codezilla I agree with.

VERY interesting post fellas, looking for those solution sets.



cheers,
res

[Resolution]

Ok,

Here is my solve, a possible solution. It should load from one file.

cheers

[HarryF]

Phew - lots going on in this thread. Just picking up on some questions Selkirk raised

Take a look at the include based filters in my previous post. Everyone who has responded with an answer has suggested that I should use classes in that implementation.

However, if the requirement is to wrap "naive" code, I do not see the value of wrapping the filters in classes. Please enlighten me.

Likewise, when I really think about, can't see any particular advantage, aside from a general fetish for OOP (possibly some things like unit testing get easier). Essentially we're headed for what are essentially procedures like;

1. Start filter execution
2. Execute page controller
3. Any filter clean up operations

We aiming for 2 to be independent of 1 and 3 so does it really much much difference? Filters could be added with includes.

A requirements list is a good idea. I was orginally going to suggest making two seperate lists. One for Intercepting Filters and one for Controllers.

Please do - my list is like a hack - was hoping for feedback / modifications.

Think it can be done automatically (fully automatic on Apache by using the 404 trick).

This is basically a front controller, right? I think any implementation of front controller would be able to support an implementation of intercepting filters.

True but was considering it in an limited sense for code generation. For people on shared servers (most PHP users) with access to modify local php.ini settings with .htaccess, using a "404 deployer" would help generate the initial page controllers with filters attached. After that, the page controllers look after themselves. For those without the ability to modify ini settings, they'd need to occasionally execute some deployment script (like the WACT compileall.php scripts) but other than that, no worries.

Basically most of my thinking is motivated by coming up with something everyone can use.

Rethinking the solution may be really easy - auto_prepend / append for those that have it. For "off the shelf" PHP apps, some install script could modify the page controllers for those without access to modify auto_prepend / append, simply adding includes for the necessary at the start and end of each page controller.

More later - nappies await...

[codezilla]

1. Why would authorization be ABOVE page caching?

Because you shouldn't see a page (cached or not) if you're unauthorized to view it. Therefore authorization should take place before caching. However, the point of my example is that a filter should be able to "short-circuit" (i.e. end) the filtering process by commencing post-processing (if necessary) without calling the next filter.

2. what states do you expect each filter have? (pre,post)

I wouldn't refer to them as "states", but . . . pre-processing only, post-processing only, or both pre-processing and post-processing.

3. If an EXIT occurs at the top of the chain what do you expect to happen and in which states?

If an exit occurs then nothing else happens. In other words an exit should only occur when it needs to. I suppose that ideally post processing should occur for any filters that are higher up in the chain. I'm not sure how to make that happen, though.

4. What exactly do you want to do with these scripts in regard to function on a server?

I'm not sure what you're asking for, but my requirements are very similiar to the ones Harry came up with earlier in the thread. Basically, I want to be able to easily apply pre-processing and post-processing logic to a simple script without relying on any Apache-specific mechanisms. I'm not talking about specific functionality using an enterprise level web application framework like WACT. I'm talking about general functionality in a typical PHP script.

5. What other deign patterns do you see that are needed in your vision of the functionality of these scripts? a la Decorator pattern

Again, I'm not talking in specifics, so it depends on what functionality is needed.

6. What happens if a class that's NOT a filter is included AS a filter?

It won't work. There are an infinite number of "what if" scenarios. What if you pass an array instead of an object? I'm not worried about that happening. If I was, I'd be a Java programmer.

7. Why did you remove the extends?

Selkirk's suggestion. It doesn't add to the funcitonality of the classes. The run() in the base class isn't called so it's not necessary to use inheritance. BTW, I didn't remove extends I just commented it out.

I don't think I explained this properly, we may be miscommunicating. I am not speaking in terms of the NUKE series (and now Xaraya) of CMS (Content Managment Systems) where one index.php functions as the sole input/entry (Front Controller) into the application.

Then what do you mean by "central connecting php script"?

8. If you plan on using a Page Controller are you still going to use the interceptiong Filter pattern?

Yes.

9. If so, will you need to tailor EACH Page Controller's filter set to match the following functions?

I'm not actually creating PageController objects. I consider the actual requested script to be a combination of a Page Controller and a Template View. Think simple PHP page that we're all used to writing. I'm trying to take the absolutely most basic case and build upon that.

10. Ie. Authentication or Pagecaching may not happen on EVERY page so how do you plan to expand on this idea when the site grows in size and Page Controllers? Code morphing?

Good point. Code morphing? What's that? Sounds complicated. I'm not sure how exactly I'm going to handle it. I'll probably either use a central config file, or do something per page.

HEY! LOL.. I got PROOF this works, damn well..

I'm not saying it doesn't work, I'm saying it doesn't work well enough for my needs.

[codezilla]

Here is my solve, a possible solution. It should load from one file.

It didn't work. I keep getting a CRC error.

[Resolution]

Likewise, when I really think about, can't see any particular advantage, aside from a general fetish for OOP (possibly some things like unit testing get easier). Essentially we're headed for what are essentially procedures like;

1. Start filter execution
2. Execute page controller
3. Any filter clean up operations

Is this in regeard to filters in general of just selkirk's case?

We aiming for 2 to be independent of 1 and 3 so does it really much much difference? Filters could be added with includes.

If you didn't use filters how would you solve that problem?

More later - nappies await...

lol

cheers