Hi, a few days ago, in private mail, Jacek asked me, how to access the currently edited data.frame from a plugin. The answer is that this is not currently possible, but of course it would make a whole lot of sense to be able to do so. Manipulating the current data.frame is a very important use case, and it should not be necessary to select the data.frame from the object list for each operation.
Some tasks that come to mind: - sorting data - generating data - transforming data / recoding Well, technically this issue is easy to solve. I'll simply create a new "context" (http://rkward.sourceforge.net/documents/devel/plugins/contextualized_plugins.html), which will be active when a data.frame-editor is active. Plugins in that context will be able to reference that data.frame. What keeps me thinking, however, is how this plugin context relates to plugins outside of the context. Let's take the example of a plugin that creates some random generated data. The problem is, that there could really be three variants of this plugin: 1) A plugin that operates on the current data.frame, and adds a new column to it. 2) A plugin that operates on an arbitrary data.frame, and add a new column to it. I think this use case is important, too. Having to open each object that you want to work with, would seem rather cumbersome to me. And for very large data.frames, this could easily lead to serious memory/performance problems. 3) A plugin that adds a new object anywhere in globalenv(). This plugin would have to ask for the length of the generated sequence, but otherwise, it would be very similar to cases 1 and 2. Again, technically this is not much of an issue. In fact it should not be too difficult to cover all three cases with a single piece of code. 2 and 3 could even be covered by the same dialog, invoked from the same menu entry. But that still leaves of with: a) A dialog that can only be invoked when editing a data.frame. b) A mostly identical dialog that is valid "globally", i.e. not tied to editing a data.frame. So how to deal with this duplication of functionality? One approach would be to place all context-dependent plugins into sub-menus of "Edit". The global plugins would reside in some other top-level menu (perhaps "Transformations"). Another idea would be to have only one set of menu-entries, i.e. only "global" plugins. Those could still reference the current data.frame, if there is any, and work on .GlobalEnv, otherwise. Of course this would mean that the plugins change their behavior in a way that may be non-obvious and confusing. It might also be mildly infuriating, in case you really want to manipulate an object which is not the one you are currently editing (you'd have to close it, first). What do you think of these options? Any other thoughts / ideas? Regards Thomas
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
