SitePoint Sponsor |
|
User Tag List
Results 26 to 48 of 48
-
Jun 3, 2003, 10:53 #26
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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...
-
Jun 3, 2003, 12:58 #27
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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
-
Jun 3, 2003, 13:02 #28
- Join Date
- Feb 2002
- Posts
- 625
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I wonder what the PHP developers would say regarding this topic, ie. how they would handle it...
-
Jun 3, 2003, 13:42 #29
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by HarryF
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):
PHP Code:CheckPagePermissions('Gallery','Create');
PHP Code:hasPermission('Gallery', 'View', $Gallery)
Other way that I've added global behavior is by routing all template printing through an application level function:
Instead of
PHP Code:$View->print();
PHP Code:DisplayPage($View)
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.
Originally Posted by HarryF
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).
-
Jun 3, 2003, 13:44 #30
- Join Date
- May 2003
- Location
- Canada
- Posts
- 26
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Selkirk
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?
-
Jun 3, 2003, 16:40 #31
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
right.
Here is an example of the Logical Resource Mapping Strategy as implemented by struts:
Code:<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>
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:
Code:<!-- Process a user logoff --> <action path="/logoff" type="org.apache.struts.webapp.example.LogoffAction"> <forward name="success" path="/index.jsp"/> </action>
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:
Code:#untested RewriteRule ^(.*)\.do$ /ActionServlet.php?requestpath=$1 [L,qsa]
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?
-
Jun 6, 2003, 23:48 #32
- Join Date
- Jun 2003
- Location
- Iowa, USA
- Posts
- 3,749
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Jun 7, 2003, 02:41 #33
- Join Date
- Mar 2003
- Location
- Germany
- Posts
- 216
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Aug 17, 2003, 00:47 #34
- Join Date
- Aug 2003
- Location
- Brisbane, QLD
- Posts
- 101
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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:
PHP Code:<?
// 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");
?>
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
PHP Code:$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;
}
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?)
-
Aug 17, 2003, 06:40 #35
- Join Date
- Nov 2000
- Location
- Switzerland
- Posts
- 2,479
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Tough issue.
what's between this and a front controller?
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
Code:www/do.php www/states/gallery.php
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.;
PHP Code: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' );
}
}
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.
-
Aug 18, 2003, 19:46 #36
- Join Date
- Aug 2003
- Location
- Brisbane, QLD
- Posts
- 101
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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
-
Sep 1, 2003, 02:09 #37
Elegant MVC in PHP with no overhead
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.
Originally Posted by Selkirk
Originally Posted by Selkirk
"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:
Code:<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>
PHP 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;
Originally Posted by Selkirk
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
-
Sep 1, 2003, 07:03 #38
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi.
Originally Posted by acostin
Originally Posted by acostin
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, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Sep 1, 2003, 13:06 #39
Originally Posted by lastcraft
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.
Originally Posted by lastcraft
Originally Posted by lastcraft
[/QUOTE]
Alexandru
-
Sep 1, 2003, 13:16 #40
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by acostin
"Why MVC" ... Maintainability increases exponentially.
"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.
PHP Code:$Mapping = unserialize(file_get_contents($SerializedSiteMapFileName));
$Destination = $Mapping[$KTURL];
if ($Destination) {
$Found=TRUE;
require $Destination;
}
I think that a central approach has its advantages, and code reuse can be extremely well achieved if you wisely use the controller.
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.
-
Sep 1, 2003, 14:11 #41
- Join Date
- Sep 2002
- Location
- Clearwater, Florida
- Posts
- 69
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by acostin
Cheers,
BDKRIf you're not on the gas, you're off the gas!
-
Sep 1, 2003, 14:39 #42
- Join Date
- Sep 2002
- Location
- Clearwater, Florida
- Posts
- 69
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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,
BDKRIf you're not on the gas, you're off the gas!
-
Sep 1, 2003, 14:42 #43
Originally Posted by Selkirk
Originally Posted by Selkirk
Maybe I'll find some time to read the other book this fall.
Originally Posted by Selkirk
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.
Originally Posted by Selkirk
Originally Posted by Selkirk
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.
Originally Posted by Selkirk
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
-
Sep 1, 2003, 14:58 #44
Hi,
Originally Posted by BDKR
Originally Posted by BDKR
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.
Originally Posted by BDKR
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
-
Sep 1, 2003, 20:22 #45
- Join Date
- Sep 2002
- Location
- Clearwater, Florida
- Posts
- 69
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by acostin
Originally Posted by acostin
Originally Posted by acostin
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,
Originally Posted by Michael Kimsal commenting over at PHPEverywhere
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,
BDKRIf you're not on the gas, you're off the gas!
-
Sep 1, 2003, 23:59 #46
Originally Posted by BDKR
Originally Posted by BDKR
Originally Posted by BDKR
Originally Posted by BDKR
Why haven't you used msession to keep the sessions together and decided to use a database?
Alexandru
-
Sep 2, 2003, 08:14 #47
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by Selkirk
Originally Posted by Selkirk
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Sep 2, 2003, 08:48 #48
- Join Date
- Sep 2002
- Location
- Clearwater, Florida
- Posts
- 69
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by acostin
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,
BDKRIf you're not on the gas, you're off the gas!
Bookmarks