By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,615 Members | 1,634 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,615 IT Pros & Developers. It's quick & easy.

php oop .. slightly ot

P: n/a
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
Jul 16 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
With total disregard for any kind of safety measures "Chris
Mosser" <cm*****@comcast.net> leapt forth and uttered:
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


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.....
Jul 16 '05 #2

P: n/a

"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.

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


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

P: n/a


"André Nęss" <an*********************@ifi.uio.no> wrote in message
news:bi**********@maud.ifi.uio.no...
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


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


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
Jul 16 '05 #4

P: n/a
"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
Jul 16 '05 #5

P: n/a
"lawrence" <lk******@geocities.com> wrote in message
news:da**************************@posting.google.c om...
"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

thankyou for your view
--
Chris Mosser
Jul 16 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.