Understanding modules

fulldecent

Joined: 2006-01-03
Posts: 4
Posted: Tue, 2006-01-03 22:34

Hey all!

I'm a developer of a 100% competing project, Camera Life, and am looking to understand design considerations made in G2 to possibly adopt in my project. I began digging into the code, however, this did not help in answering some of the bigger questions.

In my case, I am starting to abstract some of the functionality in CL and support multiple backends for features I am also trying to update to OO design as I learn about OO PHP :-)

All modules in G2 seem to look alike, they all inherit directly from GalleryModule. How do you know if a certain functionality is included with the installed modules? Like how do you know if you have a module that will handle GD-like behavior if you don't have a ImageProcessing module that they all inherit from?

Are all 46 modules include'ed for every page load? How do you know what modules you need to load for a given task?

What is the benefit of having a database handler inherit from the same base class as a database abstraction class?

Is SQL abstracted as a "data access" layer before the database connection abstraction? Or a better question, does Gallery require something that understands a SQL-like language, or will it work fine with an XML backend?

Thanks for your consideration of these questions,
Will Entriken
 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Tue, 2006-01-03 23:16

Hi Will,

Rather than remodelling your application why not join the G2 project and add missing features from your project to G2 (e.g. logging, rollback or even extend it to full-fledged versioning)? :)
There's of course room enough for many PHP based web photo album applications - and there are a lot - but Gallery 2 would profit a lot from dedicated developer like you. As for your project, much work went into G2 and it still requires a lot of work to make it feature complete, refactor it etc. So if you have suggestions on how to improve the framework or some modules, you're welcome to actively contribute / help improve the framework.

@Modules:

Quote:
How do you know if a certain functionality is included with the installed modules?

module register what they offer during module installation/activation time and they offer callbacks etc.

Quote:
Like how do you know if you have a module that will handle GD-like behavior if you don't have a ImageProcessing module that they all inherit from?

gd, imagemagick, netpbm and other image tookit modules register during module activation time what mimetypes and what operations they can handle.

Quote:
Are all 46 modules include'ed for every page load? How do you know what modules you need to load for a given task?

no, not all modules are included / loaded for each request.
1. the first filter is of course that only active modules are candidates to being included / loaded
2. since we know which modules provide what, only modules that are actually needed for a specific request loaded when they are needed

Quote:
What is the benefit of having a database handler inherit from the same base class as a database abstraction class?

are you referring to MysqlDatabaseStorage.class which extends the DatabaseStorage.class ? you'll find a few things in MysqlDatabaseStorage.class that are specific to mysql, like the optimize statement, advanced / sql / non-standard sql syntax statements, etc.

Quote:
Is SQL abstracted as a "data access" layer before the database connection abstraction? Or a better question, does Gallery require something that understands a SQL-like language, or will it work fine with an XML backend?

our storage query language is basically SQL, with some small changes.
table / column names are class / member names instead. non standard SQL syntax is abstracted a little.
but it's more like SQL than anything else. it's too narrow to SQL to use it for XML.
we'll add a flat-file based SQL storage maybe later, maybe php's sqlight. but adding a non-SQL backend is not on our agenda, it's just not worth it.

keywords: http://sourceforge.net/projects/fdcl / Camera Life
 
fulldecent

Joined: 2006-01-03
Posts: 4
Posted: Wed, 2006-01-04 16:13

Valiant,

Versioning sounds like a cool idea, and yet so easy to do - thanks for the idea! As for the modules, let me summarize to make sure I understand:

* During a setup stage, or when modules are added / removed, a database table is set up to know which modules exist and what functionality they provide, using callbacks
* When the user calls a page, it first determines what functionality it needs; then it calls a setup function that examines which modules are enabled, any preferences the user has, and includes the modules
* The modules derive from base clases that prototype the functionality that is required
* The setup function instantiates these derived classes that were just included
* The user page uses this instantiation with its base class functions to perform the desired operation

Is this basically what is going on?

Thanks,
WE
 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Wed, 2006-01-04 16:43
Quote:
Versioning sounds like a cool idea, and yet so easy to do - thanks for the idea! As for the modules, let me summarize to make sure I understand:

I take this as a no thanks :)

@Modules:
More or less. The details are not that important since every implementation of plugins/extensions/modules can be different.
And in the end, G2 is GPL, so nothing prevents you from copying some patterns / code into your own GPL application.
 
fulldecent

Joined: 2006-01-03
Posts: 4
Posted: Fri, 2006-01-06 00:19

Not a "no thanks" yet. I appreciate the help in this design consideration. I'd like to make my system more OO-aware. Ideally, I could pull some functionality out into modules. Assuming I create a similar module implementation, I am thinking it would be easy to port modules between the two systems. At that time, you could definitely expect me as a module contributor.

As far as logging support - that is a more intricate system to implement. However, the rollback feature, with checkpointing, can be done from a module.