PHP Design tools? IDE?
This is a discussion on PHP Design tools? IDE? within the PHP Language forums, part of the PHP Programming Forums category; Hi, Im an experienced database+software designer and developer, but, unfortunately, anything to do with web-programming and web-systems ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
10-07-2004
|
|||
|
|||
PHP Design tools? IDE?
Hi,
Im an experienced database+software designer and developer, but, unfortunately, anything to do with web-programming and web-systems designs is still a pretty new area to me... (been working mostly with "legacy" environments the last 10 years) So I am writing this, hoping to get some useful advise and feedback... I have done some pretty trivial, small websites with html/PHP, and now starting a bit more advanced one, where I will need SQL database-support, and will probably go for MySQL. Of course, I have read some elemantary tutorials and articles on the web, but still wonder how PHP is actually being used in practice when creating bigger web-sites... Is PHP usually handcoded? Like... you just make up a database, then a number of tables you think will do, and finally (what I am most concerned about) a multiplicity of different PHP script-files in an ad-hoc fashion? (I hope not, since it seems that this will quite soon produce a pretty diffcult-to-maintain-and-grasp mess of the whole system) So what I would like to learn, is what nice (preferrably free/open-source) tools for design and project-management are available? My idea is that you would like to have some IDE application, something like VB or Delphi or VC++, where you design your webpages and forms in a graphical manner, and you can code "event" pieces of code that will react to clicks, buttons and user-actions like in the traditional IDE:s. And then there is some "compiler" or rather that do all the boring routine-work of converting your design to html/PHP code. The page-designs would also be based on "templates", of course, so its flexible to modify if you want to change the look-and-feel of your whole site. Ideally, I would also prefer that the whole website-design would be stored in a separate, fixed set of tables in the database, rather than in a zillion different script-files, CSS-sheets, etc. I can also envision a design where, even if the website contains a huge number of pages and different functions, there would actually only be a single PHP-script "index.php" and all sub-pages are generated on-the-fly, from arguments in the URL, i.e. all URLs simply looking like: index.php?pageid=1 index.php?pageid=2 ... index.php?pageid=productlist index.php?pageid=registration index.php?pageid=loginform index.php?pageid=contactform etc... The index.php startfile might only look something like: <html> <php? include("lib.php"); main(); ?> </html> Then all pages would be generated on-the-fly by the main() function (defined in "lib.php", along with a host of useful subroutines), and driven by the URL-parameter 'pageid' and the overall site-design somehow stored in the database. All design-work you did in the IDE (graphical, code-snippets, etc) would then actually be stored in the DB, and the PHP script-files could then be a quite static PHP-implementation of an "engine" reading the DB-content and outputting the HTML-code and pages. So... could you please give me a short brief/hints/links to what IDEs and/or other free tools, along those lines, that already exist or what are commonly used for PHP/MySQL in real-world development. Thanks, 
|
|
10-08-2004
|
|||
|
|||
|
Re: PHP Design tools? IDE?
grz02 wrote:
> So... could you please give me a short brief/hints/links to what > IDEs and/or other free tools, along those lines, that already exist > or what are commonly used for PHP/MySQL in real-world development. Hi! Im not an expert on the matter since I've done most of my routines, classes and template engines myself, but just some sites you might want to check out come to mind. See the popular Smarty template engine at: http://smarty.php.net/ And for a real PHP IDE at least check out Zends PHP Studio at http://www.zend.com/store/products/zend-studio.php?home For mySQL database management there is of course at least PhpMyAdmin: http://www.phpmyadmin.net I know there are tons of others but without real personal experience on those, I will let others inform you. HTH -- Suni
|
|
10-08-2004
|
|||
|
|||
|
Re: PHP Design tools? IDE?
"grz02" <grz01@spray.se> wrote in message news:1641ee43.0410071356.717fb49e@posting.google.c om... > Hi, > > Im an experienced database+software designer and developer, > but, unfortunately, anything to do with web-programming and > web-systems designs is still a pretty new area to me... > (been working mostly with "legacy" environments the last 10 years) > > So I am writing this, hoping to get some useful advise and feedback... > > I have done some pretty trivial, small websites with html/PHP, > and now starting a bit more advanced one, where I will need SQL > database-support, and will probably go for MySQL. > > Of course, I have read some elemantary tutorials and articles on the web, > but still wonder how PHP is actually being used in practice when > creating bigger web-sites... > > Is PHP usually handcoded? > Like... you just make up a database, then a number of tables you think > will do, > and finally (what I am most concerned about) a multiplicity of different > PHP script-files in an ad-hoc fashion? > (I hope not, since it seems that this will quite soon produce a pretty > diffcult-to-maintain-and-grasp mess of the whole system) The way to Rapid Application Development (RAD) in any language, not just PHP, is to have a solid architectural framework with lots of reusable modules which you can access in order to build individual components or transactions. You may start by using something pre-written by somebody else, but once you have sussed out how it works you may wish to customise it, either because you wish to add more options, or because your personal style is different. When it comes to architectural frameworks I would suggest the 3-tier architecture or Model-View-Controller (personally I use both combined). The 3-tier architecture includes a Data Access Object (DAO) which contains the code which carries out all communication with the database. When it comes to building individual components with their own screens you can either produce all HTML tags from within your PHP code, or you can use a templating system. Personally I use XSL transformations from XML data as it is controlled by W3C standards and is used widely across the entire industry, not just within the PHP world. If you want further ideas you can browse the articles on my website at http://www.tonymarston.co.uk/php-mysql/index.html > So what I would like to learn, is what nice (preferrably free/open-source) > tools for design and project-management are available? > > My idea is that you would like to have some IDE application, something > like VB or Delphi or VC++, where you design your webpages and > forms in a graphical manner, and you can code "event" pieces of code > that will react to clicks, buttons and user-actions like > in the traditional IDE:s. Web pages do not have "events" like traditional desktop applications. The client issues an HTTP request, the web server recives it and generates a response. Web pages are also stateless, which involves another big change in thinking. > And then there is some "compiler" or rather that do all the boring > routine-work > of converting your design to html/PHP code. PHP code is not compiled, it is interpretted. However, there are third-party utilities that are able to cache the intermedaite bytecode. > The page-designs would also be based on "templates", of course, > so its flexible to modify if you want to change the look-and-feel > of your whole site. Templating systems do not come built into PHP, you have you choose one and plug it in to your framework. > Ideally, I would also prefer that the whole website-design > would be stored in a separate, fixed set of tables in the database, > rather than in a zillion different script-files, CSS-sheets, etc. Dream on. Unless you can configure your web server to access a database you MUST have scripts as files in a directory. > I can also envision a design where, even if the website contains > a huge number of pages and different functions, > there would actually only be a single PHP-script "index.php" > and all sub-pages are generated on-the-fly, from arguments > in the URL, i.e. all URLs simply looking like: Yuck! You are talking about a front controller. Personally I would avoid such things like the plague and go for smaller page controllers. > index.php?pageid=1 > index.php?pageid=2 > ... > index.php?pageid=productlist > index.php?pageid=registration > index.php?pageid=loginform > index.php?pageid=contactform > > etc... > > The index.php startfile might only look something like: > > <html> > <php? > include("lib.php"); > main(); > ?> > </html> > > Then all pages would be generated on-the-fly by the main() function > (defined in "lib.php", along with a host of useful subroutines), > and driven by the URL-parameter 'pageid' and the overall site-design > somehow stored in the database. > > All design-work you did in the IDE (graphical, code-snippets, etc) > would then actually be stored in the DB, and the PHP script-files > could then be a quite static PHP-implementation of an "engine" > reading the DB-content and outputting the HTML-code and pages. WYSIWYG editors for web pages are notorious for producing inefficient HTML code. Quite frankly if you are unable to build web pages without such an editor then your are a pretty poor developer. PHP was designed to produce HTML tags, so if you do not know how to generate HTML tags manually you will find PHP too difficult for your limited abilities. > So... could you please give me a short brief/hints/links to what > IDEs and/or other free tools, along those lines, that already exist > or what are commonly used for PHP/MySQL in real-world development. Different developers use different combinations of tools to achieve their purpose. I do it one way, but a thousand other developers will do it a thousand other ways. Who is right? We all are. You pays your money and you takes your choice. Happy hunting. -- Tony Marston http://www.tonymarston.net
|
|
10-08-2004
|
|||
|
|||
|
Re: PHP Design tools? IDE?
grz02 <grz01@spray.se> wrote or quoted:
> I can also envision a design where, even if the website contains > a huge number of pages and different functions, > there would actually only be a single PHP-script "index.php" > and all sub-pages are generated on-the-fly, from arguments > in the URL, i.e. all URLs simply looking like: > > index.php?pageid=1 > index.php?pageid=2 > ... > index.php?pageid=productlist > index.php?pageid=registration > index.php?pageid=loginform > index.php?pageid=contactform > > etc... > > The index.php startfile might only look something like: > > <html> > <php? > include("lib.php"); > main(); > ?> > </html> That's called a "front controller". http://www.phppatterns.com/index.php...leview/81/1/1/ ....is an article about front controllers in PHP. It is good - but AFAICS, the arguments given against front controllers in it are hogwash. The main objections are: ``In the simple example above, that may not seem like a problem, but what about when you have hundreds of Page Controllers? You end up with a massive switch statment or perhaps something disguised in an array, an XML document or whatever. For every page request, PHP will have to reload a bunch of data which is irrelevant to the current request the user is trying to perform.'' This is fundamentally the same task a webserver performs when looking up a file in a filing system. If PHP is doing the task, the webserver doesn't have to. It might be a bit slower in PHP than in C - but that's hardly a reason for not doing it in PHP. ....and... ``The other problem with running everything through a single PHP script, such as index.php, is it imposes a significant restriction on the flexibility PHP offers, by default, of allowing developers to "drop a script" anywhere under the web server's web root directory. Adopting this approach will likely cause you problems later, both from the practical perspective of having to updating the command hierarchy each time you create a new file to issues like integration with other PHP applications.'' ....which seems like nonsense to me. If you /must/ access code that is incompatible with a front controller (for some reason) nothing stops you from doing so. You lose the front controller's facilities in the process - but the alternative is not having them at all in the first place - so in practice little is lost. Storing your code in a filing system is a bit backwards - since you have to do independent version control, history tracking, backups, permission handling and updates. Everything should go into a database. Microsoft realised this - with WinFS: http://msdn.microsoft.com/Longhorn/u...S/default.aspx ....but have yet to pull it off. -- __________ |im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply.
|
|
10-08-2004
|
|||
|
|||
|
Re: PHP Design tools? IDE?
In article <I59pBA.1pM@bath.ac.uk>, Tim Tyler wrote:
> It is good - but AFAICS, the arguments given against front controllers > in it are hogwash. > > The main objections are: > > ``In the simple example above, that may not seem like a problem, but what > about when you have hundreds of Page Controllers? You end up with a > massive switch statment or perhaps something disguised in an array, an > XML document or whatever. For every page request, PHP will have to > reload a bunch of data which is irrelevant to the current request the > user is trying to perform.'' > > This is fundamentally the same task a webserver performs when looking up a > file in a filing system. If PHP is doing the task, the webserver > doesn't have to. It might be a bit slower in PHP than in C - but > that's hardly a reason for not doing it in PHP. The fileserver has to do a lookup anyways, to map the request to the controller script. Thus you end up with 2 lookups, where the first is pure overhead. In the case you want to have some code that is executed in every script you can also consider using the auto_prepend and auto_append functionality php has. My conclusion: The added value of a controller is 0. Not even mentionning that the chances for introducing bugs in your request->page mapper. Where the code in your webserver has been tested many times before. > Storing your code in a filing system is a bit backwards - since > you have to do independent version control, history tracking, > backups, permission handling and updates. > > Everything should go into a database. Imho, a file system is a database. -- Met vriendelijke groeten, Tim Van Wassenhove <http://www.timvw.info>
|
|
10-08-2004
|
|||
|
|||
|
Re: PHP Design tools? IDE?
grz02 wrote:
> Im an experienced database+software designer and developer, > but, unfortunately, anything to do with web-programming and > web-systems designs is still a pretty new area to me... > (been working mostly with "legacy" environments the last 10 years) First thing to remember: This html + http. Your possibilities are very limited (and also the work for you to do ;). But this also makes UI-Design the most important thing when writing php-code, for the code itself is not really a problem. But UI-Design is very difficult, for you can barely interact with the user. IMHO this makes php very different from any other programming language. > Is PHP usually handcoded? Yeah, I would say so - but that doesn't mean that you will have to do it. > Like... you just make up a database, then a number of tables you think will do, > and finally (what I am most concerned about) a multiplicity of different > PHP script-files in an ad-hoc fashion? > (I hope not, since it seems that this will quite soon produce a pretty > diffcult-to-maintain-and-grasp mess of the whole system) This is done quite often with php (the wbb is written this way), but this definitely doesn't mean, that it is a good way. > So what I would like to learn, is what nice (preferrably free/open-source) > tools for design and project-management are available? For php: Not really any. > My idea is that you would like to have some IDE application, something > like VB or Delphi or VC++, where you design your webpages and > forms in a graphical manner, and you can code "event" pieces of code > that will react to clicks, buttons and user-actions like > in the traditional IDE:s. > And then there is some "compiler" or rather that do all the boring routine-work > of converting your design to html/PHP code. > The page-designs would also be based on "templates", of course, > so its flexible to modify if you want to change the look-and-feel > of your whole site. Of course you should use templates for any of your projects (I would say that everything with more than 30 lines of codes should use a template-system). Which template engine to use is your first decision (smarty, etc or a self-written?). But the thing with vb-like design and events is neither available nor needed - html does this already. There are no events, all fields are perfectly given to you in the $_REQUEST variable - nothing more to want. What you seem to be looking for is a WYSIWYG Editor for html. Of course you can use one (I'd say dreamweaver is definitely the best one for windows, but it's not free), but that has nothing to do with php, but rather just a matter of your html-design. You could also write you html in a text-editor - it's not such a big difference, once you've learned it. > Ideally, I would also prefer that the whole website-design > would be stored in a separate, fixed set of tables in the database, > rather than in a zillion different script-files, CSS-sheets, etc. CSS should stay in files, for there is no use in storing it in tables. One big css file for your whole site will do it. If you don't like files, you can of course store your templates in the database, but this is not making a real difference. You will change a zillion different files to a zillion different table-rows... > I can also envision a design where, even if the website contains > a huge number of pages and different functions, > there would actually only be a single PHP-script "index.php" > and all sub-pages are generated on-the-fly, from arguments > in the URL, i.e. all URLs simply looking like: > > index.php?pageid=productlist > > etc... [snip] > Then all pages would be generated on-the-fly by the main() function > (defined in "lib.php", along with a host of useful subroutines), > and driven by the URL-parameter 'pageid' and the overall site-design > somehow stored in the database. This isn't such a good thing to do. You should combine some functions in one file, but not all - this will get big and bloated and your urls will look ugly and will be hard to understand. Just look at some forums (not the wbb - it's coding style is complete shit) - they have 5-15 files, each dedicated to a set of functions (one for thread-handling, one for post-handling, one for the user-profile and settings, and the admin control panel completely separated into a separate dir). I'd say that this is the right way to do it. > All design-work you did in the IDE (graphical, code-snippets, etc) > would then actually be stored in the DB, and the PHP script-files > could then be a quite static PHP-implementation of an "engine" > reading the DB-content and outputting the HTML-code and pages. That's what templates do. > So... could you please give me a short brief/hints/links to what > IDEs and/or other free tools, along those lines, that already exist > or what are commonly used for PHP/MySQL in real-world development. The best editor for windows is NuSphere's phpEd. But it costs 500$. Good - completely free - tools are rare for php (on windows). I'd say you have a strange view of php and should think about a bit, for most of what you wanted an IDE to do is done with a template-system and the already existing separation of processing-code ->PHP and design and interface code ->HTML. greetings, Christian
|
|
10-08-2004
|
|||
|
|||
|
Re: PHP Design tools? IDE?
"Tim Tyler" <tim@tt1lock.org> wrote in message news:I59pBA.1pM@bath.ac.uk... > grz02 <grz01@spray.se> wrote or quoted: > >> I can also envision a design where, even if the website contains >> a huge number of pages and different functions, >> there would actually only be a single PHP-script "index.php" >> and all sub-pages are generated on-the-fly, from arguments >> in the URL, i.e. all URLs simply looking like: >> >> index.php?pageid=1 >> index.php?pageid=2 >> ... >> index.php?pageid=productlist >> index.php?pageid=registration >> index.php?pageid=loginform >> index.php?pageid=contactform >> >> etc... >> >> The index.php startfile might only look something like: >> >> <html> >> <php? >> include("lib.php"); >> main(); >> ?> >> </html> > > That's called a "front controller". > > http://www.phppatterns.com/index.php...leview/81/1/1/ > > ...is an article about front controllers in PHP. > > It is good - but AFAICS, the arguments given against front controllers > in it are hogwash. No they're not. IMHO they are perfectly sound. Front controllers were designed for languages such as Java which have web servers which behave differently to Apache. With Apache you can have a URL that says www.site.com/page256.php?arg1=foo&arg2=bar and it will go straight to the requseted page. Using http://www.site.com/index.php?page=2...1=foo&arg2=bar means that everything has to go through index.php first, and index.php must then contain code to redirect to page256.php. Not only is this an unecessary overhead, it also means that every time you change your application you must remember to update index.php. This is a disaster waiting to happen, IMHO. I much prefer having a separate controller for each page. -- Tony Marston http://www.tonymarston.net > The main objections are: > > ``In the simple example above, that may not seem like a problem, but what > about when you have hundreds of Page Controllers? You end up with a > massive switch statment or perhaps something disguised in an array, an > XML document or whatever. For every page request, PHP will have to > reload a bunch of data which is irrelevant to the current request the > user is trying to perform.'' > > This is fundamentally the same task a webserver performs when looking up a > file in a filing system. If PHP is doing the task, the webserver > doesn't have to. It might be a bit slower in PHP than in C - but > that's hardly a reason for not doing it in PHP. The web server does not have a massive switch statement. It simply has the name of one of thousands of possible files that may exist on your file system. > ...and... > > ``The other problem with running everything through a single PHP script, > such as index.php, is it imposes a significant restriction on the > flexibility PHP offers, by default, of allowing developers to "drop a > script" anywhere under the web server's web root directory. Adopting > this approach will likely cause you problems later, both from the > practical perspective of having to updating the command hierarchy each > time you create a new file to issues like integration with other PHP > applications.'' > > ...which seems like nonsense to me. If you /must/ access code that > is incompatible with a front controller (for some reason) nothing > stops you from doing so. You lose the front controller's facilities > in the process - but the alternative is not having them at all in > the first place - so in practice little is lost. You do not lose any functionality of a front controller by using separate page controllers. There is nothing that can be done in a front controller that cannot be done in separate page controllers. > Storing your code in a filing system is a bit backwards - since > you have to do independent version control, history tracking, > backups, permission handling and updates. > > Everything should go into a database. Who says? > Microsoft realised this - with WinFS: > > http://msdn.microsoft.com/Longhorn/u...S/default.aspx > > ...but have yet to pull it off. Just because Microsoft say something does not mean that it is a good idea. -- Tony Marston http://www.tonymarston.net
|
|
10-09-2004
|
|||
|
|||
|
Re: PHP Design tools? IDE?
Hi grz,
This is a lot of questions/ideas/requirements. We have developed an open source framework for development of web based applications. It is called phpPeanuts. It seems to be close to some of your ideas but quite far from others. This has to do with design choices we made. I will begin with the similarities, then go into the differences. > I can also envision a design where, even if the website contains > a huge number of pages and different functions, > there would actually only be a single PHP-script "index.php" > and all sub-pages are generated on-the-fly, from arguments > in the URL, i.e. all URLs simply looking like: > > index.php?pageid=1 > index.php?pageid=2 > ... > index.php?pageid=productlist > index.php?pageid=registration Something like that yes: index.php?pntType=Product&pntHandler=EditDetailsPa ge&id=1 The index.php script will give you a form for editing the Product with id = 1. Or more precise, it will probably include the file that contains the class ObjectEditDetailsPage, instantiate it and forward it the request*. ObectEditDetailsPage will use its inherited function getRequestedObject() to obtain an instance of the class Product with id = 1, and generate and output a form for displaying and editing its properties. The form may be generated entirely from metadata. No need to have a database with forms. No boring designing forms for Product, Customer, Order, Shipment and all those other types you need. Just one single generic site design. Then if you specify the metadata in the Product class, the rest done is automaticly. As you see our aproach is object oriented. This means that we do not have a big pile of functions in which an engine is implemented, that processes passive data from a database. We rather have an assembly of objects that cooperate to do the work. Objects combine functions and data. This makes them much more flexible then just trying to represent the entire website desing in data (like your design seems to do) or in functions (like standard php scripting tends to do). With object orientation it is possible to offer the developer a default user interface for his application, and at the same time to allow the developer to specialize allmost any aspect of both the engine and the design by creating subclasses and overriding some methods. Because the methods are written in php, he can put in any code he likes, so he is not limited to what the existing engine can do. Like with most traditional IDE's, the user interface is composed from objects, like listboxes, tables, buttons, dialogs, etc. Only the phpPeanuts objects do not exist in the client PC and draw on the screen, but rather exist on the server, process requests and output HTML. For lists of user interfacing classes by category see http://www.phppeanuts.org/site/index...t.web/web.html Of course there is still a need for a place to put pieces of HTML that hold parts of the design. We could have stored them in the database, or use a template enigine, but we chose 'the simpelest thing that could possibly work': php include files. These have the advantage that you can include pieces of php to call methods. See http://www.phppeanuts.org/site/index...principle.html for how all this fits together. But if you like it better to have a database, be my guest: make some subclasses, override the methods that currently do the inclusion and fetch and interpret your design data from there... (actually you may hit a design limitation here, or maybe it has already been solved. Anyhow, if you explain how our design limits you you to specilize the framework in the way you need to, we will be happy see if we can make the necessary adaptations) > and you can code "event" pieces of code > that will react to clicks, buttons and user-actions like > in the traditional IDE:s. We do in specific situations support event handler methods. However, http works with url's, requests and pages that are returned. So our user interfacing framework focusses on handling requests and composing pages and forms. Only where the composition needs to be specialized in repeated details you will need to implement event handler methods. Otherwise it is a matter of specializing classes that becuase they exist override the defaults and override methods. We do not support IDE style WYSIWYG graphically editing a user interface. In an earlier version of the framework (in Java) we had an template technique for this, but even with dreamweaver it proved to be a lot of work to manually desing the user interface of a substantial application. The problem was a lack of abstraction. The result wass lots of replication, little reuse. We tried to make our objects editable with dreamweaver, but that was too cumbersome. Existing WYSIWYG editors simply could not cope with the dynamics of objects. (For some reason none of them supported the JavaBeans standard the way IDE's do). It would still be nice to have a way to WYSIWIG edit the bits and pieces of html the design is composed from. Preferably i would have that in the browser, as part of the working application. But building that is a huge effort, and the more we can reuse pieces of design, the less we can gain from it. But if anyone has substantial leftover money i would be happy to look into it ;-) I guess this is the basic difference between traditional IDE's and phpPeanuts: IDE's try to facilitate graphical designing and coding. We build components and try to faciltate their reuse. The more you can reuse, the less design and code you need for the same end user function. We believe that in the long run this gives a higer productivity then traditional IDE's and results in more flexible applications, in the sense of easyer to adapt to new or changing requirements. Greetings, Henk Verhoeven, www.phpPeanuts.org. * The mapping of urls to objects is called Request Dispatch and it is acutally a bit more complicated, see http://www.phppeanuts.org/site/index...+dispatch.html
|
|
10-09-2004
|
|||
|
|||
|
Re: PHP Design tools? IDE?
Tim Van Wassenhove <euki@pi.be> wrote or quoted:
> In article <I59pBA.1pM@bath.ac.uk>, Tim Tyler wrote: > > It is good - but AFAICS, the arguments given against front controllers > > in it are hogwash. > > > > The main objections are: > > > > ``In the simple example above, that may not seem like a problem, but what > > about when you have hundreds of Page Controllers? You end up with a > > massive switch statment or perhaps something disguised in an array, an > > XML document or whatever. For every page request, PHP will have to > > reload a bunch of data which is irrelevant to the current request the > > user is trying to perform.'' > > > > This is fundamentally the same task a webserver performs when looking up a > > file in a filing system. If PHP is doing the task, the webserver > > doesn't have to. It might be a bit slower in PHP than in C - but > > that's hardly a reason for not doing it in PHP. > > The fileserver has to do a lookup anyways, to map the request to the > controller script. Examine the work it has to do - depending on the structure of the filing system. The fewer files, the less work. > In the case you want to have some code that is executed > in every script you can also consider using the auto_prepend and > auto_append functionality php has. Doesn't using auto_prepend require php.ini/httpd.conf access - and affect *everything*? It doesn't make much difference - the main issue here - IMO - is whether the site is in the filing system or the database. > My conclusion: The added value of a controller is 0. Not even > mentionning that the chances for introducing bugs in your request->page > mapper. Where the code in your webserver has been tested many times > before. Why can't a front controller be "tested many times before"? Code can be shared. Not everyone has to reinvent the wheel. > > Everything should go into a database. > > Imho, a file system is a database. It is. It is a crappy one, with poor versioning, searching, filtering and sorting facilities. -- __________ |im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply.
|
|
10-09-2004
|
|||
|
|||
|
Re: PHP Design tools? IDE?
Tony Marston <tony@nospam.demon.co.uk> wrote or quoted:
> "Tim Tyler" <tim@tt1lock.org> wrote in message news:I59pBA.1pM@bath.ac.uk... > > grz02 <grz01@spray.se> wrote or quoted: > >> I can also envision a design where, even if the website contains > >> a huge number of pages and different functions, > >> there would actually only be a single PHP-script "index.php" > >> and all sub-pages are generated on-the-fly, from arguments > >> in the URL, i.e. all URLs simply looking like: > >> > >> index.php?pageid=1 > >> index.php?pageid=2 > >> ... > >> index.php?pageid=productlist > >> index.php?pageid=registration > >> index.php?pageid=loginform > >> index.php?pageid=contactform > >> > >> etc... > >> > >> The index.php startfile might only look something like: > >> > >> <html> > >> <php? > >> include("lib.php"); > >> main(); > >> ?> > >> </html> > > > > That's called a "front controller". > > > > http://www.phppatterns.com/index.php...leview/81/1/1/ > > > > ...is an article about front controllers in PHP. > > > > It is good - but AFAICS, the arguments given against front controllers > > in it are hogwash. > > No they're not. IMHO they are perfectly sound. Front controllers were > designed for languages such as Java which have web servers which behave > differently to Apache. With Apache you can have a URL that says > www.site.com/page256.php?arg1=foo&arg2=bar and it will go straight to the > requseted page. Using http://www.site.com/index.php?page=2...1=foo&arg2=bar > means that everything has to go through index.php first, and index.php must > then contain code to redirect to page256.php. You are complaining about the performance cost of reading a file like: <php? include("lib.php"); main(); ?> ....from the server? For those anal about performance, that seems to be more than compensated for by the lack of a need to include: include("header.php"); .... include("footer.php"); ....in every single page - and besides, that file should get cached and ought to take practically no time to read. > Not only is this an unecessary overhead, it also means that every time > you change your application you must remember to update index.php. When index.php looks like: <php? include("lib.php"); main(); ?> ....? How does that need updating? -- __________ |im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply.
|
Linear Mode
