Professional Web Applications Themes

php oop .. slightly ot - PHP Development

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

  1. #1

    Default php oop .. slightly ot

    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


    Chris Mosser Guest

  2. #2

    Default Re: php oop .. slightly ot

    With total disregard for any kind of safety measures "Chris
    Mosser" <cmossercomcast.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.....
    Phil Roberts Guest

  3. #3

    Default Re: php oop .. slightly ot


    "Chris Mosser" <cmossercomcast.net> wrote in message
    news:pZCdnXkgDaXRic2iU-KYgwcomcast.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.


    powerboy Guest

  4. #4

    Default Re: php oop .. slightly ot



    "André Nęss" <andrena.spamreallysifi.uio.no> wrote in message
    news:bipuqk$re5$1maud.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


    Chris Mosser Guest

  5. #5

    Default Re: php oop .. slightly ot

    "Chris Mosser" <cmossercomcast.net> wrote in message news:<pZCdnXkgDaXRic2iU-KYgwcomcast.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 ([url]www.publicdomainsoftware.org[/url]) 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
    [email]lkrubnergeocities.com[/email]
    [url]www.krubner.com[/url]
    lawrence Guest

  6. #6

    Default Re: php oop .. slightly ot

    "lawrence" <lkrubnergeocities.com> wrote in message
    news:da7e68e8.0308302051.66fef1e3posting.google.c om...
    > "Chris Mosser" <cmossercomcast.net> wrote in message
    news:<pZCdnXkgDaXRic2iU-KYgwcomcast.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 ([url]www.publicdomainsoftware.org[/url]) 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
    > [email]lkrubnergeocities.com[/email]
    > [url]www.krubner.com[/url]

    thankyou for your view
    --
    Chris Mosser


    Chris Mosser Guest

Similar Threads

  1. New and Slightly Confused...
    By Wilvis in forum Macromedia Freehand
    Replies: 1
    Last Post: February 27th, 05:43 PM
  2. [Slightly OT] Is there a way?
    By e n | c k m a in forum PHP Development
    Replies: 1
    Last Post: November 12th, 11:22 PM
  3. QT version, slightly OT
    By magnax in forum Macromedia Director Lingo
    Replies: 2
    Last Post: September 11th, 12:12 PM
  4. slightly ot
    By Chris Mosser in forum PHP Development
    Replies: 2
    Last Post: August 1st, 07:31 AM
  5. slightly ot: webcam
    By Martin h in forum PHP Development
    Replies: 3
    Last Post: July 24th, 09:03 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139