[campsite-dev] module development and variable name space - Newscoop Development Discussions on Sourcefabric Forum

import

i don't know if 'variable namespace' is the right wording, but we should
start thinking about this, as we are now starting to develop long term
third party modules such as log analyser and print box, which need to
interact with campsite admin and/or the template parser. here some thoughts
and a start for discussion:

Using dedicated variable namespace

With opening campsite to third party module development, we should consider
something that helps to preserver namespaces for each module. One solution
would be to invent an array called $MODULE['modname'] with 'modname' being
the name of the module, such as "printbox". Then this array will be
serialized by campsite and written to the session by the end of each page
call,a s well as unserialized at the beginning if found as part of the session.

Inside this $MODULE['modname'], every module developer can do what he or
she wants to do with their variables.

Micz Flor - micz@mi.cz

content and media development http://mi.cz
-----------------------------------------------------------------
http://www.campware.org -- http://crash.mi.cz -- http://sue.mi.cz
"Und damit bin ich immer noch billiger als ein Fachlabor."
(Ole Broemme)
-----------------------------------------------------------------

------------------------------------------
Posted to Phorum via PhorumMail

import

Things brings up another topic which I have been working on - the
Campsite API. You made me realize we probably need to try to keep our
class names unique. Currently we have classes like "Article.php", which
we should probably rename to something like "Camp_Article.php". Comments?

Micz, as for your idea, it sounds like a module needs to be able to
register a callback with campsite so that it can do things at the
beginning of a page call and at the end of a page call. I wouldnt want
to assume what a module needs to do at each of these points (such as
serializing an array). As a separate issue, having a $MODULE["modname"]
might be a good idea because it would encourage people to put their
variables in it instead of in the global namespace.

- Paul

Micz Flor wrote:
> i don't know if 'variable namespace' is the right wording, but we should
> start thinking about this, as we are now starting to develop long term
> third party modules such as log analyser and print box, which need to
> interact with campsite admin and/or the template parser. here some
> thoughts and a start for discussion:
>
>
> Using dedicated variable namespace
>
> With opening campsite to third party module development, we should
> consider something that helps to preserver namespaces for each module.
> One solution would be to invent an array called $MODULE['modname'] with
> 'modname' being the name of the module, such as "printbox". Then this
> array will be serialized by campsite and written to the session by the
> end of each page call,a s well as unserialized at the beginning if found
> as part of the session.
>
> Inside this $MODULE['modname'], every module developer can do what he or
> she wants to do with their variables.
>
>
> Micz Flor - micz@mi.cz
>
> content and media development http://mi.cz
> -----------------------------------------------------------------
> http://www.campware.org -- http://crash.mi.cz -- http://sue.mi.cz
> "Und damit bin ich immer noch billiger als ein Fachlabor."
> (Ole Broemme)
> -----------------------------------------------------------------
>

------------------------------------------
Posted to Phorum via PhorumMail

import

At 17:32 09.11.2004, you wrote:
>Things brings up another topic which I have been working on - the Campsite
>API. You made me realize we probably need to try to keep our class names
>unique. Currently we have classes like "Article.php", which we should
>probably rename to something like "Camp_Article.php". Comments?

yes, heaps Wink

currently campsite has the tree structure inside /priv/ that
reflects in some way the functionality. i would suggest that we will come
up with

a) a structure where each module has a separate folder somewhere inside
/priv/ -> that's your namespace. it's unique!

b) that folder name sets the name by which all classes and functions should
start developed for this modules, e.g. 'PopUpload_RegisterFileType' or
'EditArticle_AddTopic' if that would make sense

c) base modules of campsite have one folder, third party modules another
folder. so, what does that do to our namespace? i would suggest that we
make the names even longer and ad CS_ to all base classes, modules and
whatever. that would make it even easier for the big SUPERKONTENTOR to
merge different developments into one big beast, as there are bound to be
overlaps in the class names.

i would rather have long names for classes and functions than abreviations.
this is not a tiny php routine to add a URL to an online bookmark list.
especially not anymore when we invite external developers to write modules
with an API laid out by us.

>Micz, as for your idea, it sounds like a module needs to be able to
>register a callback with campsite so that it can do things at the
>beginning of a page call and at the end of a page call. I wouldnt want to
>assume what a module needs to do at each of these points (such as
>serializing an array).

if there is a way to globalise that $MODULE array, i thougt it could sit in
the index.php of the admin interface like this:

at the beginning:

session_start();
// get the environment variables into an array
if (isset($_SESSION['module'])) {
$MODULE = $_SESSION['module'];
}

NOW IT IS AVAILABLE TO ANY MODULE CALLED FROM INDEX.PHP

and in the end:

/**
* FINISH WITH SESSION
* write the environment to the session
*/
// all the module data
if (!empty($MODULE)) {
$_SESSION['module'] = serialize($MODULE);
}

would that work?

>As a separate issue, having a $MODULE["modname"] might be a good idea
>because it would encourage people to put their variables in it instead of
>in the global namespace.

yes. they if they use the API standard, they become approved modules. if
they go their own route, the become external modules

>- Paul
>
>
>Micz Flor wrote:
>>i don't know if 'variable namespace' is the right wording, but we should
>>start thinking about this, as we are now starting to develop long term
>>third party modules such as log analyser and print box, which need to
>>interact with campsite admin and/or the template parser. here some
>>thoughts and a start for discussion:
>>
>>Using dedicated variable namespace
>>With opening campsite to third party module development, we should
>>consider something that helps to preserver namespaces for each module.
>>One solution would be to invent an array called $MODULE['modname'] with
>>'modname' being the name of the module, such as "printbox". Then this
>>array will be serialized by campsite and written to the session by the
>>end of each page call,a s well as unserialized at the beginning if found
>>as part of the session.
>>Inside this $MODULE['modname'], every module developer can do what he or
>>she wants to do with their variables.
>>
>>Micz Flor - micz@mi.cz
>>content and media development http://mi.cz
>>-----------------------------------------------------------------
>>http://www.campware.org -- http://crash.mi.cz -- http://sue.mi.cz
>>"Und damit bin ich immer noch billiger als ein Fachlabor."
>>(Ole Broemme)
>>-----------------------------------------------------------------

Micz Flor - micz@mi.cz

content and media development http://mi.cz
-----------------------------------------------------------------
http://www.campware.org -- http://crash.mi.cz -- http://sue.mi.cz
"Und damit bin ich immer noch billiger als ein Fachlabor."
(Ole Broemme)
-----------------------------------------------------------------

------------------------------------------
Posted to Phorum via PhorumMail

import

Thinking more about the $MODULE idea :

I'm thinking we should use a singleton class instead of a raw array for
this feature. Under the hood we could use the $MODULE["modname"] if
we want. (Though we might want to use $CAMP_MODULE instead for the
name.) This class would allow interaction between modules and provide
an easy way to find out which modules are installed. Any module would
inherit from the Camp_Module class. Here is a really rough sketch. I'm
sure we can do a lot more with it:

class Camp_ModuleManager {
var $m_moduleObjects = array();

function Camp_ModuleManager() { }

function registerModule($p_campModule) {
$this->m_moduleObjects[$p_campModule->getName()] =
$p_campModule;
}

function getAllModules() {
return array_keys($this->m_moduleObjects);
}

function getModule($p_name) {
return $this->m_moduleObjects[$p_name];
}

function beginRequest($p_request, $p_session, $p_files) {
// go through all the modules
foreach ($this->m_moduleObjects as $mod) {
$mod->beginRequest($p_request,
$p_session, $p_files);
}
}

function endRequest($p_request, $p_session, $p_files) {
// go through all the modules
foreach ($this->m_moduleObjects as $mod) {
$mod->endRequest($p_request,
$p_session, $p_files);
}
}
} // class Camp_ModuleManager

class Camp_Module {
// Developers who create a campsite module
// should extend this class.
// The class will automatically contain its variables,
// thus eliminating the need for a global array.

var $m_name;

function Camp_Module($p_name) {
$this->m_name = $p_name;
}

function getName() {
return $this->m_name;
}

function beginRequest($p_request, $p_session, $p_files) {
// call back at beginning of page request
}

function endRequest($p_request, $p_session, $p_files) {
// call back at end of page request
}
}

- Paul

Micz Flor wrote:
> i don't know if 'variable namespace' is the right wording, but we should
> start thinking about this, as we are now starting to develop long term
> third party modules such as log analyser and print box, which need to
> interact with campsite admin and/or the template parser. here some
> thoughts and a start for discussion:
>
>
> Using dedicated variable namespace
>
> With opening campsite to third party module development, we should
> consider something that helps to preserver namespaces for each module.
> One solution would be to invent an array called $MODULE['modname'] with
> 'modname' being the name of the module, such as "printbox". Then this
> array will be serialized by campsite and written to the session by the
> end of each page call,a s well as unserialized at the beginning if found
> as part of the session.
>
> Inside this $MODULE['modname'], every module developer can do what he or
> she wants to do with their variables.
>
>
> Micz Flor - micz@mi.cz
>
> content and media development http://mi.cz
> -----------------------------------------------------------------
> http://www.campware.org -- http://crash.mi.cz -- http://sue.mi.cz
> "Und damit bin ich immer noch billiger als ein Fachlabor."
> (Ole Broemme)
> -----------------------------------------------------------------
>

------------------------------------------
Posted to Phorum via PhorumMail

import

see, that's why we love those boys on the dev list...

At 18:10 09.11.2004, you wrote:
>Thinking more about the $MODULE idea :
>
>I'm thinking we should use a singleton class instead of a raw array for
>this feature. Under the hood we could use the $MODULE["modname"] if we
>want. (Though we might want to use $CAMP_MODULE instead for the
>name.) This class would allow interaction between modules and provide an
>easy way to find out which modules are installed. Any module would
>inherit from the Camp_Module class. Here is a really rough sketch. I'm
>sure we can do a lot more with it:
>
>class Camp_ModuleManager {
> var $m_moduleObjects = array();
>
> function Camp_ModuleManager() { }
>
> function registerModule($p_campModule) {
> $this->m_moduleObjects[$p_campModule->getName()] =
> $p_campModule;
> }
>
> function getAllModules() {
> return array_keys($this->m_moduleObjects);
> }
>
> function getModule($p_name) {
> return $this->m_moduleObjects[$p_name];
> }
>
> function beginRequest($p_request, $p_session, $p_files) {
> // go through all the modules
> foreach ($this->m_moduleObjects as $mod) {
> $mod->beginRequest($p_request,
> $p_session, $p_files);
> }
> }
>
> function endRequest($p_request, $p_session, $p_files) {
> // go through all the modules
> foreach ($this->m_moduleObjects as $mod) {
> $mod->endRequest($p_request,
> $p_session, $p_files);
> }
> }
>} // class Camp_ModuleManager
>
>
>class Camp_Module {
> // Developers who create a campsite module
> // should extend this class.
> // The class will automatically contain its variables,
> // thus eliminating the need for a global array.
>
> var $m_name;
>
> function Camp_Module($p_name) {
> $this->m_name = $p_name;
> }
>
> function getName() {
> return $this->m_name;
> }
>
> function beginRequest($p_request, $p_session, $p_files) {
> // call back at beginning of page request
> }
>
> function endRequest($p_request, $p_session, $p_files) {
> // call back at end of page request
> }
>}
>
>- Paul
>
>
>Micz Flor wrote:
>>i don't know if 'variable namespace' is the right wording, but we should
>>start thinking about this, as we are now starting to develop long term
>>third party modules such as log analyser and print box, which need to
>>interact with campsite admin and/or the template parser. here some
>>thoughts and a start for discussion:
>>
>>Using dedicated variable namespace
>>With opening campsite to third party module development, we should
>>consider something that helps to preserver namespaces for each module.
>>One solution would be to invent an array called $MODULE['modname'] with
>>'modname' being the name of the module, such as "printbox". Then this
>>array will be serialized by campsite and written to the session by the
>>end of each page call,a s well as unserialized at the beginning if found
>>as part of the session.
>>Inside this $MODULE['modname'], every module developer can do what he or
>>she wants to do with their variables.
>>
>>Micz Flor - micz@mi.cz
>>content and media development http://mi.cz
>>-----------------------------------------------------------------
>>http://www.campware.org -- http://crash.mi.cz -- http://sue.mi.cz
>>"Und damit bin ich immer noch billiger als ein Fachlabor."
>>(Ole Broemme)
>>-----------------------------------------------------------------

Micz Flor - micz@mi.cz

content and media development http://mi.cz
-----------------------------------------------------------------
http://www.campware.org -- http://crash.mi.cz -- http://sue.mi.cz
"Und damit bin ich immer noch billiger als ein Fachlabor."
(Ole Broemme)
-----------------------------------------------------------------

------------------------------------------
Posted to Phorum via PhorumMail

Howdy, Stranger!

Categories

Poll

Top Posters