PHP Design tools? IDE?

Tim Tyler wrote:

> Doesn't using auto_prepend require php.ini/httpd.conf access

No, you can use .htaccess files.

> and affect *everything*?

Yes.

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/

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.


request -> lookup controller script by webserver -> lookup other script
by controller ->

vs

request -> lookup other script by webserver


>
>> 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 only works for the directory where you request it (and for the
directories under it)

> 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.

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.


>> > 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

--
Met vriendelijke groeten,
Tim Van Wassenhove <http://www.timvw.info>

Great thanks to all who responded!

Was very interesting reading for me with
discussion, links and thought-food....

Just some clarification...

>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.

No, that wasnt what I meant. There would be no scriptfile, page256.php, at all.
My idea was that the whole HTML-page would be generated on-the-fly
by the "engine" from the URL-arguments and the db-contents,
where you can store both the site-contents, and style information.

Some performance penalty, of course, to generate everything on the fly,
but if you dont expect the trafficload to be much of a concern...

I guess my basic attraction to this approach, is that once the engine is
debugged and working, you shouldnt have to change the code very often
-- but maybe I am dreaming again, perhaps :)

The database, consisting of something like one set of tables for the contents,
and another set of table for design-parameters, styles, etc,
and mappings between them
would then be more flexible and easier to maintain,
than a growing set of scriptfiles with a mix of HTML,
PHP, CSS and db-calls in them.

Of course, the main challenge of this approach, however, is how to design the
database in a good way, to allow you to FULLY DESCRIBE your whole site.

But I was actually having the idea (or dreaming) that somebody most likely
already had done all that work, and released it as a useful product.


>... Imho, a file system is a database.

Well... kind of... but a very simple special-case,
something like a db with only one table in it:

create table filesys
(
directory char(1024),
filename char(256)),
filecontent blob
);

I figure, however, there must be something more to db:es than this,
both from my personal experience, plus I heard they have become pretty
popular gadgets in today's business world, too ;)

Regards,

Very interesting, especially when considering maintainability. I would like
to have the information on one hand and layout on the other without
cluttering up my fs. Nice ideas!

In article <1641ee43.0410090244.5cf2ef4f@posting.google.com >, grz02 wrote:
> Great thanks to all who responded!
>
> Was very interesting reading for me with
> discussion, links and thought-food....
>
> Just some clarification...
>
>>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.
>
> No, that wasnt what I meant. There would be no scriptfile, page256.php, at all.
> My idea was that the whole HTML-page would be generated on-the-fly
> by the "engine" from the URL-arguments and the db-contents,
> where you can store both the site-contents, and style information.
>
> Some performance penalty, of course, to generate everything on the fly,
> but if you dont expect the trafficload to be much of a concern...

But what are the gains from it when it's stored in a RDBMS instead of the
filesystem?

> I guess my basic attraction to this approach, is that once the engine is
> debugged and working, you shouldnt have to change the code very often
> -- but maybe I am dreaming again, perhaps :)

Well, most filesystems already do work quite good. So if you use that,
you don't have to write the code (and/or debug).

> The database, consisting of something like one set of tables for the contents,
> and another set of table for design-parameters, styles, etc,
> and mappings between them
> would then be more flexible and easier to maintain,
> than a growing set of scriptfiles with a mix of HTML,
> PHP, CSS and db-calls in them.

Why would the grow more/less fast in a dbms than in a filesystem??

> Of course, the main challenge of this approach, however, is how to design the
> database in a good way, to allow you to FULLY DESCRIBE your whole site.

It is about designing your code/website in a good way. No matter where
the code for it will be stored.

>>... Imho, a file system is a database.
>
> Well... kind of... but a very simple special-case,
> something like a db with only one table in it:
>
> create table filesys
> (
> directory char(1024),
> filename char(256)),
> filecontent blob
> );

Actually, i think most filesytems (in use nowadays) map better to the hierarchical or the
network model than the relational model.

--
Met vriendelijke groeten,
Tim Van Wassenhove <http://www.timvw.info>

grz02 wrote:
> I guess my basic attraction to this approach, is that once the engine is
> debugged and working, you shouldnt have to change the code very often
> -- but maybe I am dreaming again, perhaps :)
>
> The database, consisting of something like one set of tables for the contents,
> and another set of table for design-parameters, styles, etc,
> and mappings between them
> would then be more flexible and easier to maintain,
> than a growing set of scriptfiles with a mix of HTML,
> PHP, CSS and db-calls in them.
>
> Of course, the main challenge of this approach, however, is how to design the
> database in a good way, to allow you to FULLY DESCRIBE your whole site.
>
> But I was actually having the idea (or dreaming) that somebody most likely
> already had done all that work, and released it as a useful product.

That is useless. 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. I use some apache
tricks, to get those nice urls - the number-dir is the only interessting
part of the url, which is the id in my db-table.

I'm working on a modularity, so that the news and image galleries can be
put into that tree. Is this what you ment, or did I completely miss your
point?


> I figure, however, there must be something more to db:es than this,
> both from my personal experience, plus I heard they have become pretty
> popular gadgets in today's business world, too ;)

Well, you can do everything with PCs. It is possible to write a script,
that will allow your whole website to be managned via web-interface
(even the design could be changed via web-interface), and a lot more,
but this just isn't worth the time writing it, for it can allready be
done. Maybe not as fast, but the time needed to write such a script
won't be compensated by that.

Greetings, Christian.

"Tim Tyler" <tim@tt1lock.org> wrote in message news:I5B2ww.My9@bath.ac.uk...
> 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.

I can achieve the functionality I require without header.php and footer.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.
>
> 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. This means that
every time you add or remove a page you have to update index.php. 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.

That's why I think front controllers are inferior to page controllers.

--
Tony Marston

http://www.tonymarston.net

"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:
>
<snip>

>> > 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.

--
Tony Marston

http://www.tonymarston.net

Chris Hope <blackhole@electrictoolbox.com> wrote or quoted:
> Tim Tyler wrote:

> > Doesn't using auto_prepend require php.ini/httpd.conf access
>
> No, you can use .htaccess files.

Many service providers disable that for security reasons.

Write code that depends of this sort of thing and many customers will
be unable to run it.
--
__________
|im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply.

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.

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.
--
__________
|im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply.