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

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
rkward-devel mailing list
rkward-devel@kde.org
https://mail.kde.org/mailman/listinfo/rkward-devel

Reply via email to