[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Phpgroupware-cvs] CVS: /sitemgr/doc hooks-requirements.txt,1.1,1.1.2.1
From: |
Patrick Walsh <address@hidden> |
Subject: |
[Phpgroupware-cvs] CVS: /sitemgr/doc hooks-requirements.txt,1.1,1.1.2.1 |
Date: |
Fri, 01 Nov 2002 01:27:35 -0500 |
Update of /cvsroot/phpgroupware//sitemgr/doc
In directory subversions:/tmp/cvs-serv18805/doc
Modified Files:
Tag: Version-0_9_14-branch
hooks-requirements.txt
Log Message:
Language updates
Index: hooks-requirements.txt
===================================================================
RCS file: /cvsroot/phpgroupware//sitemgr/doc/hooks-requirements.txt,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -C2 -r1.1 -r1.1.2.1
*** hooks-requirements.txt 14 Sep 2002 08:50:25 -0000 1.1
--- hooks-requirements.txt 1 Nov 2002 06:27:31 -0000 1.1.2.1
***************
*** 41,42 ****
--- 41,115 ----
And that's it.
+
+ Clarifications from the mailing list
+ ------------------------------------
+ Modules will not be using the {?hook=...} syntax. I could perhaps
+ enable something like that as a poweruser alternative, but probably won't.
+ The Contributor, ie the person who is allowed to edit the page, will have a
+ list of modules he/she can add to a page. So in the page editor the page
+ contents would be shown as a list of modules, like so:
+
+ -------
+ Page Name: _________________
+ Page Title: ________________
+ Page Subtitle: _____________
+ -------
+ Module1 [properties] [remove] [move down]
+ Module2 [properties] [remove] [move up] [move down]
+ TextModule [properties] [remove] [move up] [move down]
+ HTMLModule [properties] [remove] [move up] [move down]
+ Module1 [properties] [remove] [move up]
+
+ [add module] [preview page]
+ -------
+ [finished]
+ -------
+
+ So each module would have a properties page where content would be
+ entered or parameters specified or whatever.
+
+ Is this clearer? The TextModule would have a properties sheet that
+ looked like the existing page editor, minus the page title stuff. Please
+ pass this on to Michael. I will try to add this to the requirements doc to
+ make it clearer.
+
+ =======
+
+ OK, I don't have an interface worked up just yet, but you can get started
+ anyway. The interface will be pretty straight forward. You will need to
+ create a file with a single class in it. Later I will let you know what to
+ name the class and the file and how to get them listed as a module (by
+ registering the hook). The class will need to have a couple of functions.
+ One of them will be moduleName(), another will be propertiesList(), and
+ finally and most importantly there will be moduleOutput($properties).
+
+ Nevermind the first two for now. The moduleOutput function will take an
+ array of properties and values of those properties. In the case of the
+ forums app the properties might be what forum to display, whether or not to
+ show the index, show a particular message, how many to show, nested... Etc.
+ For now, just make sure you know what the property names and possible values
+ are. This information will be retrieved by SiteMgr via the propertiesList()
+ function.
+
+ The moduleOutput function will return an array. The array that is
+ returned will depend on the output type. I would prefer to return a class
+ object, but for now just write your class and have it return an array. The
+ array must have a 'displayType' element that takes one of the following
+ values. The rest of the array elements will be dictated by this one value.
+
+ displayType == 'basic'
+ content //standard html
+ DisplayType == 'block' // standard html in a box
+ title
+ content
+ displayType == 'article'
+ title
+ subtitle
+ status
+ submitted-by
+ submitted-date
+
+ And there may be more in the future.
+
+ That's all that is needed to create a module...
+
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Phpgroupware-cvs] CVS: /sitemgr/doc hooks-requirements.txt,1.1,1.1.2.1,
Patrick Walsh <address@hidden> <=