THE WEBBOX ARCHITECTURE (a PHP implementation of ColdFusion’s “Fusebox”
architecture).
architecture).
Almost any interactive website breaks down into logical divisions. For
example, there is sometimes a “People” section of the site where you can
create an “account” for yourself, log in to your account, edit your account,
etc; on e-commerce sites there’s always an “Order” section where you create
order, check an order’s status, cancel an order, update an order, etc. In
the webbox architecture each of these functional areas is made into a PHP
object with a thin wrapper around it to allow each of the object’s functions
to be called and receive arguments via URL, form action or via PHP script.
The object plus its thin wrapper layer and other supporting files, I call a
“webbox”. The functions that can be called on the webbox, I call
“boxactions”. I use the term “webbox” for the wrapped object because this
entity isn’t really a pure PHP object anymore (it can’t be subclassed) and
because of the one feature that distinguishes its “boxactions” from regular
PHP class functions — that they can be called directly from URLs or form
actions. The implementation of this feature is the whole purpose of the webbox
architecture. Without it, “webboxes” are nothing more than regular PHP
objects, and I should not use any new terminology.
example, there is sometimes a “People” section of the site where you can
create an “account” for yourself, log in to your account, edit your account,
etc; on e-commerce sites there’s always an “Order” section where you create
order, check an order’s status, cancel an order, update an order, etc. In
the webbox architecture each of these functional areas is made into a PHP
object with a thin wrapper around it to allow each of the object’s functions
to be called and receive arguments via URL, form action or via PHP script.
The object plus its thin wrapper layer and other supporting files, I call a
“webbox”. The functions that can be called on the webbox, I call
“boxactions”. I use the term “webbox” for the wrapped object because this
entity isn’t really a pure PHP object anymore (it can’t be subclassed) and
because of the one feature that distinguishes its “boxactions” from regular
PHP class functions — that they can be called directly from URLs or form
actions. The implementation of this feature is the whole purpose of the webbox
architecture. Without it, “webboxes” are nothing more than regular PHP
objects, and I should not use any new terminology.
The boxactions of each webbox should be able to do anything PHP can do — write
HTML out to the browser, perform queries on relational databases, send e-mails,
look in LDAP directories, launch programs on the host system, create GIF
images, encrypt data, create PDF files, parse XML documents, open network
sockets, etc.
HTML out to the browser, perform queries on relational databases, send e-mails,
look in LDAP directories, launch programs on the host system, create GIF
images, encrypt data, create PDF files, parse XML documents, open network
sockets, etc.
