× Warning! This forum is in archival status. New contributions may not work.
[campsite-dev] API: module development and variable name space
  • paul, do you think you can write these things into a coherent outline for
    the API? frankly, i don't understand a word, so the question is: how much
    more common sense can we supply before this leaves the realm of human
    comprehension and becomes functional?

    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
  • 4 Comments sorted by
  • Yes, I can do that, but I need to know more about how you (and others)
    see modules interacting with the system. Anything that you can supply
    would be extremely helpful. What do modules need from Campsite? They
    have to be able to display things as well, so that has to be
    incorporated somehow...


    Micz Flor wrote:
    > paul, do you think you can write these things into a coherent outline
    > for the API? frankly, i don't understand a word, so the question is: how
    > much more common sense can we supply before this leaves the realm of
    > human comprehension and becomes functional?
    >
    > 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
  • At 18:24 09.11.2004, you wrote:
    >Yes, I can do that, but I need to know more about how you (and others) see
    >modules interacting with the system. Anything that you can supply would
    >be extremely helpful. What do modules need from Campsite? They have to
    >be able to display things as well, so that has to be incorporated somehow...

    ok, you were asking for it Wink here comes from the top of my head... this is
    unrealistic, but i thought i let you know:

    ------------------
    I. something that would be ideal is a *grid* or a matrix where each module
    can say:

    a) what other module it needs
    e.g. all campsite modules need the localizer module.

    b) what other module's functionality it would like to incorporate
    e.g. the edit article module would love to see the image management module
    in place

    c) what module it intends to extend
    e.g. the topics module offers itself to the edit article module, but it
    would also work without it

    --------------------------
    II. each module should indicate which action of the module needs what id
    from the other module
    e.g. the topics module offers to link articles to topics:
    MODULE: topics
    ACTION: link article with topic
    NEEDS: article ID (from any module that supplies it)

    if there was a coherent way of creating such a grid, each module could do
    the following:

    a) see what modules would like to work with me (e.g. topics)
    b) see what information i know (e.g. article ID)
    c) see what the module offers as a link (e.g. "link article to topc")
    d) create a link to the action of the module -> this would then look very
    similar to what we have already, i.e. the links above the article details,
    leading to a sub-routine in topics. and then back to aricle details when
    you want it.

    the advantage: each module could rely on a core functionality of the
    campsite CMS to create such links whereever it feels like it. example:
    images comes up in the table before selecting to see article details (where
    we already have the article ID) and inside the article details (where we
    still know the article ID).

    if we would think it that way, there would be a number of options that
    could come up. whenever i know the article ID, the topics action 'link
    article with topic' could offer itself.

    hope this a) is sensible b) coherent c) worth reading...



    >Micz Flor wrote:
    >>paul, do you think you can write these things into a coherent outline for
    >>the API? frankly, i don't understand a word, so the question is: how much
    >>more common sense can we supply before this leaves the realm of human
    >>comprehension and becomes functional?
    >>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)
    >>-----------------------------------------------------------------


    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
  • Hi guys,

    Here is my view on campsite modules and API; I used here Paul
  • At 13:13 10.11.2004, you wrote:
    >This way we should be able to define a very flexible user interface which
    >changes in accordance to modules installed.

    this would be a perfect goal. especially, if what mugur suggests is
    possible. we will think in terms of future merging of features and software.

    in an ideal world, you would be able to stick together your own CMS modules
    - and it works ("yeah, right, micz and i will be king of germany...")

    i will read it soon and comment. but, as i said before, it starts to leave
    my universe of imagination and becomes a working API Wink will do my best.



    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