Hi, On Tuesday 27 September 2011, meik michalke wrote: > funny this wasn't discovered until now.
indeed. > they should either be corrected or the attribute removed completely. naturally, this should be corrected. But I simply suggest to delay the fix for another while (at least until after 0.5.7). Then, we will have some time to experiment with a few concepts. Meanwhile, the wrong attributes are still a sort of documentation about which varslots were intended to be numeric, and thus, I suggest to keep them until we are happy with whatever we came up with. > i think this cannot be decided on a global level. there clearly are cases > where one type of data is the only one that makes sense, so i'd consider it > a win for ergonomics that you cannot even select something which will only > produce errors (which, for a normal user, might be harder to understand > than the simple fact of not being able to put an object into a varslot). True. However, what I'm worried about is cases, where developers _think_ a certain restriction makes sense, but in reality it is too strict, and prevents the user from doing something absolutely "legal". Some examples: - In cases, where type string or factor are expected (e.g. in labels), number will sometimes make sense, too. Will we always keep such corner cases in mind? - In cases, where number is expected, logicals are often, but not always allowable, too. - In cases, where factors (e.g. tabulation by groups) are permitted, logicals generally qualify, while strings and numbers may or may not make sense. - We don't have specific support for date / time variables, yet. But these will be fun, too, as there are certainly cases, where useage is place of numbers, strings, or factors makes perfect sense, while in other cases it does not. For classes, there are many more variants. Often R functions do automatic conversion using as.XYZ(), and that may sometimes work (and make sense) in cases that we had never thought about. > on the other hand, it's a really good idea to have RKWard explaining the > *reason* why the object can't be selected, if you try and fail; what about > a tooltip for varslots like "Valid types: ..."/"Valid classes: ...", and > in the event of picking a wrong type, the varslot turns red (like > "required", and should be handled like this)? this would be similar to > saveobject, if you try to overwrite an existing object. Yes, showing the "offending" object in the varslot, along with some visible form of warning and explanation, will certainly be a big step in the right direction. From there, I think we basically have these options: - Always allow the user to proceed (like required="false") - Allow the developer to specify, whether the user should be allowed to proceed (something like a new attribute strict="true/false") - Don't allow the user to proceed by default, but give them some means to override this. Which would you prefer? Are there other sensible options? Regards Thomas
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
