"Chris Mosser" <cm*****@comcast.net> wrote in message news:<pZ********************@comcast.com>...
As of late I have been finding myself using an oop approach rather than a
procedural one. But, it usually consists of a couple base classes and 1
created specifically for a site. I am currently working on 1 that will
basically be used to create divs (or spans) and the styles used with them
for use in creating cms's. As of now, it is a single class that sets css
properties. I just trying to figure out if I should further break down and
create separate classes for each type of property .. i.e. font, border,
margin .. etc.
The important thing is to have a class that contains all the basic
types that show up in your style sheet. After all, the whole thing
with objects is to find what varies and encapsulate it. We're trying
to keep our system modular (
www.publicdomainsoftware.org) which means
other people have to somehow get basic types into that object. For
that reason, I'm thinking of doing something like what you considered,
and have a separate object for every basic type in the style sheet.
When I speak of basic types, I mean we have strings that refer to
stuff like "comments" "navElement" and "article". We then have a
process that adds "Whole" and "Headline" and "Maincontent" and "Each"
to the end of each of those types. So, for instance, in our style
sheet we need these entries:
..articleWhole{
}
..articleHeadline{
}
..articleMaincontent{
}
..articleEach{
}
Whole is a div that wraps the next 3, Maincontent wraps Each, and I
don't assume I know a head of time how many entries there might be in
an array, needing the "each" tag.
Why you'd want a separate object for each property is beyond me, but
you haven't given us enough information for us to figure out if it
makes sense in your architecture. Would object print stuff to the
screen? Rewrite a flat file? Just hold one variable? What? If it only
holds one variable, then it sounds like over kill.
It would be enough for my project to have one object that listed all
the basic types for my cms, but as I want to keep it modular, I need
to make each basic type its own object, so 3rd party developers can
add their own types.
Automating style sheets takes a step down the road to the point where
we can do TopStyle stuff internally, in our cms.
You may wonder why we feel we can get away with whole, head,
maincontent, and each. Our philosophy, which has guided recent
development, is that the display of a web page can be thought of as a
series of iterations. There is almost nothing showing up on screen
that isn't coming from an array that's being iterated over. The only
exceptions are the stuff the graphic designers hardcode into the
template, the img tags that Dreamweaver puts there (most of our
designers work in Dreamweaver to design the pages). But as far as our
code goes, we know we can think of everything as an iteration. For
instance, an article has two parts: title and maincontent, so our four
levels wrap things appropriately (though maincontent and each double
wrap the same content). If we have 20 comments on the page, beneath
the article, then they too, get wrapped the same way, over and over
again, the code iterating over some for() loop.
Sometimes custom css classes are needed, but the above gives us
starting point. Also, not everything uses all four. We end up with a
lot of waste classes that we never really need. But then, I find,
smart graphic designers often amaze me with all the stuff they can do
if you give them a surplus of classes to work with.
For me, moving toward oop design was a 2 step process: at first a I
grouped a lot of stuff in a few gigantic classes. For instance, the
forms class had everything in that had anything to do with forms, both
basic methods for building HTML and advanced functions for building
huge forms in an automated way. The hugeness of the class limited code
reuse. The size was ideal for a package, if only I'd been writing in
Java. If it had been Java, it would have been the form package, and
inside I would have had a top level form class that followed the
Command design pattern, and acted as a wrapper for the other classes.
So then it finally occurred to me that I had to refactor. I haven't
really done any refactoring yet. I've a huge SQL class and a huge
form class, and both I hope to break down to small objects, then use
compositon to hold them together. In breaking them down I open the
possibility of someone using their own object instead of mine. Done
right, it should become more modular. That is the whole point of the
Command design pattern.
take care,
lawrence krubner
lk******@geocities.com www.krubner.com 
