From: "Bob Hutchinson" <[EMAIL PROTECTED]>
> As things are pretty quiet on the freetrade mailing list at the moment, I
> would like to instigate a discussion on the subject of program
> architecture, a subject, I suspect, close to Leon's heart.
The architecture behind FreeTrade (called FreeEnergy) probably says enough
about my theories, but it's probably interesting to review the principles at
work. Recall that I wrote an article for Zend.com last year about
FreeEnergy. It tells the story of how I came to this model, and what
problems I was dealing with.
Generally, I had some experience with a content management system that took
a very generalized approach of templates that could contain more templates,
but it's generality came with the price of cumbersome implementation and
slow execution. The solution I applied was to specialize the template types
(screens, actions, navigation, layout, etc).
The most important principles behind my design are that the people building
the site are of sufficient ability to be considered "engineers" and that
anyone who has mastered HTML is capable of becoming an "engineer".
(Subsitute "programmer" for "engineer" if you wish. The terms are not
precise enough.)
Note that other architectures adopt the idea that there are "engineers" and
"designers". In other words, there are people who understand the
programming languages (PHP in this case) and those who don't. Furthermore,
the programmers don't understand graphical design, and the non-programmers
do.
The sensible approach to this problem is to present an interface to the
framework that allows non-programmers to change the design. Common
interfaces are web forms and mark-up languages. An example of the of the
former is eGrail, where you enter HTML into textareas. An example of the
latter is FastTemplates.
So, hopefully it's clear where I'm going with this. When it comes to the
PHP implementation of FreeEnergy, I don't accept the idea that there are
non-programmers. Said another way, if you can handle writing good HTML, you
can handle working around print statements. This is not true of
implementations in other languages. Turbine, a Java-based implementation of
FreeEnergy, legitimately encorporates templating languages like Velocity.
Java is significantly harder to program than HTML.
I guess I ought to throw in a disclaimer that I've only worked with about 30
graphic designers in my career. Certainly there are some contexts where my
principles don't apply. But then, FreeEnergy probably isn't a good choice
for your team.
For the last couple years that I worked at Clear Ink, we had a fairly good
separation between engineering and design. Engineers took HTML mock-ups (or
sometimes even Photoshop mock-ups) and implemented the design themselves.
In this situation, it really makes sense to create an environment the suits
the strong programmer who probably doesn't want another layer between PHP
and HTML.
As far as database specialists, I've usually been the database guy as well
as the programmer. If the roles were separated, I suppose you could adopt a
relationship where SQL was handed off to programmers. Actually, I recall a
project I had only tangent experience with where there was a remote DBA who
was writing lots of Oracle stored procedures. That was kind of painful, a
little worse than waiting for the designers to deliver HTML.
That's probably enough grist for the mill today, eh?
Leon
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Site: http://www.working-dogs.com/freetrade/
Problems?: [EMAIL PROTECTED]
