Re: [Phpgroupware-developers] trying to get into the source

[Dave Hall]

Hey Bradley

"Bradley W. Langhorst" <address@hidden> wrote:

> I've built a doxygen tree and am trying to get a handle on why the 
> ldapbackend doesn't work (and hopefully fix it).  Unfortunately 
> doxygencan't follow CreateObject instantiations so, for example, 
> it's tough to
> figure out what is instantiating uicalendar.

Ok thanks for that offer ... go for it.

> 
> Is there some kind of design document somewhere?

The is inline docs ... have a look at http://myserver.com/phpgroupware/

> 
> if not maybe sombody can answer these questions for me...
> 
> what does bo stand for?

bo - business object ... this contains all the business logic

> what does so stand for?

so - storage object ... this is all the storage logic ... it links to
the objects in the api ... such as db, mail, ldap, vfs etc

> 
> 
> it looks like this is what happens when a user requests a calendar
> does this seem right?
> where does the users dropdown get instantiated? in get_grants?
> index.php ->
> includes header.php.inc
>    includes other stuff that draws the pages...

from what i understand the user drop down in created in the header.inc.php

> 
> uicalendar->
> sets theme
> instantiates a categories dropdown
> instantiates a bocalendar object

sounds right

> 
> bocalendar->
> gets the permissions other users have on this calendar
> determines user (why is this using both POST and GET methods?)

to allow for passing of variables by both methods (i think for links etc)

> determines users group
> gets default and user prefs
> instantiates an socalendar object
> determines date to display
> 
> socalendar->
> determines date, user, filter, and category to be used 
> instantiates an socalendar_ obj
> calls open to get a stream to the db (but never does anything with
> it...)

haven't dug this deep ... sorry

> 
> socalendar_->
> determines which calendar storage mechanism to include
> (but the logic in there only ever includes the socalendar_sql
> function... this seems awkward to me)

this is to allow interfaces to other calendaring systems ... it is
easier to design it like this from the start ... this way other
interfaces can just plug straight in ... and the socalendar_ object
would have some logic to determine which one to use.

> socalendar_sql (subclass of socalendar__)
> sets the user again
> 
> keep in mind that i don't know a lot about php (i do know enough other
> languages that it all looks familiar though)

imo calendar is one of the most complex apps in phpgw ... so you have
jumped straight in at the deep end :)

> 
> thanks for helping me get up to speed...

np

> 
> brad

dave.hall.vcf
Description: Card for <dave.hall@mbox.com.au>