[rkward-devel] JS in rkwarddev [was: splitting repos?]
meik michalke
meik.michalke at uni-duesseldorf.de
Sat Oct 24 17:02:00 UTC 2015
hi,
Am Samstag, 17. Oktober 2015, 10:36:56 schrieb Thomas Friedrichsmeier:
> Yes, clearly not having to worry about the IDs (and getting early
> feedback when you mistype something) is probably the best thing about
> rkwarddev. We wouldn't want to forgo this. OTOH, I'm not sure the
> automatic _variable names_ in the generated JS are actually a feature
> worth fighting for. Yes, the consistency is a nice idea, but:
>
> - The idea is to work with the rkwarddev-code, anyway, and ideally
> never have to look at the generated code. The IDs don't show in the
> rkwarddev code, anyway.
yes, that's mostly the way i work. normally i only look at the generated code
if something does not work as it was supposed to.
> - The more useful - but difficult - thing would be for the JS variable
> names to be the same as the _R_ object names of the corresponding
> controls. We are not there, anyway.
that's easily doable if you name the R objects and their id.name likewise, and
keep naming JS conventions in mind (like no dots). that is because currently,
the JS variable names are always generated from the IDs (i.e., if the IDs are
generated automatically, everything in the resulting code looks a bit cryptic;
if you set the IDs yourself, you're indirectly also controlling the JS var
names):
x <- rk.XML.cbox("my box")
# gives you: <checkbox id="chc_mybox" label="my box" value="true" />
rk.JS.vars(x)
# gives you: var chcMybox = getValue("chc_mybox");
rk.JS.vars(x, guess.getter=TRUE)
# gives you: var chcMybox = getBoolean("chc_mybox");
and:
x <- rk.XML.cbox("my box", id.name="x")
# gives you: <checkbox id="x" label="my box" value="true" />
rk.JS.vars(x)
# gives you: var x = getValue("x");
rk.JS.vars(x, guess.getter=TRUE)
# gives you: var x = getBoolean("x");
there's currently no easy way to do this differently because rk.JS.scan()
can't access R object names when it is called. that function goes through the
XML structure, looks for all nodes that will likely be used and defines them
with their default getter method -- you usually don't call rk.JS.vars()
manually, it's only for special cases.
changing this would mean really deep changes in the package with the risk of
breaking it. i'm not so sure this is worth it.
however, i have added some new options to plugin2script() that will allow you
to use the first method: naming the R objects in the script code is much
easier than trying to get the JS vars to match those objects at an uncertain
later point.
> One new suggestion for a templating solution: Make it _look_ as if it
> was JS-code all along:
>
> var my_thing = getValue (RKD(ID(my.R.object)));
> // optionally quoted, in case it may be needed, in some places
> var my_thing2 = getValue (RKD("ID(my.R.object2)"));
> // some common things like "getting" might have easy access:
> var my_thing3 = RKD.get(my.R.object3[, getter=...]);
> // keep in mind that often you don't really _have_ to use JS variables
> // at all:
> if (RKD.get (my.R.checkbox.object)) {
> echo ("doSomethingFancy()\n");
> }
> // for some things there'd be less automatism, but that doesn't mean
> // we can't integrate advanced stuff:
> RKD(rk.JS.save(my.R.saveobj));
all of this would mean some major changes in the workflow of the package, and
i'm not convinced yet that this is the right way to go. it would also mean
returning to editing several files for one plugin.
to make reading the R script a bit more comfortable, i have just added a new
function called jo() ("JavaScript operators") which at least makes writing
if() conditions more straight forward.
old way (still works):
ite(id(x, " != \"\""),
echo(", select=c(", x, ")")
)
new way:
ite(jo(x != ""),
echo(", select=c(", x, ")")
)
that is, operators like !=, ==, > etc. are prevented from evaluation by jo()
and pasted as-is to the JS code.
> Other things like rk.JS.optionset could not easily be transitioned. But
> then, in my understanding, the main point of rk.JS.optionset is -
> again - automatic variable names.
that is one concern, next to not going crazy when using optionsets ;-) it
automatically looks up the relevant parent node of optioncolumns to fetch the
correct ID with getList(), and does also generate a for loop to make R code
from all entries.
viele grüße :: m.eik
--
dipl. psych. meik michalke
institut f"ur experimentelle psychologie
abt. f"ur diagnostik und differentielle psychologie
heinrich-heine-universit"at d-40204 d"usseldorf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20151024/a03341e4/attachment.sig>
More information about the rkward-devel
mailing list