[rkward-devel] data.frame-related plugins

[Prasenjit Kapat]

Hi,

On Thu, Jun 17, 2010 at 8:14 AM, Thomas Friedrichsmeier
<thomas.friedrichsmeier at ruhr-uni-bochum.de> wrote:
>
> Some tasks that come to mind:
> - sorting data
> - generating data
> - transforming data / recoding

Hmm, sorting should be really useful... This opens a can of
possibilities (and worms too..) Someday, if we could include the
transformation from reshape package, that would be wicked ;)

> 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).

I'll try to be brief and I am just thinking out loud:

There are two issues:

(i) which object to edit, and
(ii) what to do with that object.

My idea is to keep (ii) as a separate "pseudo" plugin (like we do in
various distribution plots, CLT plots, etc.. which can be included in
other plugins.

Now, (i) can be broken down into three completely separate plugins:
(i.1) Context menu for an open data.frame
(i.2) Context menu for selected object from the workspace browser (w/o
opening it in data.frame editor)
(i.3) Edit menu.

i.1: No extra work is needed to select any object, it is obvious.
There should not be any option to select any other object. Just
include (ii) and continue
i.2: Again, just include (ii) and continue
i.3: In this case, add a selection box listing only data.frames and
allow one of them to be selected. Below the selection box, include
(ii) and continue

In this way, bulk of the (important) work will be handled by the
pseudo plugin and will be common to all the three. The individual
plugins target three different scenarios and should be separately
maintained.

All this was easy ;) The more difficult part, in my opinion, is to
decide what to put in (ii) and how to structure it. But that, I guess,
can be improved incrementally. We could start with just sort
("order"), add column, and add row options.... and build from there.
As things get complicated, (ii) itself can be split into different
sub-pseudo-plugins, ....


Regards,
-- 
Prasenjit