PHP Design tools? IDE? - Page 3

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Re: PHP Design tools? IDE?

grz02 wrote:
Quoted text here. Click to load it

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:

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

Quoted text here. Click to load it

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.

Re: PHP Design tools? IDE?

Thanks Christian.
CMS here stands for what?

Quoted text here. Click to load it

Re: PHP Design tools? IDE?

grz02 wrote:
Quoted text here. Click to load it

Content Management System

geetings, Christian

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:

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

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


Henk Verhoeven,

* The mapping of urls to objects is called Request Dispatch and it is
acutally a bit more complicated, see +dispatch.html

Site Timeline