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