"lawrence" <lkrubner@geocities.com> wrote in message
news:da7e68e8.0308302051.66fef1e3@posting.google.c om...[color=blue]
> "Chris Mosser" <cmosser@comcast.net> wrote in message[/color]
news:<pZCdnXkgDaXRic2iU-KYgw@comcast.com>...[color=blue][color=green]
> > As of late I have been finding myself using an oop approach rather than[/color][/color]
a[color=blue][color=green]
> > 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[/color][/color]
them[color=blue][color=green]
> > for use in creating cms's. As of now, it is a single class that sets[/color][/color]
css[color=blue][color=green]
> > properties. I just trying to figure out if I should further break down[/color][/color]
and[color=blue][color=green]
> > create separate classes for each type of property .. i.e. font, border,
> > margin .. etc.[/color]
>
> 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
>
lkrubner@geocities.com
>
www.krubner.com[/color]
thankyou for your view
--
Chris Mosser
