Let's take a look at the Semantic MediaWiki FAQ:
We truly believe that there's no other software yet, either free or
proprietary, that enables flexible, collaborative data structures in the
way that Semantic MediaWiki does. [snip]
In the big picture, the real competitor to Semantic MediaWiki is every usage-specific so-called "turnkey" application meant to store a specific type of data. We would like to see the users of many of these applications consider switching to SMW as a cheap, flexible alternative.</quote>
Hi,Sorry, what I meant was just that, at this point in time in the development of SMW, SF and the rest, when there are feature requests that are unusual in some way, my experience is that they can usually be solved more easily, and in a nicer way, with either changes to the data structure, or an alternate approach. Not always, but usually.In your case, given that I now know what you're trying to do (make a dropdown for forms in an "edit category" form), I can suggest a good alternative: you can use "autocomplete on namespace" instead - it'll show autocompletion instead of a dropdown, but on the other hand, if you use it with the "combobox" input type (not available yet in SF, but coming, I believe, later this week :) ), it'll function quite a bit like a dropdown. Though even without the combobox, I'd say that that's probably the best alternative.To the general philosophical issue - every software application ever written lacks features that it would be potentially useful to have; that's just the nature of software (or of life, really).-Yaron--On Tue, Aug 17, 2010 at 8:58 AM, John Arrowwood <John@irie-inc.com> wrote:
What a very interesting response. Let me see if I have this straight: You can't think of any good reason why someone would want to do something, and when someone says they want to, your reaction is to attack their choice of organizing their data? I think the problem may be that you are still thinking wiki, whereas I'm using MediaWiki as a platform for developing a data management system.
So, what is the actual place where I'm trying to do this? I created a Form to help edit Category pages. On the form, I put a dropdown which lists all of the Structured Documents defined in the system. If the user selects a structured document, then the template looks up everything it needs to know from the Structured Document definition page. Likewise, there is a dropdown that lists all of the forms in the system, so you can select the form to use to edit pages in that category (if you didn't select a structured document). The purpose of all of this is to make it easier for non-technical users to define/edit categories.
But the query for forms returns everything looking like: [[:Form:xyz|Form:xyz]], which means that is what shows up in the dropdown. What SHOULD show up in the dropdown is "xyz", as that is all the user needs to see.
But in general, I can think of a million reasons why you would need to populate a dropdown with something other than raw page names.
1. A list of users, displayed as Last Name, First
2. A list of open defects, showing defect ID number followed by the summary
3. All open/active User Stories, listing the user story text
4. A list of teams, taken from their team pages
Bottom-line: There is a very real need to do this kind of thing.
Which means that being "out of luck" means that Semantic MediaWiki is not really ready for prime-time. Is that really the message you want to send to the world?
On Mon, Aug 16, 2010 at 8:05 PM, Yaron Koren <firstname.lastname@example.org> wrote:
Hi,No, you can't do any of these things, so I guess you're out of luck.Personally, I think the fact that you're asking about these might indicate a non-ideal data structure, which is why I was asking about data structure before; but that's a matter of opinion.-Yaron--On Mon, Aug 16, 2010 at 6:30 PM, John Arrowwood <John@irie-inc.com> wrote:
The data structure is not important. What is important is that I want to return something other than a page name. The current method of using a concept as inputs to a dropdown does not accept anything other than a page name. Only the page names are used to populate the dropdown, as best as I can tell...
Imagine it like this: Suppose you had a collection of pages, all in the same category. Suppose you wanted to have a dropdown where the values are the page names, but converted to upper case. How would you do that?
How about if you had a collection of pages and sub-pages, and you wanted to return only the sub-page name, without the base page? How would you do that? So if you had "foo/bar" and "foo/blip" and "foo/goo", and you wanted the dropdown to include the values "bar" and "blip" and "goo". How would you do that?
Or if you had a collection of pages in a particular namespace (other than the main namespace), and because it is redundant to show the namespace name over and over again, you want to show the page name without the namespace. Again, the contents of the dropdown should be populated from a query, but the actual appearance of each item should be something other than the actual page names. It might be, for example, an attribute on the page, or a function executed against the page name.
That is the root of the problem. I tried everything I could find to be able to make that happen. The closest thing I could come up with was putting a query on the property page that used a template to control the allowed values. But as you yourself said, then it doesn't update the values unless you 'edit' the property page. That is not a viable alternative. Neither is having to 'purge' the property page.
So, how does one put user-friendly values in dropdowns that are the result of a query? Or can you?On Mon, Aug 16, 2010 at 5:34 PM, Yaron Koren <email@example.com> wrote:
Hi Alex,John - in a sense, this extension might be helpful for you as well; though I'm always sure there's a better way for you to do whatever it is you're trying to do; though, not knowing your data structure, I don't know what that is.-Yaron--On Mon, Aug 16, 2010 at 1:14 PM, Alex Kozak <firstname.lastname@example.org> wrote:
Has there been any discussion about ways around the data update issue? Maybe there could be a way for SMW to run the data repair/upgrade in the background? I've run into this annoyance countless times. It would be nice not to have to turn off page caching for the whole wiki.AKAlex KozakOn Mon, Aug 16, 2010 at 10:05 AM, Yaron Koren <email@example.com> wrote:
That doesn't sound like a defect - regardless of what you see on the
property page, the actual semantic data (allowed values, in this case)
doesn't get updated until there's some sort of update action taken, like a
In any case, that's not the ideal way to do it - you should instead define
an SMW "concept" that holds that query, and then use either "values from
concept" or "autocomplete on concept" in the form input (probably the
On Mon, Aug 16, 2010 at 12:50 PM, John Arrowwood <John@irie-inc.com> wrote:
> I have a sequence of pages that all have a common base page, "Structured
> Documents". So, for example, I have Structured Documents/Term for the page
> that has the definition of a glossary Term.
> I created a property. The definition of that property includes a query
> returns all of those structured documents, listing only their name without
> the Structured Documents prefix. The idea was that the property will be a
> dropdown on the appropriate form which shows a cleaned-up version of the
> page names.
> The intention is that as soon as I added a new Structured Document, the
> property would update its 'allowed' list, and the new document would appear
> in the dropdown.
> In reality, I have to go to the page for that property, make a meaningless
> change, then click Save in order for the change to be picked up. Even
> though I can go to the page, click Purge, and see the new item in the list,
> that alone is not enough. I have to edit and save before the new item(s)
> appear in the dropdown of a form.
> So the defect is that even though you view the property page and see the
> list of allowed values, the form is not picking up the new list of allowed
> However, the real NEED here is a way of associating a form on a page with a
> queried list of values. Unfortunately, I have tried in vain to do that.
> I put a template call in the default= part of the field definition, it
> treated as a template, and so the user sees it as a template, not as a list
> of values.
> What is the proper way of accomplishing this goal?
> John Arrowwood
> John (at) Irie (dash) Inc (dot) com
> John (at) Arrowwood Photography (dot) com
> John (at) Hanlons Razor (dot) com
> This SF.net email is sponsored by
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> Semediawiki-user mailing list
WikiWorks ˇ MediaWiki Consulting ˇ http://wikiworks.com
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
Semediawiki-user mailing list
WikiWorks ˇ MediaWiki Consulting ˇ http://wikiworks.com
--WikiWorks ˇ MediaWiki Consulting ˇ http://wikiworks.com