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 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

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 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