Separate Logic / Presentation without Templates

[Dr Livingston]

Just like I said earlier folks....

Confused the hell out of me, and proberly a lot of other developers as well ?

Umm....

IMO do we actually need .NET ? Nope...

[Selkirk]

The central theme behind a front controller seems to be A single object dispatches all requests and this is a good place to put a bunch of common behavior

So for reasons I mentioned earlier, having a single dispatch object works better in Java than PHP (because Java can maintain state between requests and PHP has to serialize/unserialize to simulate maintaining state.)

I think I agree with HarryF and Codezilla that the auto_prepend_file is a good mechanism for centralizing common behaviour in PHP.

In my benchmarks, auto_prepend_file is exactly the same speed as an include. This means that if you really do need the behavior in every request, there is no performance penalty for using auto_prepend_file.

My main problem with the front controller implementations in PHP that I have seen so far has been the overhead cost of the dispatch.

The microsoft literature on front controllers warns about performance overhead as one of the liabilities of this pattern while the sun literature does not. I wonder if this is a reflection of Java having a cheaper implementation of this particular feature than ASP or PHP?

Java has an API to hook into the webservers request dispatch mechanism that PHP Does not yet have

Until then, I think we are better off leaving the dispatch to Apache. I think this is equivelent to the Physical Resource Mapping Strategy mentioned in Core J2EE Front Controller Pattern

[datune]

I wonder what the PHP developers would say regarding this topic, ie. how they would handle it...

[Selkirk]

Couple of questions; how do you handle "global" operations such as whether a given user has permission to perform this action.

This application uses http authentication in .htaccess files.

For other applications with finer grained access control, I have added a security check as the first executable line of code in the file (at the add.php level):

CheckPagePermissions('Gallery','Create'); 

or security checks before certain resources are accessed:

hasPermission('Gallery', 'View', $Gallery) 

The config.inc file includes a security.inc file into every file that checks a user cookie and initializes some global data structures that these two functions use.

Other way that I've added global behavior is by routing all template printing through an application level function:

Instead of

$View->print(); 

I would do

DisplayPage($View) 

DisplayPage would be defined in the config.inc file and be specific to the application. It would print the page view, add global site elements like dynamically generated global site menus.

I have been moving many of things that I used to put in the DisplayPage function into the Page Controllers and into the templates.

In light of this thread, though, I think I might revisit the concept from a front controller/mediator perspective

In light of this thread, I definately think I will start using auto_prepend_file for my config.inc.

As far as the templates are concerned, does a template like admin/galleryform.html constitute a complete page? What options do you see for re-use as far as building the HTML itself is concerned?

Yes. The template represents a complete page.

I will typically have one standalone template per page. (galleryform.html). A few templates per resource type (gallerydetail.html, gallerysummary.html) that only get used in other templates and a handful of shared global site layout templates.

I am a big fan of being able to use WYSIWYG editors on templates. (well, dreamweaver at least.) If you refactor your html to eliminate all duplication, you end up losing the ability to see what your site is going to look like while you are editing it in dream weaver. (a good example of losing the big picture is the smarty templates in x-cart.)

Its not necessarily good to think like a programmer when doing web design. (or force your own style of thought on them.) Web designers have their own types of tools for dealing with duplication (CSS).

[CamelToe]

... Until then, I think we are better off leaving the dispatch to Apache. I think this is equivelent to the Physical Resource Mapping Strategy mentioned in Core J2EE Front Controller Pattern

I was want to make sure I understand the theory behind this:

Physical Resource Mapping:
//www.myserver.com/path/to/gallery/add.php
(as in your example above)

Whereas, Logical Resource Mapping:
//www.myserver.com/?process=GalleryAdd

Am I write in this assumption?

And you would prefer the Physical Resource Mapping?

[Selkirk]

right.

Here is an example of the Logical Resource Mapping Strategy as implemented by struts:

    <servlet-name>action</servlet-name>
    <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>

...
  <!-- Action Servlet Mapping -->
  <servlet-mapping>
    <servlet-name>action</servlet-name>
    <url-pattern>*.do</url-pattern>
  </servlet-mapping>

This tells the web server to pass any request that ends in .do to an instance of the servlet called ActionServlet. ActionServlet is the name of Struts front controler.

ActionServlet uses a struts-config.xml file to hold a mapping between url paths and the objects that should service requests

Here is a portion of the struts-config.xml file from the example that comes with struts:

<!-- Process a user logoff -->
    <action    path="/logoff"
               type="org.apache.struts.webapp.example.LogoffAction">
      <forward name="success" path="/index.jsp"/>
    </action>

So, when then web server receives a request

http://www.myserver.com/logoff.do

It passes the request to the struts front controller.

The front controller then maps the request to the java object LogOffAction, and then sends the request to an instance of that object.

/jakarta-struts-1.0.2-src/src/example/org/apache/struts/webapp/example/LogoffAction.java

After the LogOffAction object processes the request, the front controller will redirect the browser to

http://www.myserver.com/index.jsp

The equivelent of the above servlet-mapping in Apache/PHP might be the following .htaccess file:

#untested
RewriteRule ^(.*)\.do$ /ActionServlet.php?requestpath=$1 [L,qsa]

Now ActionServlet.php will receive any request that ends in .do and can dispatch the request as it pleases.

Here is another PHP framework that implements the front controller pattern. It uses auto_prepend_file and an empty place holder in the documentroot for dispatch. I wonder why they didn't use a RewriteRule like the one above?

[sweatje]

I would like to let you know an in depth example of a PHP MVC implementation (using Phrame) is available as the sample article for the June issue of PHP|Architect.

http://www.phparch.com/issuedata/2003/jun/sample.php

Smarty is used as a template layer for the application, but this topic has veered a little off of the original subject and more towards MVC in general, so I thought you may find the article useful.

Regards.

[mkrz]

I read that article just yesterday and I must say that it's much better than the first one. Jason Sweat has refactored some important elements and the framework looks indeed very neat now. Just have a look at the PhpDoc documentation package that's included with the sample code. It looks wonderfully clean and understandable.

[soapsud]

sorry for reviving an old thread. i just wanted to say thanks to selkirk. with all this talk of MVC i thought i was doing something horribly wrong.

on re-evaluation i think i prefer the approach you describe. i've been developing (with smarty) in the same vein, and a typical page would look something like this:

<?
// class.Template.php is a wrapper around Smarty to provide basic application specific functionality. at the moment in sort of implies that i don't use a lot of smarty specific stuff

require_once('config.inc');
include_once('class.Template.php');
include_once('class.SomeClass.php');
include_once('class.SomeClass2.php');
include_once('class.AuthHandler.php');

AuthHandler::authenticate("required_permission");
$obj = new SomeClass();
$obj2 = new SomeClass2();

$data = $obj->getData;
$data2 = $obj->getMoreData;

$tpl = new Template()
$tpl->display(array($data, $data2), "template.tpl");
?>

in this sense, only the needed files (SomeClass 1 and 2) are being called, which i think MVC tends to (as you mentioned) have an all in one kinda approach to.

i think it's important to use the web server to provide that extra little bit of navigational information, in that

http://domain.com/gallery/add.php (and)
http://domain.com/gallery/view.php?id=4

is preferable to
http://domain.com/index.php?resource...w&gallery_id=4

or whatever...

although i am finding i use an MVC approach for things like database updates (deletes, edits, inserts) where the above script would be modified with perhaps a quick switch statement

$option = $_POST['option'];

switch ($option) {
    case "add":
        $obj->add($data);
        break;
    case "delete":
        $obj->delete($data);
        break;
    case "update":
        $obj->update($data);
        break;
    default:
        trigger_error("Not a valid option");
        break;
} 

i think that's a decent tradeoff between URL readability, and having one big front controller (opting for the many little ones instead)

however, i'm still not convinced at the moment it's the best way for me to go about things, i'd like to simplify it a bit if possible, and am not sure if perhaps moving to a bit more of an MVC design with it is the right thing to do.. as to what that would look like i'm not entirely sure... (ie, what's between this and a front controller?)

[HarryF]

Tough issue.

what's between this and a front controller?

The filesystem. Think a front controller in PHP, that doesn't require a massive array which maps out your site has to work on the basis of "guess work".

An interesting study is ISMO (thanks to lastcraft for finally getting me to take interest) which is a nice lightweight framework.

The front controller (a script called do.php in examples) is not the name of a directory (the states directory) within which it can find page controllers. Then, depending on the URL, it attempts to include a file and execute the class in it (which has the same name as the file i.e. same name as the URL).

Filesystem

www/do.php
www/states/gallery.php

A URL like http://www.site.com/do.php/gallery gets do.php to load the correct file.

With the file gallery.php there's a class called gallery (the page controller) which basically does the same thing as your switch statement above e.g.;

class gallery extends ismostate {
    function gallery(& $request) {
         parent::ismostate($request);
    }
    function exec_default() {
         echo ( 'This is the default action' );
    }
    function exec_add() {
         echo ( 'Adding something here' );
    }
    function exec_delete() {
         echo ( 'Deleting something here' );
    }
    function exec_update() {
         echo ( 'Updating something here' );
    }
    functoin foo() {
         echo ( 'This is not executed' );
    }
} 

Methods starting with exec_ can be executed as a result of the URL e.g. those above would be executed by the following URLs;

http://www.site.com/do.php/gallery <<< exec_default
http://www.site.com/do.php/gallery/blah <<< exec_default
http://www.site.com/do.php/gallery/add <<< exec_add
http://www.site.com/do.php/gallery/delete <<< exec_delete
http://www.site.com/do.php/gallery/update <<< exec_update

Another study is eZpublish 2.x where index.php is the front controller. Requests to a module lead to index.php looking for a file datasupplier.php in the module directory which contains a switch statement as to what to do next. Pretty simple but effective.

[soapsud]

ah thanks for the link harry, good stuff. i'm not really a programmer so all this is quite new to me. hadn't been on sitepoint since a number of years ago and it's quite different (i just discovered your great site a few days ago through php architect in a round about way)

i like what they're doing, i took a quick look at the code but found it a bit over much for what i was doing, and as a result rolled a quick front controller to cover the basics (ie, parse the request and execute the action within the state, etc..). the only "change" i made (which i don't believe ismocore does... correct me if i'm wrong) is to allow for the data dir to be above the webtree, so we don't need to worry about setting an .htaccess to prevent accidental web access.

i still have (partial, very minimal) issue with making php simulate the error pages (page not found, etc...) as that seems like a task the webserver should be doing. but as a result of the default (at least in my code) any unknown request which is valid will end up in the default state anyhow (which seems either like a feature or a limitation depending on how you look at it)

when i get a bit more time i'd like to study the ismo code a bit more to see what else i'm missing

[acostin]

Hello,
I have read with interests your comments on MVC and PHP, and also the issues about object persistence, and I have to agree that I have the exact same opinion about PHP and object instantiation.

PHP does not have the same run time environment. Each request initializes a fresh PHP environment.

That is why OOP programming is PHP is pretty dumb, as OOP is designed to "keep the data and the procedures that process this data together", while in PHP the data is *always* loaded from a database.

A front controller implementation in PHP has to take this into account because it is going to incur the costs of initializing its data structures on every request. It also incurs an overhead of dispatch.

Instead of using a struts-config.xml file, Phrame uses a mappings.php file to hold its dispatch data structures. As the application gets larger, this file will have to grow larger, taking more time to parse and load into memory on EVERY request.

We have met the exact same problem in Krysalis. (http://www.interakt.ro/products/Krysalis). Krysalis is a complete MVC implementation in PHP, and we think that we have solved most of the problems related with the overhead brought by MVC. Let me explain more:

"Why MVC" - because it's extremely flexible, and allows you to define with extreme ease rules of serving requests. While the default "serve from disk" method for PHP pages is pretty straight forward, it will not allow you to do enterprise level things. Like having 10 installed applications that share the same kernel, and that serves slightly different pages in logic or layout depending on the current application state. Maintanability increases exponentially.

"How"- we have chosen to create an XML structure to define our Controller. While this might seem "overheading" at the beggining, we've optimized this to a level that it is compiled to a pure PHP file that is written much better than the average coder will write it. What we have in our sitemap.xml file are description like below:

  <map:pipeline>
   <map:match pattern="language.xml" type="exact" internal="yes">
	<map:cache type="xml" src="./admin/resources/descriptors/cache/desc.xml" time="360"/>
	<map:generate src="modules/core/language/front/index.pxp" type="pxp"/>
	<map:transform src="modules/core/language/front/{skin}.xsl"/>
	<map:serialize type="xml" remap="no" header="no"/>
   </map:match>
  </map:pipeline>   
 
  <map:pipeline>
   <map:match pattern="search.xml" type="exact" internal="yes">
	<map:cache type="xml" src="./admin/resources/descriptors/cache/desc.xml" time="360"/>
	<map:generate src="modules/core/search/front/layout/index.pxp" type="pxp"/>
	<map:transform src="modules/core/search/front/layout/{skin}.xsl"/>
	<map:serialize type="xml" remap="no" header="no"/>
   </map:match>
  </map:pipeline>

Which are compiled to a large switch loop that does dynamic requires of the compiled pipelines. This means that the overhead added by the controller is extremely minimal, as the file is pretty small and the code is loaded dynamically - and only the needed code:

 switch ($KTURL) {
  case ("language.xml"):
   $found = true;
   require("/iakt/www/htdocs/www/prod/komplete/2.5.0beta4/krysalis/webapps/komplete/cache/0.cache");
   break;
  case ("search.xml"):
   $found = true;
   require("/iakt/www/htdocs/www/prod/komplete/2.5.0beta4/krysalis/webapps/komplete/cache/1.cache");
   break; 

This is the generated code for the case where the Controller rules are simple (direct association between URL and pipeline that serves an URL), but optimized code is also generated for more complex cases.

I mistrust the requirement that every action in your web application has to have an entry in a central file. This seems to me like it would inhibit your ability to move code between web applications and make it difficult to move things around in your file stucture and in your URL structure.

In my own code, I don't use a front controller, but instead I create a small PHP file for each "action" that the application would perform. For example

Should we consider then our smart compilation a "front page controller"?

I think that a central approach has its advantages, and code reuse can be extremely well achieved if you wisely use the controller.

Of course, alternative approaches exist, and final decision should be made regarding your familiarity with OOP, XML or with your exact project goals.

Alexandru

[lastcraft]

Hi.

That is why OOP programming is PHP is pretty dumb, as OOP is designed to "keep the data and the procedures that process this data together", while in PHP the data is *always* loaded from a database.

OO is about the development stage. It says next to nothing, as far as I know, about what happens at runtime. Can you explain the above comment?

...compiled to a pure PHP file...

I was wondering when code generation was going to be mentioned. Using XSLT to generate PHP code has proved a very effective combination in my experience. It allows a lot of preprocessing and PHP code can be "unrolled" (a'la loops) for efficiency. The thing is, this has no bearing on whether to use a front controller or not. You could just as easily generate the large number of script controllers as you could a single complex front controller.

To focus the debate again, it seems to me that front controllers work better with forms and can better cope with sudden switches of context. Examples include a form taking you to different locations or a permissions failure dropping you into an error page. Scripts either force ugly redirects or, slightly better, a PHP include(). Scripts lead to more natural page navigation and can mix easily with static pages. In the rough and tumble of web development this almost always ends up the preferred option for better or worse it seems.

Code generation can alleviate both of these with orthogonal tradeoffs such as greater developer expertise and the difficulty of refactoring XSLT code (for me at least).

A fascinating and overdue debate. More, more,...

yours, Marcus

[acostin]

Hi.
OO is about the development stage. It says next to nothing, as far as I know, about what happens at runtime. Can you explain the above comment?

OO is not only about the development stage. Actually, to get more close to "semantics", a class represents the description of an object, that is something with sense only at runtime. While a class is a definition of some properties and methods (a.k.a. the data and the procedures to process it under the same roof), the object represents the existence in memory of a data structure that includes the object type and the object properties.

What I'm saying is that, for PHP, the object constructor and properties are executed/loaded each time for the persistent storage, and even if this stateless approach adds a lot to round-robin load balancing, it seems to me that objects are just hype in PHP (actually, they are very good when coding to structure your code better, and maybe to add some encapsulation, but not for many other reasons - as loose coupling can be achieved easily in other ways).

As we know it, PHP is a language mostly used for 2 reasons - loop through recordsets to display data in a tabular form, and process HTML forms to store records in the database. I think this represents over 80% of the web development out there. As both those usages involve simple application logic and complex presentation logic, it is a pain in the *** to include the presentation logic INSIDE the obejects that are design to include the application logic. I've seen postnuke with a lot of echo "<tr><td>".$content."</td></tr>" and it was enough for me.

I was wondering when code generation was going to be mentioned. Using XSLT to generate PHP code has proved a very effective combination in my experience. It allows a lot of preprocessing and PHP code can be "unrolled" (a'la loops) for efficiency.

Used wisely, loop unrolling is nice. Used without brains this can become a real pain in the *** - we've left some of our developers take this to the edge, and reached PHP unlooped code of about 800 KB for a simple form. However, after a small and effective optimization (moved the repetitive things into some old-fashioned procedures), we've ended up with less than 50 KB code for the same thing.

The thing is, this has no bearing on whether to use a front controller or not. You could just as easily generate the large number of script controllers as you could a single complex front controller.

To focus the debate again, it seems to me that front controllers work better with forms and can better cope with sudden switches of context. Examples include a form taking you to different locations or a permissions failure dropping you into an error page. Scripts either force ugly redirects or, slightly better, a PHP include(). Scripts lead to more natural page navigation and can mix easily with static pages. In the rough and tumble of web development this almost always ends up the preferred option for better or worse it seems.

Actually Krysalis is a mix between a front controller and the page controller - that are both described in the sitemap.xml file. However, we will probably use something like a Cocoon2 FlowScript in the future to simplfy the definition of simple "flow" rules in the controllers.
[/QUOTE]

Alexandru

[Selkirk]

Hello,
That is why OOP programming is PHP is pretty dumb, as OOP is designed to "keep the data and the procedures that process this data together", while in PHP the data is *always* loaded from a database.

Orthogonal issues. Yes, in PHP data meant to persist between requests must always be reloaded. This has nothing to do with objects. You still have to reload the data even if you don't use objects.

"Why MVC" ... Maintainability increases exponentially.

Preaching to the converted about the benefits of MVC, although exponentially is a strong statement. However, I have to point out that MVC != FrontController.

"How"- we have chosen to create an XML structure to define our Controller. While this might seem "overheading" at the beginning, we've optimized this to a level that it is compiled to a pure PHP file that is written much better than the average coder will write it.

Another strong statement. Encapsulating data into PHP code is one of the slowest ways of importing data into a running program. Have you considered something like this instead of your switch statement:

$Mapping = unserialize(file_get_contents($SerializedSiteMapFileName));
$Destination = $Mapping[$KTURL];
if ($Destination) {
    $Found=TRUE;
    require $Destination;
} 

I suspect that you will find this dramatically faster for dispatch when not using a bytecode cache. I also suspect that it will be faster when you are.

I think that a central approach has its advantages, and code reuse can be extremely well achieved if you wisely use the controller.

It also has its disadvantages. Many of them only show up in large projects. (Remember, MVC does not imply centralization.)

I talked a little bit about centralization in my previous post. I have since learned that Struts 1.1 has added the feature to break up their single configuration files into multiple configuration files. They did this because they found that it was difficult for multiple team members to work on different parts of an application while having to share a centralized configuration file.

I expect further versions of struts will endorse further decentralization. I see that the xdoclet projects provides a decentralized way to specify a struts configuration file.

Another problem with a centralized configuration file that has to be compiled (ala Krysalis) is that as your application size increase, your compilation time increases. This represents an ever increasing drag on the code-compile-test cycle. I've noticed a trend towards quick feedback in this cycle driven by the growing popularity of extreme programming.

One thing about maintainability is that locality of reference in code is important.

JavaDoc style comments are more maintainable because the documentation is stored with code being documented.

Objects are more maintainable because the data is stored with the code that manipulates it.

My earlier file system example shows how the meta data is more robust on the macintosh file system because it is stored with the file that it describes.

Apache uses .htaccess files to decentralize configuration. There is nothing you can do in a .htaccess file that you can't do in httpd.conf. So why you need .htaccess?

This link talks about how XML is a more extensible and robust file format than binary formats because the meaning of a data item is stored with the data item itself as markup.

I see successful modern programming trends moving away from centralized structures in large scale development.

[BDKR]

That is why OOP programming is PHP is pretty dumb, as OOP is designed to "keep the data and the procedures that process this data together", while in PHP the data is *always* loaded from a database.

Something is wrong with this statement. Are we saying that data members in PHP objects must be made up of data taken from a database? That doesn't make sense. Perhaps you're talking about the non persistent nature of PHP from one page request to the next? This has nothing to do with OO in PHP or Java.

Cheers,
BDKR

[BDKR]

What's interesting about all of this MVC cacophony is that when I really look at it, it seems a bit like event-driven programming. The other funny thing is that I've been using an MVC like approach for a long time and didn't know it.

Anyways, please do note that I say it seems. I know it's not. First off, with event-driven stuff, there IS a persistence. There is something that never stops running/listening for an event of some sort then it runs off to process a bit of code that corresponds to that event. Also, there isn't the risk of event cascade.

But it is similar if you imagine the entire process of a page with various options or links being shown (the GUI), the following of one of those links (the event), and the process of responding to that event (the event handler or callback function or method). That's how I ended up with what is essentially an MVC pattern.

Just rambling....

Cheers,
BDKR

[acostin]

Orthogonal issues. Yes, in PHP data meant to persist between requests must always be reloaded. This has nothing to do with objects. You still have to reload the data even if you don't use objects.

Yes - but unfortunately you don't have to do this in Java (and I've also heard that .NET objects are persistent and reused using (guess what) class-id names). I'm not too deep in this, and frankly I have a good experience in Java and OOP architectures, but I think that the impossibility of doing this in PHP (yes, I know about SRM but never got to use it right) is one of the most annoying misses. Something like a "server-side" cursor, shared between pages when navigating a recordset, is not possible in the today/tomorrow PHP. And because of the process nature of Apache1 (as compared with the threaded approach in apache2), persistent objects that could be shared between requests will not be a reality soon. One could serialize to the disk or SHM, but this is a platform specific hack and still does not elimitate the constructors being called on deserialization, or the query of being recreated, etc.

Preaching to the converted about the benefits of MVC, although exponentially is a strong statement. However, I have to point out that MVC != FrontController.

Have to learn more about this indeed. Being caught up in the commercial world more than I would like, I have to admit that my research time has been "exponentially" decreasing in favor of some "marketing" activities. Actually, lately we've just bought two books based on a Slashdot post and on an Amazon recommendation. Martin Flower - "Patterns of Enterprise Application Architecture" and "Beyond software architecture - Creating winning solutions" - I have read the marketecture book first.

Maybe I'll find some time to read the other book this fall.

Another strong statement. Encapsulating data into PHP code is one of the slowest ways of importing data into a running program. Have you considered something like this instead of your switch statement:

$Mapping = unserialize(file_get_contents($SerializedSiteMapFileName));
$Destination = $Mapping[$KTURL];
if ($Destination) {
$Found=TRUE;
require $Destination;
} 

I suspect that you will find this dramatically faster for dispatch when not using a bytecode cache. I also suspect that it will be faster when you are.

Actually we've done a lot of benchmarks about serialization and other techniques of optimizing the Controller part of Krysalis. We've started with PEAR Cache (based on smart serialization, but pretty sensitive on race conditions, also unable to effectively use a bytecode cache for the compiled PHP code), and then we've decided to create a simple cache layer for ourselves. Having the generated PHP code on disk and dynamically requiring it brought a lot of performance to the controller.

As for using a pipeline lookup table as your example suggest, it is doable of course, we've thought of it but never investigated as our goal was to "generate PHP code as similar as possible with the code written by a programmer" - to ease debugging. However, thanks for the tip, we'll investigate this as we are always looking to minimize the time spent in the controller.

The idea is that fixed url requests are just a subset of the Krysalis sitemap, as we also have dynamic pipelines like "mod_(page|article|gallery).html" that are served in the same pipeline and for which a lookup table will not do as we process the incoming URL with the pipeline regular expression to see if it matches.

It also has its disadvantages. Many of them only show up in large projects. (Remember, MVC does not imply centralization.)
.....
different parts of an application while having to share a centralized configuration file.

We have indeed met this problem and it's quite annoying - we have a file lock procedure in the IDE (we have an IDE for Krysalis), but it's not the best way of handle this.

Another problem with a centralized configuration file that has to be compiled (ala Krysalis) is that as your application size increase, your compilation time increases. This represents an ever increasing drag on the code-compile-test cycle. I've noticed a trend towards quick feedback in this cycle driven by the growing popularity of extreme programming.

I'm really glad we've opened this conversation, as those are the exact problems we're confronting with, and with no time to research alternative open platform, we were doomed to search inside the team to find the solution.

Going descentralized with the Krysalis sitemap.xml file is a very doable thing, and we will look inside the Struts approach to see how they do this.

JavaDoc style comments are more maintainable because the documentation is stored with code being documented.
Objects are more maintainable because the data is stored with the code that manipulates it.
My earlier file system example shows how the meta data is more robust on the macintosh file system because it is stored with the file that it describes.

I see successful modern programming trends moving away from centralized structures in large scale development.

It seems that descentralization is the key for a maintanable architecture, and we have tried to implement this in the Krysalis by using aggregation. We define in the sitemap the possibility of merging resulted XML trees for the menu, the content and the nuggets, and then we aggregate them in a single output XML file.

Thinking at your comments, it really make sense now to redesign the Krysalis sitemap, to define the notion of module that comes with it's own sitemap and that is only integrated in the Krysalis main sitemap for future aggregation (right now we do this using copy/paste in the sitemap when we include a new module).

I think that Krysalis 3.0 will have this descentralized view in terms of sitemap.

Looking forward to other comments.

Alexandru

[acostin]

Hi,

Something is wrong with this statement.

Maybe because I am Romanian

Are we saying that data members in PHP objects must be made up of data taken from a database?

No, we are not saying this, but most of the data members of a dynamic PHP website objects are usually information from the database.

Exceptions are the OOP hierarchies that include a lot of custom application logic or that are an independent API - think PEAR, or JpGraph.

The idea is that you can use PHP and OOP very beatifully to create a library that does something, but finally when you get to a dynamic website - everything goes to : interogate the database - mix the HTML code. At least for what we've done mostly in the last 3 years.

That doesn't make sense. Perhaps you're talking about the non persistent nature of PHP from one page request to the next? This has nothing to do with OO in PHP or Java.

This is about it. When thinking of OOP in Java (for example), it was all about "live" objects, multiple threads running various objects, messages sent between the objects (few messages as Demeter might say).
Doing this in PHP is simply not possible - so the only way to write OOP in PHP (IMHO) would be to better structure your code.

I know that (see Zend survey about this) most PHP programmers use OOP to create websites, and I must admit that they can't be all wrong , but I think that OOP is not the answer for all the real-life problems in PHP. It will make you code better, be more organized and (maybe) reuse the code for the application logic.

I don't want to create a flame-war from the OOP purists, I think OOP has it's advantages and disadvantages, but until we'll have persitent objects we'll never be able to reach the elegance of Java (even if I understand that PHP is NOT Java and that it will never be). Also our non-OOP techologies have advantages and a lot of disadvantages but this is the open diversity that should fit all the programmers preferences

Alexandru

[BDKR]

This is about it. When thinking of OOP in Java (for example), it was all about "live" objects, multiple threads running various objects, messages sent between the objects (few messages as Demeter might say).
Doing this in PHP is simply not possible - so the only way to write OOP in PHP (IMHO) would be to better structure your code.

You are wearing Java colored glasses.

I know that (see Zend survey about this) most PHP programmers use OOP to create websites, and I must admit that they can't be all wrong , but I think that OOP is not the answer for all the real-life problems in PHP. It will make you code better, be more organized and (maybe) reuse the code for the application logic.

Those who know me know that I'm not an OO purist at the implementation level. It's good stuff, but it's not the solution to the software crisis.

I don't want to create a flame-war from the OOP purists, I think OOP has it's advantages and disadvantages, but until we'll have persitent objects we'll never be able to reach the elegance of Java (even if I understand that PHP is NOT Java and that it will never be). Also our non-OOP techologies have advantages and a lot of disadvantages but this is the open diversity that should fit all the programmers preferences

'...but until we'll have persitent objects...' is telling me that you are taking a Java centric view. Additionally, you probably feel that there is some concern of how this affects the creation of enterprise solutions in PHP.

Two points:
1) The persistence of objects is not part of the OO paradigm. The idea of OO predates Java (believe it or not) and the wide spread use of the internet which is why data persistence is even a question in this conversation.
2) The concept of shared nothing is an alternative to issues concerning persistence of state in PHP enterprise solutions.

As for elegance in regards to scaling a Java solution,

The Java approach encourages not just more complexity, but additional purchases to accomodate that complexity. Grabbing a JVM and notepad, you'll have a harder time setting up a webfarm than you would with a LAMP system. Many companies have a lot riding on 'enterprise' Java, and to make things *easier* runs counter to everything those companies have built the past few years.

I've run in to a few people who've claimed that in memory sessions can be distributed *instantly* between dozens of machines in a webfarm with no latency. I've asked for clarification on this point several times, and I've yet to see/read any. I've been hearing this claim since '99 when a colleague was raving on about weblogic (I think that was it). It was something like $25,000 per CPU at the time. Yes, even if that's faster, that's nifty and all, but building a 10 node cluster can easily put you in the $500,000+ (with hardware). I was also told that one machine running weblogic could have 50,000+ concurrent users with no noticeable lag time. Of course, no one ever gave the *hardware* specs to support that claim.

I wrote a good number of administrative utilities (in PHP) that needed to maintain state from page view to page view. These were deployed in a cluster (or web farm). I had the ability (as the cluster administrator) to route a visitor to the same machine in the cluster that he or she may have started a session on. If he/she/it started the session on Web_2, then the cluster manager (ATM in Turbo Cluster speak) would continue to route he/she/it to Web_2. However, it didn't matter if it managed to do this or not as the session information was stored in the database. All of the web servers in the cluster had the database in common.

The reason I state this is because PHP is not Java so we shouldn't feel the need to look at PHP through Java colored glasses. The route or solutions taken by the Java community can't be mapped onto PHP for a good number of obvious reason. Therefore, we shouldn't even try.

If you're curious what is meant by 'shared nothing', check the link below.

http://php.weblogs.com/discuss/msgReader$2677

Cheers,
BDKR

[acostin]

You are wearing Java colored glasses.

Nice said

'...but until we'll have persitent objects...' is telling me that you are taking a Java centric view. Additionally, you probably feel that there is some concern of how this affects the creation of enterprise solutions in PHP.

I actually don't think that persistent objects are the solution to the software crisis, but theu will surely make a lot of things easier/faster.

Two points:
2) The concept of shared nothing is an alternative to issues concerning persistence of state in PHP enterprise solutions.

I see, and I completely agree with you - as persistence has it's advantages and also has its drawbacks.

If you're curious what is meant by 'shared nothing', check the link below.
http://php.weblogs.com/discuss/msgReader$2677

I have proposed (but actually never implemented) this clustering solution to some of our clients, and indeed I've found it very easy to setup and maintain.
Why haven't you used msession to keep the sessions together and decided to use a database?

Alexandru

[lastcraft]

Hi...

Another problem with a centralized configuration file that has to be compiled (ala Krysalis) is that as your application size increase, your compilation time increases. This represents an ever increasing drag on the code-compile-test cycle. I've noticed a trend towards quick feedback in this cycle driven by the growing popularity of extreme programming.

Not really the problem. You still get one click testing if the appropriate test case invokes the necessary make command. With things being built on demand the developer impact is zero. We are only talking about a few thousand lines of code after all, not building a major C++ project.

Another problem wiI see successful modern programming trends moving away from centralized structures in large scale development.

This is the problem.

yours, Marcus

[BDKR]

I have proposed (but actually never implemented) this clustering solution to some of our clients, and indeed I've found it very easy to setup and maintain.
Why haven't you used msession to keep the sessions together and decided to use a database?

A number of reasons. At the time, I wasn't doing any development as such. My sole job was to build the back end and assist the head developer with migration to a different database. I decided that this was the most cost effective solution. At the ATM (let's call it cluster manager from now on as ATM means at least three different things in my head) level, I could maintain sessions, but none of what the head developer was doing required it. There are two reasons for this.

1) It wasn't needed for the transaction servers.
2) He had no concept of security (for the web based admin stuff).

Additionally, I didn't have a complete understanding of what msession was. However, I saw an easy solution to the problem by using the database.

Having looked at the msessions page just a little while ago, it seems pretty cool. However, I'm curious how this is worked into a system where there can be no single point of failure. One of the things I strived to do with the system was make sure a failure somewhere in the system was a non-event to the user. No more than a 2-3 minute (5 at most) interval before the system was aware of a failure somewhere and could adjust. Based on my understanding so far of the msession solution, I would need at least two seperate machines running the daemon to provide fault tolerance. One would be a slave that is also somehow monitoring availability of the first and replicating (synchronous) the state data maintained by the first. If the first one goes boom, the second one could easily step in and start doing battle.

This is something that is worth exploring for the most part. As much as this may take care of maintenance of state better than a db, it seems at this point to be more expensive and complicated.

Cheers,
BDKR