Jørn Wildt
Dealing with Zikula and other interesting stuff
Guppy: Merging Categories/Lists and Publications
-
- rank:
- 12
- registered:
- March 2009
- Status:
- offline
- last visit:
- Posts:
- 0
Since J?rn introduced the most excellent guppy plugin architecture, i've been using it to create what i'll refer to as "publist fields", that is, the ability to list a given pub type's items in a field. Example: in PubType A, i can create a field listing the content of PubType B (pulldown menu). This is extremely cool to recreate a DB environment. J?rn had some reservation about this approach on this (here), but having used it for a few months now, i can say managing large amounts of publications is doable using pulldown menus (500-or-so pubs.).
I'm so enthused about guppy plugins that i've even started to ditch "categories/lists", using "publist fields" allowing way more control (for instance, eases multilanguage maintenance immensely). I even have two versions of it, "single" and "multi", the "regular" stores a single pub's PID, and the "multi" stores a semi-colon separated list of PIDs (using a multiple select).
By using a given PubType's "publist field" on itself - ex.: a field listing PubTypeA's docs within PubTypeA - i even able to generate "categories/lists"'s trees, using that field to select parent node. The only drawback i've encountered at this point is the lack of manual control over the tree structure, which i don't need 90% of the time, alphabetical order being ok most of the time. Another benefit, not using cats/lists restricts the users to regular publications and allows to circumvent the unavoidable mistake of forgetting to "Commit" when modifying a list - admit it, you all got caught a few times :) In fact, i always have some client falling for it on a weekly basis.
This leads to my existential question: is merging Categories/Lists with Publications a remote possibility? The answer is probably "no", manual control over the tree being cats/lists' "raison d'?tre". But i figured i'd throw it out there anyway for the sake of discussion.
Another thousand thanks for such an awesome module,
jeff
-
- rank:
- 12
- registered:
- March 2009
- Status:
- offline
- last visit:
- Posts:
- 0
Very interesting news - thanks a lot. I would like to know if you think the plugins are worth distributing with Pagesetter (I do) - independently of whether categories and publications are merged?
There has been some discussions about how publications should be related to each other, but I haven't seen any "solves it all" ideas yet.
But I do like the idea of just using pulldown menus - then we can always invent a better method for large amounts of publications. And, if you expect to use publications as categories like this, then you probably won't have too many publications.
So I believe categories and publications should live side by side, as I expect they will serve different purposes.
So, if possible, I would appreciate your help if you could make the two plugins ready for distribution. I think that would be a very usefull feature for Pagesetter.
-
- rank:
- 12
- registered:
- March 2009
- Status:
- offline
- last visit:
- Posts:
- 0
Definitely would require some tuning to be used as a generic plugin - i've been adding a plugin per pubtype for now. Plus, i'm definitely not the greatest coder. Relatively simple, here's where the bulk of the work occurs:
Code
class GuppyInput_yourplug extends GuppyInput{
function render($guppy){
[style stuff ...]
// OPTIONAL : i sometime check for URL input,
// useful to preselect option
if( $this->value == "" ){
$this->value = pnVarCleanFromInput("some_id");
}
////////////////GET THE PUBS
if( pnModAPILoad("pagesetter", "user") ){
$args["tid"] = 1;
$args["orderByStr"] = "title";
$args["noOfItems"] = 999; //
$catcher = pnModAPIFunc("pagesetter", "user", "getPubList", $args);
}
// GENERATE THE SELECT
$bag = "<SELECT name=\"" . $this->name . "\" id=\"" . $this->ID . "\" class=\"$htmlClass\" $style >\n";
//OPTIONAL: uncomment the following line to allow root node selection,
// useful in when in a tree-like environment
// $bag .= "<OPTION value='-1'> -- root node -- </OPTION>";
foreach($catcher["publications"] as $i){
$bag .= "<OPTION value='$i[pid]'";
if( $i["pid"] == $this->value ){
$bag .= " selected='SELECTED'";
}
$bag .=">$i[title]</OPTION>\n";
}
$bag .= "</SELECT>";
return $bag;
}
This stores the PID in an INT(11) field
Multiple selection aren'T really more complicated (don't forget the [] in the SELECT to pass the array):
Code
function render($guppy){
// GET THE VALUES
$values = explode(";", $this->value);
...
//GET PUBS
...
$bag = "<SELECT name=\"" . $this->name . "[]\" id=\"" . $this->ID . "\" class=\"$htmlClass\" $style multiple=\"multiple\">\n";
foreach($catcher["publications"] as $i){
$bag .= "<OPTION value='$i[pid]'";
foreach($values as $v){
if( $v == $i[pid]){
$bag .= " selected='SELECTED'";
break;
}
}
$bag .=">$i[title]</OPTION>\n";
}
$bag .= "</SELECT>";
return $bag;
}
Fix the decode function to handle the array:
Code
function decode()
{
foreach( $_POST[$this->name] as $i){
$bag .= "$i;";
}
$this->value = $bag;
// REST OF FUNCTION
}
That's roughly it. I rely a lot on plugins to display user-end infos, but that's pretty much it as far as admin data handling is concerned. Easy huh? In fact, it may be _too_ easy, i get the feeling this may not be exactly what you've been looking for, so don't hesitate to ask more questions; anything to give a little something back.
jeff
-
- rank:
- 12
- registered:
- March 2009
- Status:
- offline
- last visit:
- Posts:
- 0
Cool. Thanks a lot. I have added a link to this topic on my internal todo list. It will probably be part of the 6.2 release.
I can see the problem of choosing a publication type to select from. I'm thinking along the lines of allowing plugins to define sub-types. So each plugin could return a list of possible sub-types and their titles. The optional sub-type parameter would then be passed around to all calls to the plugin. Then the publication type could be the sub-type. But that's for 6.2.
You are very welcome to mail your plugin to me (see bottom of page). Please remember that HTML should be lower case for standards compliancy (although only XHTML I think). If create never version then just mail them too. Thanks.
-
- rank:
- 12
- registered:
- March 2009
- Status:
- offline
- last visit:
- Posts:
- 0
Not a bad idea, and relatively easy to implement; may require a little fine tuning but a quick test shows it works. you can see the code here:
http://obstacle.com/_bin/input.pnusers_multi.txt
This stores the data - users' UIDs in this case - in a semi-colon separated string (ex.: 12;23;11;23). To use in your template, i'd use a smarty plugin, something along the followings lines (note: coding blind, the following is untested):
Code
function smarty_function_pagesetter_getusers ($params, &$smarty)
{
//IN: $uids, our semi-colon separated string
extract($params);
unset($params);
$uids = explode(";", $uids);
foreach($uids as $uid){
$users[] = pnUserGetVars($uid);
}
if (isset($assign)) {
$smarty->assign($assign, $users);
} else {
$smarty->assign("users", $users);
}
}
In your template, the call would look like this:
This would return the array in variable "roster". Then it's just a matter of running a loop through it, kinda like this:
- ( )
Enjoy! jeff
N.B.: hey Ars (Arsch's probably better), i know you know most of this stuff; just figured i'd run through the whole sequence for the benefit of the group :)
[Edited on 10/5/2005 by obstacle]
-
- rank:
- 12
- registered:
- March 2009
- Status:
- offline
- last visit:
- Posts:
- 0
obstacle, thanks for your code in this thread.
I am in need of a way to link one publication to another and am hoping that your solution (or something similar to it) will work for me. My plan was to create previous and next publication fields until I realized that the field type of publication id has not been created yet.
Jorn pointed me to this thread and I am wondering if you would be willing to post a link to the actual source file(s) that you used to create the post above.
This will be my first attempt at a guppy plug in and already appreciating your work in this area.
Tony
[Edited on 5/18/2005 by tjreo]
-
- rank:
- 12
- registered:
- March 2009
- Status:
- offline
- last visit:
- Posts:
- 0
mmmh possible with a plugin, although you may find it to be a little clunky. Here it goes:
1. Download the following plugin, it's a generic and slightly more complete version: http://obstacle.com/_bin/input.generic.txt
2. Change the extension to ".php" and move it into the Guppy plugins folder (modules/pagesetter/guppy/plugins/)
3. Edit the file and change the $tid to the pubtype you want listed (you'll find it on top of the page along with a few other "settable" variables. Let's use $tid=4 for the sake of this example).
4. In Admin > Pagesetter > Pub Types, edit your pubtype and create two fields, "previous_pub" and "next_pub". Of course, you want to set those two fields to your newly created Guppy Field Type, which should show up in the list as "Guppy (tid:4)" (you can change that label by modifying the "title" variable in the plugin).
5. Start using it. Create a new publication, you should see both "previous_pub" and "next_pub" pulldown menu, both listing the publications linked to that publication type.
6. Technically the plugin stores the publication's PID in the field, so using it in your template is relatively easy:
Code
<a href="index.php?module=pagesetter&func=viewpub&tid=4&pid=<!--[$previous_pub]-->">Previous Pub</a>
<a href="index.php?module=pagesetter&func=viewpub&tid=4&pid=<!--[$next_pub]-->">Next Pub</a>
I hope this works for you,
G'luck! jeff :)
[Edited on 19/5/2005 by obstacle]
-
- rank:
- 12
- registered:
- March 2009
- Status:
- offline
- last visit:
- Posts:
- 0
Wow! Thanks obstacle. This plugin is supercool.
I was just looking for a simple way, to let my users attach an infoflyer to items in the calendar list.
With your plugin i can string my calendar pubtype and the document manager together. Amazing!
edit:
Ah... and a last question. Is it possible to use the generic plugin for prev and next publications also with multiple selections? then you could use this plugin easily for context links... maybe to refer to several publications from anaother publication type. that would be nice.
[Edited on 2/6/2005 by Andreas]
[Edited on 2/6/2005 by Andreas]
-
- rank:
- 12
- registered:
- March 2009
- Status:
- offline
- last visit:
- Posts:
- 0
LOL! i should have seen that one coming: i've updated it, still available here (http://obstacle.com/_bin/input.generic.txt). Two new variables: "multiple" and "multiple_size". Pretty self explanatory: when the former is set to true, you will have the possibility of using multiple selections. "multiple_size" set the number of viewable rows.
Note 1: the plugin uses a different field type depending on "multiple"'s value - INT when single, VARCHAR when multiple. So it's preferable not to switch multiple/single on the fly; erase the field and/or create a new one.
Note 2: with "multiple", the values stored are semi-colon separated ( 23;4;34;5;6; - which explains the VARCHAR). You may need to code a quick plugin to use the data. I'll refer you to the plugin in this very thread, an easy enough tweak to have it return a usable array.
g'luck! jeff :)