From: Yury K. <kat...@gm...> - 2013-11-18 07:01:54
|
Hi Yaron! I now look at these options and see that indeed ajax=true is exsessive. We can just have update time and update button and if they have any value, ajax method of retrieving values will be used. Yaron, you're asking why not always to retrieve values with ajax. I really can't think of any reasons from the problem domain point of view. From programmer point of view though I expect that new parameters won't work smoothly first times. Maybe there will be problems with certain formats, maybe there will be problems with transclusion. Because of that I would support the old methods of non-ajax retrieval. ----- Yury Katkov, WikiVote On Mon, Nov 18, 2013 at 3:11 AM, Yaron Koren <ya...@wi...> wrote: > Hi, > > Before we get too deep into the technical side of things, let me take a step > back: > > Ajax, for those who don't know, is a technology where parts of the page can > be modified, based on new data from the server, without needing to refresh > the whole page. As far as I know, there are two advantages to having query > results use Ajax: > > 1) It leads to faster initial page loading - especially for more involved, > Javascript-based result formats, like the charting ones. > 2) Results can be refreshed, manually or automatically, without reloading > the page. > 3) It eliminates the problem of MediaWiki caching of query results (the old > "why isn't that new page showing in the list?" problem), because the query > results aren't cached along with the rest of the page. > > Until now, I think I've mostly heard #1 as a reason to use Ajax in SMW query > results - though, Yury, you seem to be talking mostly about reason #2. > (Correct me if I'm wrong.) That seems strange to me, because I think on the > vast majority of wikis, changes don't happen nearly fast enough to require > any type of real-time refreshing; and certainly not for a refresh rate > measured in seconds. > > Personally, I think reason #3 might be the strongest one, by the way. > > In any case, I have a question: Yury - if Ajax is possible for every result > format, why both with an "ajax=[true/false]" parameter at all? In other > words, is there ever an advantage to *not* using Ajax, given the option? > > -Yaron > > > On Sun, Nov 17, 2013 at 3:48 PM, Yury Katkov <kat...@gm...> wrote: >> >> Sorry if it have looked like an attack or if I've offended you, >> Jeroen, I have to mind my tongue and emotions. >> >> So, what do you think about this feature from purely technical point >> of view? How hard is that? How much would it change the artictecture >> if implemented? >> ----- >> Yury Katkov, WikiVote >> >> >> >> On Mon, Nov 18, 2013 at 12:30 AM, Yury Katkov <kat...@gm...> >> wrote: >> > That wasn't very technical :-) >> > >> >> Not every format supports this functionality and this is also not going >> >> to happen. >> > I'd say, that's managerial point of view AKA "I decline this >> > functionality with no explanation", like here: [1]. Come on, Jeroen, >> > you can do better than that! >> > >> >> Forcing them to do is makes little sense >> > And this is problem domain/application point of view, which only >> > reflect your experience. In some of our applications wiki supports >> > some offline process and there it's crucial to have thi kind of >> > 'update' button in every query including broadtable, ul, ol, filtered >> > and maps. And yes, people there don't know anything about wikis. I can >> > imagine similar problem in case of BPM (Alexander Gesinn) and >> > enterprise architecture - well anywhere where you need the information >> > to update quickly. I bet they's now using NOCACHE or struggling to >> > explain their users why their results doesn't appear instantly. >> > >> > [1] >> > http://comments.gmane.org/gmane.science.linguistics.wikipedia.technical/64153 >> > , scroll to Tim Starling >> > ----- >> > Yury Katkov, WikiVote >> > >> > >> > >> > On Mon, Nov 18, 2013 at 12:10 AM, Jeroen De Dauw >> > <jer...@gm...> wrote: >> >> Hey, >> >> >> >>> 2) could such feature be implemented in SMW core, that is: for all >> >>> result formats? Or must we add these parameters to every result format >> >>> separately? >> >> >> >> >> >> I'll answer this question from the technical side. Not every format >> >> supports >> >> this functionality and this is also not going to happen. (Forcing them >> >> to do >> >> is makes little sense.) Thus having a global parameter that "does not >> >> work" >> >> for a lot of the result formats is rather awkward. >> >> >> >> Cheers >> >> >> >> -- >> >> Jeroen De Dauw >> >> http://www.bn2vs.com >> >> Don't panic. Don't be evil. ~=[,,_,,]:3 >> >> -- >> >> >> ------------------------------------------------------------------------------ >> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps >> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access >> Free app hosting. Or install the open source package on any LAMP server. >> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk >> _______________________________________________ >> Semediawiki-devel mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com |