Hi, Alas - I feared that would happen - the performance issues. Unfortunately, I don't know if there's any way around it. CategoryTree uses Ajax to get additional categories at a depth greater than what it initially retrieved, when a user clicks on a "+" sign. Semantic Forms, meanwhile, does some string replacements to add the radiobuttons or checkboxes before each category name in the CategoryTree output. Unfortunately, I don't think it's possible to get SF to do that on additional subcategories retrieved via Ajax. That's why SF gets categories to such a large depth - 10 - because it can only handle categories that were retrieved right at the beginning. Does that mean that the 'category' input, in its present form, is unusable for your wiki?
-Yaron 2009/4/21 Guoqian Jiang <[email protected]> > Yaron, > > This is fantastic. > > I made an installation and tested the category tree inputs. > > There was a performance issue initially. I checked your category tree usage > and noticed that you set the depth to 10 which is probably the reason for > this performance issue. I would suggest set it to 1 or 2 and let user to > expand from top level. However, when I changed the depth number and expanded > the tree and I noticed a side effect that the sublevel categories do not > have a radiobutton attached. > > Anyway, this is a fantastic implementation. Thanks a lot, > > -Guoqian > > > > ------------------------------ > Date: Tue, 21 Apr 2009 20:28:24 -0400 > Subject: [Semantic Forms] Version 1.6: category-tree inputs, 'CreateClass' > page, default upload filenames, etc. > From: [email protected] > To: [email protected] > > > Hi all, > > Version 1.6 of Semantic Forms has been released. This is a fairly major new > version, with a lot of additions and bug fixes. They are: > > - there are now inputs for letting you select a category. Being able to > select a category is a feature that people have requested since almost the > beginning of Semantic Forms, but I always rejected it on the theory that > users shouldn't be adding categories to pages, and that a page shouldn't > belong to more than one category anyway. I still think that's usually the > case, but there are a number of wikis, like LexWiki, that use categories as > inputs because they're the only thing that matches the need: a hierarchical > set of values. It dawned on me that there's no way now, and probably no way > ever, that semantic properties will be able to generate a hierarchical form > input, so that you can, for instance, choose whether to set a car to be of > type "Ford" or "Ford Taurus", with the latter a subset of the former. So, > there are now two new input types for forms that display a category tree: > "category" and "categories". Both use the CategoryTree extension, which must > be installed for these input types to work: > > http://www.mediawiki.org/wiki/Extension:CategoryTree > > The difference between the two input types is that "category" only lets you > select one value, while "categories" lets you select many: the first uses > radiobuttons, while the second uses checkboxes. > > I should note that I haven't changed my opinion, the subject of a recent > thread, that a page should only have one category *that has a default form*. > > - the 'CreateClass' special page was added. This page provides a form for > letting you create all the components of a single "class" - properties, > template, form and category - in one place, at the same time. This should be > helpful for people who want to get a wiki up and running quickly, including > beginning users. It should be noted that the page provides very little > flexibility compared to creating each component separately - you can't have > more than one template in the form, for instance. > > - Samuel Lampa's addition of setting a default filename for file uploads > has been added, with some modifications: if you add the field parameter > "default filename" to an uploadable field, it will set the default name > given to that file. Also, the value of this parameter can include a "<page > name>" variable, which will get substituted with the name of the page being > created or edited. > > - mandatory radiobutton and dropdown fields no longer have a "None" or > blank option show up, if they're set with a default value. > > - remote autocompletion now works for wikis that use the new SMW database > structure (i.e., most SMW wikis). Until now, it always used the old table > structure, for no good reason. > > - a bug was fixed so that the 'Category' namespace can have a default form > associated with it. > > - the time placed in the form for fields with a "default=now" setting is > now set according to the wiki's time zone; thanks to Patrick Nagel for the > fix. > > - if the user is creating a page that has already been deleted once or > more, a warning message, with a list of previous deletions, appears at the > top of the form, just as happens with the regular "edit" tab. > > - if a page has more than one default form associated with it, due to > multiple categories, a warning message appears at the top of the "edit with > form" tab. (This warning doesn't show up if the page has one default form > from its category and a different one from its namespace - category always > supersedes namespace.) > > - the #tooltip parser function defined in SMW now works in forms. > > - a typo introduced in version 1.5 was fixed, for handling form fields not > defined in the template. > > - the extension produces a more helpful error message if SMW is not > installed. > > - language support was added for Veps. > > -Yaron > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Semantic Forms" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/semantic-forms?hl=en -~----------~----~----~----~------~----~------~--~---
