[rkward-devel] JS in rkwarddev [was: splitting repos?]

[Thomas Friedrichsmeier]

Hi,

On Fri, 16 Oct 2015 22:51:49 +0200
meik michalke <meik.michalke at uni-duesseldorf.de> wrote:
> > Perhaps this might be a good opportunity to think about a -
> > slightly - less integrated solution for this, where the JS file
> > could be kept on its own, instead of inline-quoted?
> 
> this has always been possible if you remove "js" from the "create"
> argument of rk.plugin.skeleton(), rkwarddev will not touch the .js
> file in place then. this will of course disable all automation that
> is done, like automatic variable definitions, automatically added
> code for saving objects or previews, etc.

yes, I was aware of that, but I meant more integrated ;-).
 
> > I could think of two approaches, neither of which
> > may be ideal, but perhaps they can trigger some further ideas:
> 
> i personally wouldn't want to do without the R functions any longer,
> but maybe we can find some useful template solution with R code in
> specially marked JS comments (similar to roxygen).

Ok, I was only worried about tying up the IDs, but in fact, with
templating, we could have arbitrary R code anywhere in the JS.
 
> the main problem is variable names. rkwarddev generates all of those 
> automatically from the given ID tag, keeping them identical in XML
> and JS as long as no forbidden characters are used, and also
> generates IDs automatically from label names and node types. my main
> goal was to not have to worry about any ID stuff any longer, as that
> was always driving me crazy before. i wanted to re-use an object i
> defined once, be it in XML or JS code, and let rkwarddev worry about
> how what is called.

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.
 - 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.
 - It is also not a problem if you somehow alter the IDs later on
   (intentionally or unintentionally): As long as the IDs are in sync,
   the variable names don't have to be.
 - Saving the developer from mistyping JS-variable names is a honorable
   goal, but errors on that front tend to show up rather directly,
   anyway.
 - In my personal experience, most UI data you need in JS is either
   a) needed exactly once, so storing it in a variable does not really
   help anything or
   b) needs some string modifications / concatenation / whatever
   applied, anyway, and thus the correspondence between JS-variables
   and UI IDs is a temporary thing, again.

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

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.

Note: For finding and extracting RKD()-pseudo-function calls, a look at
update_plugin_message.sh might help. It's python, and it only extracts,
instead of replacing, but it has enough JS parsing to find and extract
i18n()/i18ncp()/...-calls.

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