Over-engineering woes...

I've been given a project to do, largely from scratch, the scope of which to me is a non-trivial undertaking. An entire back-end has to be made to interface with an existing database from PHP, and, well, the objects and relations represented in the database are somewhat overwhelming given the scope of projects I've done in the past (UML diagrams that will not easily print on a handful of pages).

Now, I'm going to go on a bit of a tangent. Java is a nice, fundamentally solid object-oriented language. By common practice, you end up with getter and setter functions for every member on a class, nice encapsulation, and ultimately very reliable (if long, and tedious) code.

PHP is a newly emerging object-oriented language, in that PHP has been around for quite a while, but only in its most recent version has it supported classes. The majority of experience I have with PHP is as an in-line scripting language. My interaction with the database was done in the page, as I needed the information. Clunky, yes, but with little overhead. Impossible to work through a redesign with, but kind of elegant for the project scopes I used it on.

In becoming object oriented, PHP threw me a bit of a curve ball. Now I've got the homogenized nature of Java, all pretty and sterile, compartmentalized and encapsulated to the last, provided to PHP, the wild jungle banshee child of web languages. I'm fighting some very base, some might even say primal urges to use PHP's scripting language capacity to do database interaction, but no, that's bad. It needs to be extensible, easily redesigned, easily understood... it must be object oriented.

But then I look at the Java code that was previously used to interact with the database. Classes with hundreds of lines of getters and setters, code that was hard to navigate, not due to complexity, but monotony. Unnecessary sterility, unnecessary encapsulation for things that were just being consumed or emitted from objects, only to be consumed or emitted from the database. Things which would never need redesign, built that way "just in case..."

All of these things were done in Eclipse, so I realize no poor fool had to sit there and write all of them, but still. PHP is an interpreted language, slow on runtime because it is not precompiled. Surely, several hundred lines of code and function declarations meant only for the purpose of tradition could only slow it down further, and take me forever and a day to write using notepad++... I must think of a better way.

Then, it occurs to me. I'll make a solution that lets me write less code. The pitfall of all designers/programmers. The theory is simple, the implementation is only trivially less simple, and in practice it works practically identically to the Java model of doing things. I end up breaking encapsulation, but only a tiny bit, at the benefit of saving myself the effort of writing menial pass-through getters and setters.

In my model, most gets/sets are handled by an abstract class, which my "real" classes extend. The "real" classes have only the getters and setters defined for things that are special cases, like members that might pull from more than one place in the table, etc. The rest of the data members on an object are pulled from internal variables directly, based on column name. I don't have to write the setters/getters for trivial columns, like username for instance. Plus, if the column name changes, I can write a special case setter/getter for the old column name that will still behave identically, preserving encapsulation.

It's a brilliant plan, in theory, but I worry about having over-engineered it. I worry about it breaking people's expectations of an OO language. I know it will be nice for me to use, but, I'm not so sure how to expect other people to react. I'm breaking a precious paradigm, and Java coders throughout the ranks are cringing upon hearing my ideas. I want to think I'm not a bad designer, and I hope this turns out well. I hope that people will see the benefit of mixing object-orientation with the flexibility of PHP. We shall see.

Lunchbreak: jQuery Habits

Recently, jQuery has become by far my most favorite JavaScript framework. It's so freeing to be able to use statements like $(".restricted-admin").hide(); to hide elements en-mass, based on CSS class, or to be able to fade things with a similar statement, load page content via AJAX in two lines... yes, jQuery has become the new object of my amazement. It has made JavaScript website enhancement easy for the first time, ever.
My only concern is that it's too easy to encourage healthy programming practices. JavaScript is a funny little scripting language, in which you can create functions/objects mid-statement. So, you can make a statement like this:
$(".button1").click(function(){alert("we're inside a function!"); alert("hooray!");});
...with absolutely no grief. This is absolutely amazing, considering how much it streamlines the coding process. If I need a callback function, I can write it where and when I need it. Recently, though, I've noticed myself slipping on some of the more fundamental aspects of SE...
Particularly, the finer grains of encapsulation/"granulation" - having the ability to write functions inline has given me the nasty habit of re-writing code in a bunch of places, where I need it. It's good that I've caught myself early enough to force myself into good practices.

CSS Fundamentalists

During the last week of the spring semester, I was roped into several heated conversations regarding web development. In all of these conversations, people somehow managed to get me to argue on the side of tables versus divs & css.
To me, having a good deal of practical web development experience, these "CSS fundamentalists" are scary. Now, you might call me pretentious, but web developers are not necessarily going to be good programmers, and likewise, good programmers may not always make the best web developers. However, there is one paradigm that I believe web developers and programmers alike can agree with: less work + stable result is always going to be a goal to strive for. In every one of these arguments, I had to bring up the issue of visual consistency. I've worked cross browser, cross platform, to try and get things to look the same on every browser I test on. In every case, a table will produce a more consistent result than a Div/CSS approach. I brought this point up, and the CSS fundamentalist would bring up two or three possible solutions using divs, and more CSS. Of course, the more points I brought up, the more css they suggested, and the less likely it was to work on a variety of platforms.

The bottom line is, CSS is more work, for a less stable result. The only reason these people insisted on using it was because tables were "obsolete" ... which is a fairly arbitrary and unsubstantiated thing to claim, seeing as how they are still supported under W3C standards, HTML 5, and XHTML 1.0 Strict...

There are two valid arguments that I heard against using tables in design:

Tables were not meant for GUI design - Tables were meant to hold tabular data. This is a valid point, but then again, there isn't a whole lot designated in HTML or XHTML standards specifically intended to cater to GUI design. Every tag is meant to hold a specific, well-formed piece of data in the document. HTML as a whole was nothing more than a document formatting language to begin with, and it's only through hacking and adaptation that it has become so adept at GUIs.
Tables are not well supported by mobile browsers - Alright, you've got me there. Tables force a lot of scrolling in mobile browsers, whereas an extremely well thought out Div/CSS layout will automatically be collapsed to a simple, vertically scrollable format. However, if enough of your viewer base is going to be using mobile browsers, you've probably already got a mobile version of your site, specifically designed with minimal extraneous data. There's no need to sacrifice consistency on desktop browsers for the sake of a mobile browser.

Also, speaking from a perspective of practicality, W3C standards are largely useless. Half of them aren't even properly implemented by the browsers used by the majority of the world. It doesn't matter if you've done something right, if it doesn't work on the client's browser. Yes, there will eventually be a day when all browsers can pass the acid test on standards, and when standards evolve to support all platforms and content types in a way that doesn't fail so hardcore. In the meantime, I'll be keepin' it real with my tables.