× Warning! This forum is in archival status. New contributions may not work.
[campsite-dev] module development and variable name space
  • 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
  • 4 Comments sorted by
  • 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
  • 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
  • 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
  • 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