Re: [Semediawiki-user] Fwd: creating a category via a template

[Michael G. <mg...@gr...>]

On Sun, Feb 14, 2010 at 20:31, Yaron Koren <ya...@gm...> wrote:
> Hi,
> Sorry for not having responded sooner. Being able to pass a "hideroot=on"
> value would solve this particular problem; I'm just not convinced that it's
> necessary. The 'category' and 'categories' inputs are supposed to handle a
> hierarchy of values. In the case of your wiki, you could have the top
> category be called something like 'General' instead of 'Subject Area', which
> could be one solution: it could let issues that didn't fit into any of the
> defined values be categorized as well. An even better solution might be not
> to use categories at all: given that none of these categories currently have
> sub-categories, you could replace the whole thing with a new property/field,
> maybe called "Topic", that had all of these as "allowed values". Of course,
> if any of these categories did get sub-categories later, that wouldn't work.
> On that note, it looks like two of those categories "belong to" themselves,
> which leads to the recursive display in the category tree: you should
> probably remove that.

Hmm, I thought about what you said about renaming Subject Area to
General and I can see your point but it's not the way we've been using
the category tree.  I would agree with you more if General applied to
all categories below it but that's not really the case here.  It's a
sort of catch-all where it doesn't apply directly to anything else.

Would it be difficult to pass in these parameters into the category
tree widget?  I have confirmed changing this line does work:

    $tree = efCategoryTreeParserHook($top_category, array('mode' =>
'categories', 'depth' => 10, 'hideroot' => 'on'));

> "mandatory" failing for the "categories" input: that looks like a bug in SF.

Yes, or a mis-interpretation.  I can see it's not totally clear that
if you mark it as mandatory that that would mean you need to check at
least one box.  That's my interpretation though.  Is that something
that's within your code?

> Having "no subcategories" show up: yes, it's kind of annoying. I didn't
> think this was possible to remove via a CategoryTree setting of some kind,
> though I could be wrong: do you know of a specific way to do this?
> Otherwise, it could be that the easiest way to remove this, for now, is to
> edit the page "MediaWiki:Categorytree-no-subcategories".

Not sure what you mean.  I see where to edit the CategoryTree source.

I tried changing the mode to something other than 'categories' and
that didn't help much, so you are correct, the way to fix this is
elsewhere.  It doesn't print the 'no subcategories' when the bottom of
the tree is a page, but it does do it if the bottom node is a category
itself.  I will follow that up with the CategoryTree folks.

> -Yaron
>
> On Sun, Feb 14, 2010 at 4:51 AM, Michael Grant <mg...@gr...> wrote:
>>
>> Thanks Simon, I seem to have the templates working.  What's not
>> working the way I want is the way it presents the category tree.
>>
>> You can see what it does here:
>>
>> http://issues.ni4d.us/index.php?title=Special:AddData/Issue/Category:Test
>>
>> It presents a category tree that looks something like this:
>>
>> [-]  [ ] Subject Area
>>  [-] [ ] Anthropology
>>   no subcategories
>>  [-] [ ] Archeology
>>   no subcategories
>>  [-] [ ] Civil Engineering
>>   no subcategories
>>  [-] [ ] Civil Rights
>> ...
>>
>> Now the first thing wrong with this is that Subject Area itself (the
>> root) is included in the category tree.  This does not make a lot of
>> sense.  I'm trying to get the user to select a particular subject
>> area.  What I need to do is somehow pass the hideroot="on" to the
>> CategoryTree widget but I don't see a way to do that. I tried the
>> obvious thing of adding that to the parameters:
>>
>>  {{{field|Categories|input type=categories|top
>> category=Subject_Area|height=200|hideroot="on"}}}
>>
>> but it didn't work.  I tried it without the ="on" as well (only
>> hideroot).  So it would appear that these extra parameters are not
>> being passed to the CategoryTree widget itself.
>>
>> I did try making it mandatory by adding the mandatory keyword but it
>> didn't actually have any effect with the categories (plural) form.
>> Mandatory to me would mean "check at least one box".  It seems to
>> completely ignore the mandatory keyword.
>>
>> Lastly, you will notice that the category tree is showing nicely
>> unfolded.  However, at the bottom of each branch of the tree it puts
>> "no subcategories".  I can't seem to find a way to stop it from doing
>> that.  It's annoying.  This may be fixable by passing the mode
>> parameter to the CategoryTree.
>>
>> In summary, two of my problems might be solvable if the Categories
>> template type would pass parameters to the underlying CategoryTree
>> (maybe I'm not passing them correctly?) and the third, the 'mandatory'
>> parameter, in the case of CategorIES, should check that at least one
>> box is checked.
>>
>> Michael Grant
>>
>>
>> ------------------------------------------------------------------------------
>> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
>> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
>> http://p.sf.net/sfu/solaris-dev2dev
>> _______________________________________________
>> Semediawiki-user mailing list
>> Sem...@li...
>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>
>
>
> --
> WikiWorks · MediaWiki Consulting · http://wikiworks.com
>