First of all I should say that I greatly appreciate Yaron's and others' contributions to Forms, SMW, and related extensions immensely and believe they're quite powerful tools as they are right now. But I also agree with John's sentiments that (on the assumption SMW needs to be competitive to turnkey solutions) SMW/Forms is great at doing a lot of stuff well but can sometimes be inadequate at the "deep dive" applications which require more powerful features. There have been many other times where a feature is "sort of" supported if you go about implementing it in a non-intuitive way.
I think that we as a community of users and developers ought to do a better job of collecting all of these kinds of missing features or functionality requiring hackish solutions so that we can start to see where the gaps are in the tools. I think it would be better for us all if more people were invested in the direction of the SMW extensions. So having said that, Yaron do you have any ideas about the best way to publicly collect feature requests like John's, and do you have any thoughts on how to involve users in developing a "roadmap" for the extensions? - Alex On Tue, Aug 17, 2010 at 3:35 PM, John Arrowwood <j...@irie-inc.com> wrote: > Let's take a look at the Semantic MediaWiki FAQ: > <quote> > What are the alternatives to SMW? > > 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 <http://en.wikipedia.org/wiki/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> > > So, if you want Semantic MediaWiki to be able to compete with 'turnkey' > applications, you are going to have to make it capable of competing. I've > not only USED a lot of those 'turnkey' applications, I've been on the > development teams that have CREATED several of them. > > Don't get me wrong, I agree that sometimes a person's idea of of how to go > about doing something is not necessarily the "right" way of doing it. But > in this case, you are saying that it can't be done, and moreover doesn't > NEED to be done. > > If you seriously want SMW to be a viable alternative to "turnkey" > applications, it has a lot of features that have to be added. A more > powerful query language that can support calculated output is one. > Dependent fields in forms is another. Something that a real developer can > actually build stuff on top of without pulling their hair out is probably > the biggest. > > So, there may not be a solution to my immediate problem. I'm cool with > that, this is a work in progress. But seriously, calculated fields needs > to > get on the roadmap for the future. That is a big, gaping hole in SMW, one > that if it were plugged would make life a whole lot easier for a lot of > people. > > -- John > > > On Tue, Aug 17, 2010 at 11:03 AM, Yaron Koren <yaro...@gmail.com> wrote: > > > 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 <j...@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 <yaro...@gmail.com> 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 <j...@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 <yaro...@gmail.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 < > >>>>> ako...@creativecommons.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. > >>>>>> > >>>>>> AK > >>>>>> > >>>>>> > >>>>>> On Mon, Aug 16, 2010 at 10:05 AM, Yaron Koren <yaro...@gmail.com > >wrote: > >>>>>> > >>>>>>> Hi John, > >>>>>>> > >>>>>>> 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 > >>>>>>> page save. > >>>>>>> > >>>>>>> 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 > >>>>>>> former). > >>>>>>> > >>>>>>> -Yaron > >>>>>>> > >>>>>>> On Mon, Aug 16, 2010 at 12:50 PM, John Arrowwood < > j...@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 > >>>>>>> > that > >>>>>>> > 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 > >>>>>>> > values. > >>>>>>> > > >>>>>>> > 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. > >>>>>>> > If > >>>>>>> > I put a template call in the default= part of the field > definition, > >>>>>>> it > >>>>>>> > isn't > >>>>>>> > 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 > >>>>>>> > -- > >>>>>>> > http://www.irie-inc.com/ > >>>>>>> > http://arrowwood.blogspot.com/ > >>>>>>> > > >>>>>>> > > >>>>>>> > ------------------------------------------------------------------------------ > >>>>>>> > This SF.net email is sponsored by > >>>>>>> > > >>>>>>> > Make an app they can't live without > >>>>>>> > Enter the BlackBerry Developer Challenge > >>>>>>> > http://p.sf.net/sfu/RIM-dev2dev > >>>>>>> > _______________________________________________ > >>>>>>> > Semediawiki-user mailing list > >>>>>>> > semediawiki-u...@lists.sourceforge.net > >>>>>>> > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > >>>>>>> > > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> 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 > >>>>>>> http://p.sf.net/sfu/RIM-dev2dev > >>>>>>> _______________________________________________ > >>>>>>> Semediawiki-user mailing list > >>>>>>> semediawiki-u...@lists.sourceforge.net > >>>>>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Alex Kozak > >>>>>> Program Assistant > >>>>>> Creative Commons > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> WikiWorks · MediaWiki Consulting · http://wikiworks.com > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> John Arrowwood > >>>> John (at) Irie (dash) Inc (dot) com > >>>> John (at) Arrowwood Photography (dot) com > >>>> John (at) Hanlons Razor (dot) com > >>>> -- > >>>> http://www.irie-inc.com/ > >>>> http://arrowwood.blogspot.com/ > >>>> > >>> > >>> > >>> > >>> -- > >>> WikiWorks · MediaWiki Consulting · http://wikiworks.com > >>> > >>> -- > >>> John Arrowwood > >>> John (at) Irie (dash) Inc (dot) com > >>> John (at) Arrowwood Photography (dot) com > >>> John (at) Hanlons Razor (dot) com > >>> -- > >>> http://www.irie-inc.com/ > >>> http://arrowwood.blogspot.com/ > >>> <http://wikiworks.com> > >>> > >> > > > > > > -- > > WikiWorks · MediaWiki Consulting · http://wikiworks.com > > > > > > -- > John Arrowwood > John (at) Irie (dash) Inc (dot) com > John (at) Arrowwood Photography (dot) com > John (at) Hanlons Razor (dot) com > -- > http://www.irie-inc.com/ > http://arrowwood.blogspot.com/ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Semediawiki-user mailing list > semediawiki-u...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > -- Alex Kozak Program Assistant Creative Commons
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
