Ah, my apologies. Disabling page caching had been discussed as a potential solution to the data update issue on one wiki in the past but it was before I got involved in the project.
Thanks for the link, I'll take a look! AK On Mon, Aug 16, 2010 at 2:34 PM, Yaron Koren <yaro...@gmail.com> wrote: > Hi Alex, > > The "SemanticUpdateOnPurge" extension, which I'm told is bug-free, :) might > be what you're looking for: > > http://www.mediawiki.org/wiki/Extension:SemanticUpdateOnPurge > > I assume that's what you're talking about, though your comment about page > caching is a little odd - turning off page caching won't affect data > updating. > > 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 > -- 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
