php oop .. slightly ot

[Chris Mosser]

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.

Here is some example code:

$mod = new Module("Test"); // constructor setting name and Id attributes
$mod -> setBorderWidth( 1);
$mod -> setBorderColor( "#336633");
$mod -> setSize(300, 200);
$mod -> setPosition(50, 50);
$mod -> setFontColor("# 000000");
$mod -> setVisibility(" visible");
$mod -> render("HELLO") ;//creates the opening div (or span) tag and places
the function's argument between that and a closing tag

just trying to get a couple of opinions

--
Chris Mosser

[Phil Roberts]

Re: php oop .. slightly ot

With total disregard for any kind of safety measures "Chris
Mosser" <cmosser@comcas t.net> leapt forth and uttered:
[color=blue]
> 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.
>
> Here is some example code:
>
> $mod = new Module("Test"); // constructor setting name and Id
> attributes $mod -> setBorderWidth( 1);
> $mod -> setBorderColor( "#336633");
> $mod -> setSize(300, 200);
> $mod -> setPosition(50, 50);
> $mod -> setFontColor("# 000000");
> $mod -> setVisibility(" visible");
> $mod -> render("HELLO") ;//creates the opening div (or span)
> tag and places
> the function's argument between that and a closing tag
>
> just trying to get a couple of opinions
>
> --
> Chris Mosser
>
>
>[/color]

To be honest it sounds more than a little over the top.

If you're just using it as a learning exercise then fine, but is
there really any practical application for such a class?

--
There is no signature.....

[powerboy]

Re: php oop .. slightly ot


"Chris Mosser" <cmosser@comcas t.net> wrote in message
news:pZCdnXkgDa XRic2iU-KYgw@comcast.co m...[color=blue]
> As of late I have been finding myself using an oop approach rather[/color]
than a[color=blue]
> procedural one. But, it usually consists of a couple base classes[/color]
and 1[color=blue]
> created specifically for a site. I am currently working on 1 that[/color]
will[color=blue]
> basically be used to create divs (or spans) and the styles used with[/color]
them[color=blue]
> for use in creating cms's. As of now, it is a single class that[/color]
sets css[color=blue]
> properties. I just trying to figure out if I should further break[/color]
down and[color=blue]
> create separate classes for each type of property .. i.e. font,[/color]
border,[color=blue]
> margin .. etc.
>
> Here is some example code:
>
> $mod = new Module("Test"); // constructor setting name and Id[/color]
attributes[color=blue]
> $mod -> setBorderWidth( 1);
> $mod -> setBorderColor( "#336633");
> $mod -> setSize(300, 200);
> $mod -> setPosition(50, 50);
> $mod -> setFontColor("# 000000");
> $mod -> setVisibility(" visible");
> $mod -> render("HELLO") ;//creates the opening div (or span) tag[/color]
and places[color=blue]
> the function's argument between that and a closing tag
>
> just trying to get a couple of opinions[/color]

It'd be much slower than using say some kind of template system, and
the memory usage would be high.

[Chris Mosser]

Re: php oop .. slightly ot



"André Næss" <andrena.spamre allysucks@ifi.u io.no> wrote in message
news:bipuqk$re5 $1@maud.ifi.uio .no...[color=blue]
> Chris Mosser:
>[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
> > and create separate classes for each type of property .. i.e. font,
> > border, margin .. etc.
> >
> > Here is some example code:
> >
> > $mod = new Module("Test"); // constructor setting name and Id[/color][/color]
attributes[color=blue][color=green]
> > $mod -> setBorderWidth( 1);
> > $mod -> setBorderColor( "#336633");
> > $mod -> setSize(300, 200);
> > $mod -> setPosition(50, 50);
> > $mod -> setFontColor("# 000000");
> > $mod -> setVisibility(" visible");
> > $mod -> render("HELLO") ;//creates the opening div (or span) tag and
> > places
> > the function's argument between that and a closing tag
> >
> > just trying to get a couple of opinions[/color]
>
> IMO you are complicating things too much. What is the benefit of your
> current solution? If you can answer that question satisfactory your
> solution might have something to offer, otherwise you should reconsider.
>
> André Næss[/color]

well, seems like all 3 of you are in agreement, and with me being so new to
oop, I wont argue. Thanks for the input.
--
Chris Mosser

[lawrence]

Re: php oop .. slightly ot

"Chris Mosser" <cmosser@comcas t.net> wrote in message news:<pZCdnXkgD aXRic2iU-KYgw@comcast.co m>...[color=blue]
> 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.[/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 "Mainconten t" and "Each"
to the end of each of those types. So, for instance, in our style
sheet we need these entries:

..articleWhole{
}
..articleHeadli ne{
}
..articleMainco ntent{
}
..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@geocit ies.com

https://www.krubner.com

[Chris Mosser]

Re: php oop .. slightly ot

"lawrence" <lkrubner@geoci ties.com> wrote in message
news:da7e68e8.0 308302051.66fef 1e3@posting.goo gle.com...[color=blue]
> "Chris Mosser" <cmosser@comcas t.net> wrote in message[/color]
news:<pZCdnXkgD aXRic2iU-KYgw@comcast.co m>...[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 "Mainconten t" and "Each"
> to the end of each of those types. So, for instance, in our style
> sheet we need these entries:
>
> .articleWhole{
> }
> .articleHeadlin e{
> }
> .articleMaincon tent{
> }
> .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@geocit ies.com
> www.krubner.com[/color]


thankyou for your view
--
Chris Mosser