Re: [SMW-devel] [SF] Spinbox for SF
Hi Yaron, I think that the main advantage of the spinbox over a generic field is that the spinbox is recognizable as input for inserting only numbers. So often the users of my wikis make mistakes and inserted values like "over 9000" or "9000 (approximately)" instead of just "9000". This usually leaded to problems in queries and the wiki produced not nice looking error notifications. I usually solved these problems by adding explanations to the fields and use regex filtering. However I think that the amount or user errors will decrease if we use spinner for numbers. I agree though that the the change in default look of the forms is very important and always must be done very carefully: I myself hated the switch to KDE4, Unity and most of all GMail's-barbarian-forced-switch-to-a-new-look. Another thing is that wiki-admins may have attached some CSS and JS to html elements and the change will broke the appearance of their forms. So I'll integrate the spinbox input to SFI. Sincerely yours, Yury 02.07.2012 19:45 пользователь "Yaron Koren" написал: > Hi Yury, > > Very interesting. This certainly looks like a useful input, though I don't > know if it makes sense as a default input for the "Number" type. > Personally, I associate "spinners" with graphical applications like word > processors and illustration apps, where it lets you quickly try out small > variations on different settings, then preview to see whether that's an > improvement or not. I don't know if I've ever seen a spinner on an input > where the number is known in advance, and you just have to enter it in. > (I've seen dropdowns in cases like that, like when you have to enter the > number of people in an online reservations form, but that's not entirely > the same thing.) > > Maybe other people disagree, though. If you or othes have more opinions > about this, feel free to share them. It would be a pretty big change to the > look of forms, but sometimes change is good. > > If it's not going to be the default input type, though, I would say it > makes more sense in SFI, because that's where most of the Javascript-based > inputs go. > > By the way, it would be nice to actually see the spinner input in action, > but it looks like editing on that wiki is restricted to administrators. Not > that big a deal, though - I can imagine how it works. > > Also - it's great to see the "two listboxes" input, above it on the form! > It looks even cooler than I thought it would be; I didn't realize there was > an autocompletion element to it too. > > -Yaron > > On Mon, Jul 2, 2012 at 9:55 AM, Yury Katkov wrote: > >> Hi everyone! >> >> Alexey Klimovich from WikiVote developed great form input for spinners >> (spinboxes). Should we integrate this input with SF or with SFI? In my >> opinion spinner should be default input for number data: not because >> those little buttons are handy but because the user recognizes >> immediately that she have to put the number (not string) in the box. >> >> You can see the input in action here [1] and this library [2] have been >> used. >> >> The input supports the following parameters: >> * min and max values >> * showonfocus - show buttons on hover >> >> We'll probably add these parameters soon: >> * step - the step of a single increment/decrement >> * prefix - text before the number >> * suffix - text after the number >> >> [1] http://goo.gl/raIY9 >> [2] https://github.com/btburnett3/jquery.ui.spinner >> >> Sincerely yours, >> Yury Katkov >> > > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Bundling extensions more closely
Hi, I still think that this is a bad idea, due to the fact that it sets up a two-tier system of extensions, with somewhat arbitrary criteria over what gets included. The only extension that I think can be included without any controversy or complications is Semantic Result Formats. Any other extension either has additional requirements, or has spinoff extensions, or has "competitors", or is not widely in use, etc. I admit, though, that I don't really see the advantage of putting more than one extension in the same repository in the first place, if it doesn't make download easier and it doesn't enforce any sort of compatibility. Whatever the advantage is, is it enough to outweigh the negatives? -Yaron On Jul 17, 2012 7:15 AM, "Markus Krötzsch" wrote: > Hi, > > as I understand Jeroen, this is mainly a proposal about code > maintenance, not about deployment. Somebody who pulls the whole repo > will have the code for all extensions that are in there, but that does > not mean that they are all enabled (or even mutually compatible). > > It seems to me that a joint repository would not work very different for > people who run wikis with code from git (development or not). You still > need many individual pull commands, since you need many parallel > directories that are not in a joint super-directory that is in the > SMW-repository (the MW extension directory is part of MW's repository). > I suppose that you cannot pull many extension directories into > ./extensions with one git command in this case. So what people would do > is still to check out each extension that they want to use individually. > > Similarly, we would not automatically have a different distribution than > we have now. Maybe work on SemanticBundle would be simplified by a joint > repo, but the SMW package will look as before. So there is no change for > the final user. > > If this is all true, the proposal is mainly a decision about simplifying > some of our development processes. I would support this. > > A possible problem that I can see is with automated testing: if some of > the other extensions break due to some SMW change, then the maintainers > of these extensions need to fix it; they may not do this, or at least > not do this immediately. We cannot quickly move extensions out of the > joint repo, so this might be a nuisance once automated tests are enabled > on pushs (SMW changes will not get auto-verified). Is that an issue? > > Markus > > > On 16/07/12 23:48, Daniel Schuba wrote: > > I think, before bundeling any extensions, there could be something like > a compatibility check. Wordpress for example has something like this, and > even allows to install plugins directly. So I think something like a > compatibility and dependency check would be better. But on mediawiki side, > not especially for SMW. > > > > Am 17.07.2012 um 00:18 schrieb Yaron Koren : > > > >> Hi Jeroen, > >> > >> I don't think this is a good idea as you've described it. It would > certainly increase convenience, for all the reasons you mention. But on the > other hand, it would automatically set up a "two-class system" for > extensions: those that are grouped in with Semantic MediaWiki, and those > that aren't. In some cases, this wouldn't be controversial: I think > everyone would agree that Semantic Result Formats is the right extension to > use if you want to display semantic data in charts, calendars and the like, > and that Semantic Maps is the right extension to use if you want to display > it in map form. However, there are various cases where it's not so obvious: > for instance, Semantic Watchlist provides notifications about changes to > SMW data, but there are two other extensions that, at least in theory, can > be used for the same thing. And the Semantic Image Input extension provides > a useful input for Semantic Forms, but there are various other extensions > that provide just one or two form input typ > es: what are the criteria for deciding which of them get included and > which don't? > >> > >> There are some technical issues as well: you didn't include the > Validator and Maps extensions in that list, even though they're required by > SMW and Semantic Maps extension, respectively; presumably because there are > people who would want to install those without installing SMW. But at that > point, the whole thing starts to feel a little like a hack. > >> > >> Let me make a counter-suggestion, then: the Semantic Bundle package > already does essentially the same thing, of holding a curated group of > extensions. Is it possible to make a Git repository for Semantic Bundle, > that just holds symbolic links (or whatever the term is) to all of its > extensions, in a way that can be downloaded all at once, either via Git or > as a tar file? That's essentially what happens with Semantic Bundle > already, although the SVN part of it doesn't work that well. Maybe with Git > it can function better, given Git's greater flexibility. > >> > >> Tied in with that
Re: [SMW-devel] PHP requirements
Hi Markus, shouldn't be, just wanted to check. Thanks Benedikt - Original Message - From: "Markus Krötzsch" To: "Benedikt Kämpgen" Cc: semediawiki-devel@lists.sourceforge.net Sent: Tuesday, 17 July, 2012 1:31:33 PM Subject: Re: [SMW-devel] PHP requirements On 17/07/12 09:48, Benedikt Kämpgen wrote: > Hello, > > Validator uses get_called_class in > Validator/includes/definitions/ParamDefinition.php on line 872. > > Apparently, this method is only available from PHP 5.3.0 onwards. > > Does that mean that Validator and SMW do require PHP >= 5.3.0 from now on? Yes, upcoming versions of SMW are planned to require PHP 5.3.0. Is this a problem for you? Best, Markus -- AIFB, Karlsruhe Institute of Technology (KIT) Phone: +49 721 608-47946 Email: benedikt.kaemp...@kit.edu Web: http://www.aifb.kit.edu/web/Hauptseite/en -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] PHP requirements
On Tue, Jul 17, 2012 at 4:14 PM, Jeroen De Dauw wrote: > Hey, > > >> Shouldn't we hold these requirements in the extensions? [1] > > These docs are for MediaWiki 1.19. 1.20 does require 5.3 or later. Oh, I see. No objections then! > Furthermore, I send a mail to the lists about using PHP 5.3 in the next > version of SMW, and no one complained. And several extensions I maintain > already require it, and no one complained about that either. So do you have > any specific reason for not using it outweighing the advantages? :) > > Cheers > > -- > Jeroen De Dauw > http://www.bn2vs.com > Don't panic. Don't be evil. > -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] PHP requirements
Hey, > Shouldn't we hold these requirements in the extensions? [1] These docs are for MediaWiki 1.19. 1.20 does require 5.3 or later. Furthermore, I send a mail to the lists about using PHP 5.3 in the next version of SMW, and no one complained. And several extensions I maintain already require it, and no one complained about that either. So do you have any specific reason for not using it outweighing the advantages? :) Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] PHP requirements
Hi! Shouldn't we hold these requirements in the extensions? [1] [1] http://www.mediawiki.org/wiki/Manual:Installation_requirements - Yury Katkov On Tue, Jul 17, 2012 at 2:31 PM, Markus Krötzsch wrote: > On 17/07/12 09:48, Benedikt Kämpgen wrote: >> Hello, >> >> Validator uses get_called_class in >> Validator/includes/definitions/ParamDefinition.php on line 872. >> >> Apparently, this method is only available from PHP 5.3.0 onwards. >> >> Does that mean that Validator and SMW do require PHP >= 5.3.0 from now on? > > Yes, upcoming versions of SMW are planned to require PHP 5.3.0. Is this > a problem for you? > > Best, > > Markus > > > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Semediawiki-devel mailing list > Semediawiki-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] PHP requirements
On 17/07/12 09:48, Benedikt Kämpgen wrote: > Hello, > > Validator uses get_called_class in > Validator/includes/definitions/ParamDefinition.php on line 872. > > Apparently, this method is only available from PHP 5.3.0 onwards. > > Does that mean that Validator and SMW do require PHP >= 5.3.0 from now on? Yes, upcoming versions of SMW are planned to require PHP 5.3.0. Is this a problem for you? Best, Markus -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] PHP namespaces
On 16/07/12 18:02, Jeroen De Dauw wrote: > Hey, > > I discussed using PHP namespaces a while back with Markus and Nischay > and have now written up my thoughts on the roadmap: > http://semantic-mediawiki.org/wiki/Roadmap#Introduce_PHP_namespaces This will be a big improvement. We can also rename files to agree with the new class names when we do this. No extension code should be broken by this, as long as it relies on the MW autoloader. Markus -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Bundling extensions more closely
Hi, as I understand Jeroen, this is mainly a proposal about code maintenance, not about deployment. Somebody who pulls the whole repo will have the code for all extensions that are in there, but that does not mean that they are all enabled (or even mutually compatible). It seems to me that a joint repository would not work very different for people who run wikis with code from git (development or not). You still need many individual pull commands, since you need many parallel directories that are not in a joint super-directory that is in the SMW-repository (the MW extension directory is part of MW's repository). I suppose that you cannot pull many extension directories into ./extensions with one git command in this case. So what people would do is still to check out each extension that they want to use individually. Similarly, we would not automatically have a different distribution than we have now. Maybe work on SemanticBundle would be simplified by a joint repo, but the SMW package will look as before. So there is no change for the final user. If this is all true, the proposal is mainly a decision about simplifying some of our development processes. I would support this. A possible problem that I can see is with automated testing: if some of the other extensions break due to some SMW change, then the maintainers of these extensions need to fix it; they may not do this, or at least not do this immediately. We cannot quickly move extensions out of the joint repo, so this might be a nuisance once automated tests are enabled on pushs (SMW changes will not get auto-verified). Is that an issue? Markus On 16/07/12 23:48, Daniel Schuba wrote: > I think, before bundeling any extensions, there could be something like a > compatibility check. Wordpress for example has something like this, and even > allows to install plugins directly. So I think something like a compatibility > and dependency check would be better. But on mediawiki side, not especially > for SMW. > > Am 17.07.2012 um 00:18 schrieb Yaron Koren : > >> Hi Jeroen, >> >> I don't think this is a good idea as you've described it. It would certainly >> increase convenience, for all the reasons you mention. But on the other >> hand, it would automatically set up a "two-class system" for extensions: >> those that are grouped in with Semantic MediaWiki, and those that aren't. In >> some cases, this wouldn't be controversial: I think everyone would agree >> that Semantic Result Formats is the right extension to use if you want to >> display semantic data in charts, calendars and the like, and that Semantic >> Maps is the right extension to use if you want to display it in map form. >> However, there are various cases where it's not so obvious: for instance, >> Semantic Watchlist provides notifications about changes to SMW data, but >> there are two other extensions that, at least in theory, can be used for the >> same thing. And the Semantic Image Input extension provides a useful input >> for Semantic Forms, but there are various other extensions that provide just >> one or two form input typ es: what are the criteria for deciding which of them get included and which don't? >> >> There are some technical issues as well: you didn't include the Validator >> and Maps extensions in that list, even though they're required by SMW and >> Semantic Maps extension, respectively; presumably because there are people >> who would want to install those without installing SMW. But at that point, >> the whole thing starts to feel a little like a hack. >> >> Let me make a counter-suggestion, then: the Semantic Bundle package already >> does essentially the same thing, of holding a curated group of extensions. >> Is it possible to make a Git repository for Semantic Bundle, that just holds >> symbolic links (or whatever the term is) to all of its extensions, in a way >> that can be downloaded all at once, either via Git or as a tar file? That's >> essentially what happens with Semantic Bundle already, although the SVN part >> of it doesn't work that well. Maybe with Git it can function better, given >> Git's greater flexibility. >> >> Tied in with that, maybe it makes sense to upgrade Semantic Bundle to a >> recommended download solution for SMW, so that, for instance, instructions >> on how to get it are right on the SMW download page, instead of on a linked >> page. That seems like a good idea to me, though others might disagree. >> >> -Yaron >> -- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> ___ >> Semediawiki-devel
[SMW-devel] PHP requirements
Hello, Validator uses get_called_class in Validator/includes/definitions/ParamDefinition.php on line 872. Apparently, this method is only available from PHP 5.3.0 onwards. Does that mean that Validator and SMW do require PHP >= 5.3.0 from now on? Best, Benedikt -- AIFB, Karlsruhe Institute of Technology (KIT) Phone: +49 721 608-47946 Email: benedikt.kaemp...@kit.edu Web: http://www.aifb.kit.edu/web/Hauptseite/en -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
