Greetings,

I'm writing yet another web-calendar app (mainly as a learning exercise). To gain a little php sophistication, and (hopefully) to learn a bit about best practices, I'm trying to work it out as an object-oriented application (as far as php permits).

So, I have broken down the actual functions of the application into [list=1]
Date determinations & calculations
Calendar-drawing operations (i.e. draws the month tables, navigation links etc)
(For the near future) Database query functions
[/list=1]

So far, everything is just ducky ;) My question has to do with classes: should I - [list=1]
Make the calculation part a class and extend it with the drawing & db logic when it's called on a page?
Make the drawing functions part of the class?
[/list=1]

Sorry if the question is slightly incoherent - it was easy to create a bunch of functions to do the job, but I'm a little fuzzy on OO programming in php...

TIA,

B

Generally, you want your objects to be cohesive 'things' to interact with. I would probably put the calculations in the Calendar class. Probably the query tasks, too, so I can do something like $month->getDaysEvents(14).

I would not pollute the class with implementation-specific details like HTML rendering.

I would agree.

As much as you can, get the display stuff out of of your class, make it so that the core functionality is in there, but nothing implementation specific. That way, you can use the same class in other scripts without having to mess with the output code (as in formatting, etc.)

Thanks,

That's what I had guessed would be appropriate. I'd already removed most of the display stuff, and placed it in a stylesheet. At this point I'll remove it entirely from the main class.

Should I then make it into its own (separate) class and use it to extend the hypothetical 'calendar class'? Or should I approach this part another way?

well what you can do is create a "calendar_printing" class that uses the calendar "code" class to create some generic calendars.

Like, a table based calendar that shows the current month. Such a function could have a signature like this :

function calprint($style,$type)

where $style points to a stylesheet, and $type defines the kind of calendar you want.

sample call :


$foo = new calendar_printing();
$foo->calprint("/home/styles/cal/blue_month.css", "6 month");


etc.

Try not to get too much of the output stuck in the function though. A better way to make your calendar class more "portable" is to use a template system for the calendars. That way a potential user just needs to edit a template, rather than go mucking about in your source editing echo statement (bad, bad idea).

hth

Hey, thanks.

That's close to the way I'm approaching it (after having read the 2 previous replies).

At this instant, the calendar drawing function contains some html 'echoes', but only TABLE, TH, TR, TD tags - there are no attributes in the table that's created, except for styles (ie 'class="foo-bar"'). When I actually get to the event logic, I'll have it vary the class of the table cell etc. so that the user can control the look of things that way. I think - if I can devise an economical way to accomplish it - I might make functions that write the html, although I don't know, I'm not sure if it makes altering the output easier, or less flexible... Still, a month display is always gonna be a table, I think...

The way it's set up so far, the user can't change the name of the styles, but he can change the stylesheet. I figure that anyone using this thing can call a stylesheet with the basic calendar styles and, if necessary, override it with another stylesheet on the page. That way, the script never explicitly refers to any stylesheet.

Thanks everyone, for the advice.

B