[RkWard-devel] Barplot plugin

[Thomas Friedrichsmeier]

On Thursday 25 January 2007 12:53, you wrote:
> That would be very nice and tried it in different ways and in this way too,
> but with no result. The if (if getRK_val ("rainbow")) { ?>, col=rainbow(
> rk.temp.x) <? } ?>, does not seem to work for me, because this part does
> not appear in the code of the plug in, or appears constantly, whatever the
> choice of the user.  Tried the code as is with a small differentiation here
> l=rainbow( rk.temp.x) <? } ?> is in the barplot4.php.

Ok, small correction: Instead of 
	if (getRK_val ("rainbow")) ...
you'd have to write
	if (getRK_val ("rainbow") == "TRUE") ...
either that or change the value and value_unchecked of the rainbow checkbox 
to "1" and "0". Why? Well, PHP works slightly different from R. If it sees 
the string "FALSE", it will not recognize this as the logical false. Rather 
it will see "Ok, this is a non-zero string, I can't convert it to a number, 
so I'll take the condition as fulfilled". In other words, here's what it 
looks like in PHP, when the getRK_val () statement has been evaluated:

if ("TRUE") {
	// this gets executed / shown
}
if ("FALSE") {
	// this also gets executed / shown!
}
if ("0") {
	// this does not get executed
}
if ("FALSE" == "TRUE") {
	// this does not get executed
}

Does it make sense, now?

> - You might want to rewrite the first part as:
> > rk.temp.x <- (<? echo ($vars); ?>)
> > if(is.factor(rk.temp.x)) rk.temp.x=summary(rk.temp.x)
> > else if (!is.matrix(rk.rempt.x)) error ("Only matrices or factors are
> > supported")
> >
> > Saving one variable name, and also giving a more meaningful error message
> > in
> > case something wrong was selected.
>
> I tried this, but I get a syntax error. The warnings points me to the .xml
> file, so I removed the number type=numeric but with no result.

A typo, somewhere?

> Finally, I made a change making one more variable rk.temp.barplot2 and
> moved all the function to the function preprocess() as I had done in
> correlation graph.

Not quite sure, whether it make much sense in this case. After all, in essence 
it's a really thin wrapper around barplot, and does not provide too much 
additional functionality (ok, one additional statement for the value labels, 
but I don't think that justifies a function).
However, let's try to get the PHP ifs right, first, then we can worry about 
this detail later.

> This leads me to one idea that it cross my mind. Could we write some
> functions and embed them in the rkward package for R, so to use them in the
> plugins like the Rcmdr package does?

It depends. Yes, if it's a function that is
1) used by many or all plugins and
2) does not hide any essentials, i.e. only does some printing / formatting, 
but does not actually calculate a result / perform a statistic function

No, if it's a function that is
1) useful to only two or three plugins or
2) hides some essential steps of what is being done.

The reasons are
a) Keep the rkward package lean an mean. If we would - in the extreme - add 
one function for each plugin, that would mean plugins are no longer modular, 
are no longer easy to install (you'd always have to update the rkward package 
as well), and the rkward package would become huge, while only little 
functionality is actually used in a typical session.
b) Keep compatible in the essentials. The core of all generated code should 
also be runnable without the rkward package installed (so users can share 
code snippets with other R users that cannot or do not want to use RKWard). 
RKWard may provide some icing on the cake by e.g. making sure the results are 
printed in a consistent look across all plugins, but it should not actually 
provide statistics functions. Those are better kept in the regular add-on 
packages on CRAN.
If we do feel a real need for that, we should provide a stand-alone add-on 
package for inclusion on CRAN, or try to get the function(s) included in 
existing packages on CRAN.
c) Don't hide what's going on. The generated code should be as simple as 
possible, but not to the point of hiding everything in a function. Then - if 
users would like to modify some aspect - they'd have to start modifying those 
functions, instead of just copy-and-pasting some snippets from here to there.

Well, this is not set in stone, but that's the way I see it.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20070125/ec4c585e/attachment.sig>