PHP Design tools? IDE?

Tony Marston <tony@nospam.demon.co.uk> wrote or quoted:
> "Tim Tyler" <tim@tt1lock.org> wrote in message news:I5B2ww.My9@bath.ac.uk...

> > 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.
>
> I can achieve the functionality I require without header.php and footer.php.

This still seems like an anal performance niggle. Such issues are
way below my threshold of what's important when designing sites.
What I care about are things like time-to-market and rapid development -
not whether it takes 433 or 440 ms to render a page.

You should not make a mess of your architecture for the sake of a
few milliseconds - that's called premature optimisation.

> >> 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?
>
> If every request for a page starts off by going through index.php then it
> has to be redirected to the correct page, so index.php has to have knowledge
> of every page in the system so it can redirect to that page.

....or have access to that knowledge.

> This means that every time you add or remove a page you have to update
> index.php.

No - not if it has access to the information. The information is
presumably also stored in a database - and updates itself automatically
when new pages are created - so there need not be any maintenance
issue involved.

> In your example the cross reference between request and script may
> exist in lib.php, but that is the same difference - there is still a
> single place that needs updating each time you change a page.

Creating a page involved modifying the database. That would automatically
update the list of available pages.
--
__________
|im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply.

Thanks Christian.
CMS here stands for what?
/grz

Christian Fersch <Chronial@web.de> wrote in message news:<ck8i9d$2m6$01$1@news.t-online.com>...

>Of course it could be done, but it a lot more
>effective, to customize the script to the site, than having that big
>overhead (not only in speed, but also in code-lines and debugging time)
>of beeing able to create a _whole site_ dynamically.

>And that exists - it's called a cms and there are thousands of that kind
>out there.
>I have one running myself:
>http://www.cyberpunkuniverse.de/sitemap.htm

>This wohle tree is stored in one database-table.

Tim Van Wassenhove <euki@pi.be> wrote or quoted:
> In article <I5B2J4.Mn0@bath.ac.uk>, Tim Tyler wrote:
> > 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.
>
> The fewer lookups, the less work.

As a generalisation, this is false. The lookups can take different
quantities of work, and it is not always true that more looksups take
more work.

Another determiner of performance is how many alternatives have to
be searched throuh. Basically:

index.php?foo/bar/zub

....and...

foo/bar/zub/index.php

....takes the came work to parse as and resolve - since the same number of
alternatives need to be considered and searched throuh.

One is being searched in compiled C and the other one is being done
in PHP - and there /will/ be a speed difference there.

If performance is your overriding concern, then indexing files is
likely to be faster than accessing a database. That's a pretty
crummy argument for using flat files in this day and age, though.

If you want things to go faster, spend more on hardware - don't
bend your application framework out of shape for the sake of a
few milliseconds.

> >> 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.
>
> But the code in apache has already been tested many times before. And i
> have a good feeling it has been tested many more times than whatever
> controller script. Yes, i agree on not reinventing the wheel.

An argument against not writing a front controller yourself.

It's not exactly rocket science, though. You are only looking
up a script from a query string. Is that code going to need
weeks of testing before you get it right? Also, front controllers
are not exactly new either. There are plenty of them out there -
many already pretty well tested.

> >> > 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.
>
> Depends on the filesystem you are using, and what your requirements are.
> Personally i like the article: http://www.namesys.com/whitepaper.html

It seems to agree that most filing systems are impoverished and need
replacing.
--
__________
|im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply.

grz02 wrote:
> Thanks Christian.
> CMS here stands for what?

Content Management System
http://en.wikipedia.org/wiki/Content_management_system

geetings, Christian

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

"Tim Tyler" <tim@tt1lock.org> wrote in message news:I5Bwut.Iow@bath.ac.uk...
> Tony Marston <tony@nospam.demon.co.uk> wrote or quoted:
>> "Tim Tyler" <tim@tt1lock.org> wrote in message
>> news:I5B2J4.Mn0@bath.ac.uk...
>> > Tim Van Wassenhove <euki@pi.be> wrote or quoted:
>> >> In article <I59pBA.1pM@bath.ac.uk>, Tim Tyler wrote:
>
>> >> > 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.
>>
>> Storing code in a database does not automatically provide any of those
>> features. You still have to write them, just as you can for files in a
>> file
>> system.
>
> There are quite a number of searching filtering and sorting facilities
> built into databases and made available via the SQL language.

But you still have to write commands to invoke those operations, just as yiu
have to write commands to invoke filesystem operations.

> Databases typically have better facilites for grouping actions, undoing
> them and making backups, as well.
>
> Filing systems are primitive databases - too primitve for many
> applications these days - and a lot of data is migrating into
> databases, to provide better searching, indexing, filtering
> and sorting facilities.

I agree that data belongs in a database, but code does not.

--
Tony Marston

http://www.tonymarston.net

"Tim Tyler" <tim@tt1lock.org> wrote in message news:I5Bx9p.J51@bath.ac.uk...
> Tony Marston <tony@nospam.demon.co.uk> wrote or quoted:
>> "Tim Tyler" <tim@tt1lock.org> wrote in message
>> news:I5B2ww.My9@bath.ac.uk...
>
>> > 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.
>>
>> I can achieve the functionality I require without header.php and
>> footer.php.
>
> This still seems like an anal performance niggle. Such issues are
> way below my threshold of what's important when designing sites.
> What I care about are things like time-to-market and rapid development -
> not whether it takes 433 or 440 ms to render a page.
>
> You should not make a mess of your architecture for the sake of a
> few milliseconds - that's called premature optimisation.

If you say that there is very little difference in performance between a
single front controller and multiple page controllers, then why should I
switch from one to the other? My design works, it employs a lot of reusable
modules, it is flexible, so why should I change?

You like front controllers, I don't. I like page controllers, you don't. We
agree to disagree.

>> >> 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?
>>
>> If every request for a page starts off by going through index.php then it
>> has to be redirected to the correct page, so index.php has to have
>> knowledge
>> of every page in the system so it can redirect to that page.
>
> ...or have access to that knowledge.
>
>> This means that every time you add or remove a page you have to update
>> index.php.
>
> No - not if it has access to the information. The information is
> presumably also stored in a database - and updates itself automatically
> when new pages are created - so there need not be any maintenance
> issue involved.
>
>> In your example the cross reference between request and script may
>> exist in lib.php, but that is the same difference - there is still a
>> single place that needs updating each time you change a page.
>
> Creating a page involved modifying the database. That would automatically
> update the list of available pages.

I have all my transaction details stored in a database, but I still don't
need a front controller.

--
Tony Marston

http://www.tonymarston.net

"Tim Tyler" <tim@tt1lock.org> wrote in message news:I5Bxuy.JJ1@bath.ac.uk...
> Tim Van Wassenhove <euki@pi.be> wrote or quoted:
>> In article <I5B2J4.Mn0@bath.ac.uk>, Tim Tyler wrote:
>> > 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.
>>
>> The fewer lookups, the less work.
>
> As a generalisation, this is false. The lookups can take different
> quantities of work, and it is not always true that more looksups take
> more work.
>
> Another determiner of performance is how many alternatives have to
> be searched throuh. Basically:
>
> index.php?foo/bar/zub
>
> ...and...
>
> foo/bar/zub/index.php
>
> ...takes the came work to parse as and resolve - since the same number of
> alternatives need to be considered and searched throuh.
>
> One is being searched in compiled C and the other one is being done
> in PHP - and there /will/ be a speed difference there.
>
> If performance is your overriding concern, then indexing files is
> likely to be faster than accessing a database. That's a pretty
> crummy argument for using flat files in this day and age, though.
>
> If you want things to go faster, spend more on hardware - don't
> bend your application framework out of shape for the sake of a
> few milliseconds.
>
>> >> 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.
>>
>> But the code in apache has already been tested many times before. And i
>> have a good feeling it has been tested many more times than whatever
>> controller script. Yes, i agree on not reinventing the wheel.
>
> An argument against not writing a front controller yourself.
>
> It's not exactly rocket science, though. You are only looking
> up a script from a query string. Is that code going to need
> weeks of testing before you get it right? Also, front controllers
> are not exactly new either. There are plenty of them out there -
> many already pretty well tested.

Just because some developers like front controllers is no justification for
saying that everyone should use a front controller. They are not the only
solution, and IMHO they are not the best solution.

--
Tony Marston

http://www.tonymarston.net

Tony Marston <tony@nospam.demon.co.uk> wrote or quoted:
> "Tim Tyler" <tim@tt1lock.org> wrote in message news:I5Bx9p.J51@bath.ac.uk...
> > Tony Marston <tony@nospam.demon.co.uk> wrote or quoted:
> >> "Tim Tyler" <tim@tt1lock.org> wrote in message

> >> > 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.
> >>
> >> I can achieve the functionality I require without header.php and
> >> footer.php.
> >
> > This still seems like an anal performance niggle. Such issues are
> > way below my threshold of what's important when designing sites.
> > What I care about are things like time-to-market and rapid development -
> > not whether it takes 433 or 440 ms to render a page.
> >
> > You should not make a mess of your architecture for the sake of a
> > few milliseconds - that's called premature optimisation.
>
> If you say that there is very little difference in performance between a
> single front controller and multiple page controllers, then why should I
> switch from one to the other? My design works, it employs a lot of reusable
> modules, it is flexible, so why should I change?

My original point was that the arguments given against using
front controllers in an online article were not very good.

Front controllers have their moments - and are often used by
CMS systems - which are deployed across multiple web sites -
and which thus treat whole web sites as being user data.
In such contexts, a front controller makes quite a bit of sense.

I'm not trying to convert you to liking front controllers -
if you say you don't like them.
--
__________
|im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply.

"Tim Tyler" <tim@tt1lock.org> wrote in message news:I5EvsA.HnL@bath.ac.uk...
> Tony Marston <tony@nospam.demon.co.uk> wrote or quoted:
>> "Tim Tyler" <tim@tt1lock.org> wrote in message
>> news:I5Bx9p.J51@bath.ac.uk...
>> > Tony Marston <tony@nospam.demon.co.uk> wrote or quoted:
>> >> "Tim Tyler" <tim@tt1lock.org> wrote in message
>
>> >> > 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.
>> >>
>> >> I can achieve the functionality I require without header.php and
>> >> footer.php.
>> >
>> > This still seems like an anal performance niggle. Such issues are
>> > way below my threshold of what's important when designing sites.
>> > What I care about are things like time-to-market and rapid
>> > development -
>> > not whether it takes 433 or 440 ms to render a page.
>> >
>> > You should not make a mess of your architecture for the sake of a
>> > few milliseconds - that's called premature optimisation.
>>
>> If you say that there is very little difference in performance between a
>> single front controller and multiple page controllers, then why should I
>> switch from one to the other? My design works, it employs a lot of
>> reusable
>> modules, it is flexible, so why should I change?
>
> My original point was that the arguments given against using
> front controllers in an online article were not very good.
>
> Front controllers have their moments - and are often used by
> CMS systems - which are deployed across multiple web sites -
> and which thus treat whole web sites as being user data.
> In such contexts, a front controller makes quite a bit of sense.
>
> I'm not trying to convert you to liking front controllers -
> if you say you don't like them.

Understood. It's just that too many people say "you should use a front
controller because...", and when I look at their reasons I cannot see any
real justification, just opinion. I have seen documentation on why java
applications need front controllers, for example, but as I don't have the
same set of problems I certainly don't need the same set of solutions. A
front controller is just a means to an end, but it is not the only means.

--
Tony Marston

http://www.tonymarston.net