I've tried working with other open source php designs for similar projects,
and found that they are either too simple with little abstraction and hard
coded features, or they are so complex and abstracted one need to be a OO
programmer to get anything done. To me that's not the objective of PHP. If a
web developer has those high level programming skills, then a java
application server will probably be mre suitable. For HTML/PHP/mySQL hybrid
designers like myself, the Freetrade code only requires a few days and some
experimentation before familiarity is achieved and the designer can have a
site up and working in as as little as a week. Modifying Freetrade is
relatively easy as the layout is easy to understand.
Chris Mason
Box 340, The Valley, Anguilla, British West Indies
Tel: 264 497 5670 Fax: 264 497 8463
USA Fax (561) 382-7771
Take a virtual tour of the island
http://net.ai/ The Anguilla Guide
Find out more about NetConcepts
www.netconcepts.ai
Talk to me in real time with Instant Messenger: [EMAIL PROTECTED]
Signature
F331 8AD1 36FB B3B0 DF9F D95B 8024 D1EA 7450 D50C
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Leon Atkinson
Sent: Friday, February 23, 2001 1:41 AM
To: FreeTrade
Subject: Re: [FreeTrade] freetrade architecture
> I know I found a lot of problems with this sort of abstraction when I
> was modifying FreeTrade. I had to add some extra information to the
> order (mostly delivery instructions). It seems like the sort of
> thing that would be common and should have been abstracted out, but
> there were a number of subtley different places where the structure of
> parts of the database were implied. (obviously some part of the
> database were highly integrated with the logic of the site, but other
> parts are just storage containers)
I will admit that the design of the checkout process was polluted a bit by
some last-minute changes that the architecture didn't account for. Clearly
I didn't structure the checkout process with enough modularity, and probably
with too much flexibility with regard to express versus non-express styles.
In retrospect, it seems more sensible to break up all the parts and allow
the implementor to put them together in whatever order. That's one thing we
ought to work towards.
And furthermore, the schema is not optimal. It seemed like a good idea at
the time to put serialized data in rows, but looking back it wasn't very
proper. :) I've removed this from the 2.x tree, actually. I've also put in
indexes and foreign keys where it seemed logical.
> The HTML was also intermixed with PHP coding quite a bit.
> Particularly display logic was intermixed with business and other(?)
> logic. (What do you call the code that runs the basic site...?) When
> I was trying to create new screens that were just other screens
> collated, I felt like I was forced to copy-and-paste more than I
> should have.
>
> I feel like more stuff could have been functions or objects, keeping
> things a little smaller and better factored.
>
When coding, it doesn't really bother me when I mix HTML in the code. I can
see through the layers of abstraction. And having starting doing CGI in C
back in 94, I'm comfortable using print statements to output all the HTML.
But I do see value in pushing that HTML into it's own space to make it
easier to change things, so in the 2.x tree I've built out functions for
common GUI elements (like selectors, text boxes, etc) like we have with
StartForm() in the 1.x tree.
Ultimately, I think it takes a little bit longer to code the screens, but
once they are done, they are easier to understand. Here's a simple example:
// Start the section table and the form
print(StartForm("edit_user", $method='post',
$action='UPDATE_LOGIN_PASSWORD',
$secure=TRUE, array("ID"=>$EditUser["ID"])));
startTable();
printEditRow(L_EDITUSER_LOGIN, "Login", $EditUser["Login"]);
printEditRow(L_EDITUSER_PASSWORD, "Password", "", 32, 255, "password");
printSubmit(L_EDITUSER_SUBMIT, L_EDITUSER_RESET);
endTable();
endForm();
That code builds the form for changing your username and password. If you
want to change the styles of all tables in the application, you can edit the
collection of functions (startTable, printEditRow) and it will happen across
the whole site.
Note, I could have stuck in a templating layer here, but like I said
earlier, my idea is that it's a toolkit for engineers.
> [I don't want to seem too negative -- I think things went quite well,
> and I was quite happy with my choice of FreeTrade]
Yeah, despite all the things I want to fix, the original framework has
proven to be very robust.
Leon
---
Leon Atkinson <http://www.leonatkinson.com/>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Site: http://www.working-dogs.com/freetrade/
Problems?: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Site: http://www.working-dogs.com/freetrade/
Problems?: [EMAIL PROTECTED]
