2009/4/23 Guoqian Jiang <[email protected]>: > > FYI. > > ________________________________ > Date: Wed, 22 Apr 2009 21:49:32 -0400 > Subject: Re: [Semantic Forms] Re: Version 1.6: category-tree inputs, > 'CreateClass' page, default upload filenames, etc. > From: [email protected] > To: [email protected] > > Hi, > > That's interesting - although I don't know if the screenshots help, since > they show all this Halo stuff. :) > > Could you send that email to the list, though? I'd be curious to know if > anyone else has an opinion on it.
I don't know much about iframe or the implementation details of category tree / SF, however, I do know that category queries can be a massive hit on performance. This seems strange as there are typically only a few categories in a wiki, and the queries should be very fast. Can you explain why querying the category hierarchy is so slow? Is it because you are required to query at the page level? Could this be a MW issue? Cheers, Dan. > -Yaron > > > 2009/4/22 Guoqian Jiang <[email protected]> > > Hi, Yaron, > > For the interface design of category tree-based input, I would suggest to > use iframe you already adoped for upload file. > > I have made a category input based on Halo Ontology Browser working in an > internal wiki and put some screenshots at > > http://informatics.mayo.edu/vkcdemo/lexwiki1/index.php/Semantic_Forms_Enhancement_20090422 > > Not sure if you like the design but I think it may help overcome performance > issue and provide more flexibility (e.g. some users would like to use > autocompletion instead). > > -Guoqian > > > > ________________________________ > Date: Wed, 22 Apr 2009 00:58:02 -0400 > Subject: [Semantic Forms] Re: Version 1.6: category-tree inputs, > 'CreateClass' page, default upload filenames, etc. > From: [email protected] > To: [email protected] > > 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 -~----------~----~----~----~------~----~------~--~---
