Deutsch

Current Texts Comic Imprint Calendar Search PHP-Classes Container-Wizard main.s21

Categories

Some Design Notes about "Classes for your pleasure"

Until now, I haven't come up with a proper name for what I put online a few months ago as "Classes for your pleasure".

They are my third generation of an object oriented toolset so far (let's not speak about what existed before, shall we?). The prior generations never made it into a wide public, but the second one was truly successful: a set of classes which would allow me to create web applications really fast. I think the proper name for such a tool would be a "RAD framework".
It was fast, yes, and powerful, but on the other side terribly limited. It stemmed from a particular web-application called "pgCRM", which also never made it into a wide public, and was mostly designed with said pgCRM in mind. Although it worked pretty good to build other webapplications (which are mostly the same, input, validation, output), the classes proved to be too inflexible. Often, I experienced that the toolset would allow me to do about 80% of the work just easy and make the remaining 20% a mess. Which is mostly a problem of user whishes - they want countless exceptions from the rules, can we make this one button green, can we have this one font bold and have a mail receipt here as soon as an user enters something. Yuck. You don't face these problems when doing everything imperative sans any reusable parts, but hell, who wants to wait one year for his application and days for every change request?

I briefly looked into other frameworks, in PHP and other languages. From what I saw, I expected to face the same problems, if not worse. You've got fancy acronyms there, MCV and ORM and whatever. Everything links together and there seem to be big "God classes" that are in charge of everything. Which led me to expand my rule of thumb: I'll have 100% of Framework, of which I will use 20% to have 80% waste my resources while I'll be able to attain 80% of what I want and make the remaining 20% a pain in the ass. Which is added by the fact that these "MCV-driven (or whatever) tools" will force me to follow their approach in whatever I do. No thanks.
Now there are even more horrible things, stuff like Typo 3 which I had the questionable honor to make an acquaintance with. These Titans' are completely out of the scope; I really don't want to have a 48meg footprint for what could possibly be done even with a collection of simple, static websites. The Typo3 people I dealt with so far showed themselves to be terribly incompetent; trying to substitute their lack of hard coding skills needed for doing some database related input-output stuff by completely giving the task to the user managing content with Typo3. But structurized content deserves to be managed by a structurized database. There is only one valid application area for a behemoth like Typo3: a large website mainly consisting of unstructurized data that is to be administered by different editors with different rights.

My primary idea with the class collection is to go away from programming "machines" toward programming their components. Instead of starting with a class "Pump", I'll do a piston, a switch, a hose, a cogwheel, a shell and so on until I've got enough components to build my pump. Having a class Switch will save me time to write the same code over and over again. That is exactly what object oriented programming is perfectly suited for. Often, people will scoff at this approach as being to abstract and gloat about being "pragmatic" and "getting stuff done". Yes, sometimes it is reasonable to be pragmatic. But often enough, I was "pragmatic" and wrote a quick and specific class for a project, only to have a colleague glance on it and say "Hey cool, can't you use that for my project too?".
Extensions are another example. Write the "higher" classes as general as possible while thinking about which methods will most likely be overloaded by extensions. As mentioned, users will be happy with 99 instances of a form and make helluva riot about having a red submit button for the 100th, so it is probably a Good Idea to spend some time thinking about not making it entirely impossible to serve their random wishes.

Another, more general design principle which I keep in mind and which is intertwined with the extension aspect is the aforementioned 80/20 problem. Imagine the different, thinkable needs you may have in the future and which might be solved by a class you're about to code. It is a set of circles, which will intersect in a large area and have a space outside the central circle, the special needs. If you want to care about every possible set of needs, you possible end up with version 4.4.2 of a fat, buggy class which starts to reach the extents of the Linux Kernel. One example is the Wikiparser I wrote - I rewrote it five times until I liked it. I thought about making it possible to have it present tables. Or format images with text-flow attributes. Or have a possibility to change a font scale or color. But no. 99% percent of my text is simple text with paragraphs and breaks. Why mess around reinventing another markup language and writing a parser which will turn my markup into HTML when there is already HTML? So I just added an on and off switch, which gives me a possibility to turn of the parser anytime.

So, while enjoying the automatic ease of just typing in text without having to add <p> and </p> every few minutes, I still keep the full flexibility of basically doing everything I want.
Also, the core wikiparser is quite dump; much of its power lies within user defined callback functions, which are often mere two liners, such as "display image" or "execute script and show result". Especially the latter makes the system very powerful, as I can mix structured (such as a calendar of upcoming events) and unstructured content (such as a collection of texts) with ease.

At the moment, the project is not exactly usable, at least not for the wide public (but imagine what powers my site here). Problem is that I have to few classes online, some are missing yet and I'm still in the process of developing design.
One thing is sure: this ain't gonna be a bloody Framework. Yes, some classes will be designed to work together, and my ultimate goal is to have "kindof" framework with a User object and database mappers and forms and whatever, I won't deliver a readymade concept. An extension of the form class will digest a User object and consider the permissions he has, but you'll be perfectly able to write your own User, or an extension to user, and a extension to form to follow your own approach. Also, this is also meant to be "nondiscriminatory"; possibly, I'll add classes which aren't web centric.

Comments

Please note: comments posted won't be visible immediately, as they will be checked for harmful content.