Suggestion for using some Stapler features from Ruby

[Hiroshi Nakamura]

Hi,

I tried to port ui-samples plugin to Ruby yesterday.
https://github.com/cowboyd/jenkins-prototype-ruby-plugin/commit/06265d3395a1f5ff7c868e978242b0c904318c1d
As you can see in commit log, there're lots of TODOs. All I'm doing at
present is just convert index.jelly to index.erb. No interesting
feature is implemented.

Charles, Kohsuke, do you have suggestions about where I should look
first? Any comments are appreciated.

// NaHi

[Kohsuke Kawaguchi]

Thanks. I searched TODOs and here are my comments:

* "TODO: sample.jelly does not pick up 'it' correctly now."

This is because Jelly views cannot be used with Ruby objects, because it
makes association between views and objects through java.lang.Class. If
this is a real problem, we can probably improve stapler to fix this, but
I've thus far assumed that we only need to support Ruby-proper view
technology for Ruby plugins.

If you'd like to dig deeper, I can provide more pointers.

* "TODO: let stapler recognize it." def increment(n)

Similarly, Java script proxy code doesn't yet recognize Ruby method
definitions. This just needs a bit more coding in Stapler.

If you'd like to dig deeper, I can provide more pointers.

* "TODO: how do we implement AutoCompletionCandidates?"

As long as it produces the same JSON data on the HTTP response, any
classes can be used. So we can conceivably reimplement
AutoCompletionCandidates in Ruby.

Now this goes back to the same old question, but one might wonder if
it's practical to keep re-implementing everything in Ruby like this, or
just use this Java class as-is.

--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Nectar, our professional version of Jenkins

[Hiroshi Nakamura]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for your comments. Those 3 TODOs are exactly one I listed in
commit log. I should not have written 'lots of'...

(2011/09/23 2:21), Kohsuke Kawaguchi wrote:
> * "TODO: sample.jelly does not pick up 'it' correctly now."
>
> This is because Jelly views cannot be used with Ruby objects,
> because it makes association between views and objects through
> java.lang.Class. If this is a real problem, we can probably improve
> stapler to fix this, but I've thus far assumed that we only need to
> support Ruby-proper view technology for Ruby plugins.
>
> If you'd like to dig deeper, I can provide more pointers.

I think it's enough for spike phase, and I'm not sure if we need it
eventually. I'll ask if I need.

We can create view in Ruby world via doDynamic or your Rack interface.
Current Stapler + ERb/Haml can be used for creating config view and it
should be enough.

> * "TODO: let stapler recognize it." def increment(n)
>
> Similarly, Java script proxy code doesn't yet recognize Ruby
> method definitions. This just needs a bit more coding in Stapler.
>
> If you'd like to dig deeper, I can provide more pointers.

I checked the code yesterday, around @JavaScriptMethod and "js" method
lookup in Meta.java in Stapler-core. And the hard part I think would
be those Java reflection in Stapler works for Java object (proxy
object in Jenkins/JRuby integration) and it would be tricky for wiring
to our Model object. One direct way I though is adding
@JavaScriptMethod to jenkins.ruby.JSMethod.java in ruby-runtime-plugin
and... who should include it?

> * "TODO: how do we implement AutoCompletionCandidates?"
>
> As long as it produces the same JSON data on the HTTP response,
> any classes can be used. So we can conceivably reimplement
> AutoCompletionCandidates in Ruby.
>
> Now this goes back to the same old question, but one might wonder
> if it's practical to keep re-implementing everything in Ruby like
> this, or just use this Java class as-is.

Agreed. We'd better define what plugins we allow to implement in Ruby
before trying to port some Jenkins plugin to Ruby :) If we were not
introduced proxy objectsand let users allow to use JRuby's Java
integration feature, users could implement almost all extension points
in Jenkins.

It's same for one TODO I've just added to
jenkins-prototype-ruby-plugin which I found during porting
DropdownList in UI Samples plugin.

https://github.com/cowboyd/jenkins-prototype-ruby-plugin/commit/b6e21c4f23bc1a8969198c134247a7963e9a033f

For embedding "Apple" and "Banana" view into DropdownList view would
need more help from Stapler and ruby-runtime-plugin I think. I should
do it just in Ruby land without using Jenkins model persistent feature.

Anyway, I think I've got too far. But it was good to find that JRuby's
ScriptingContainers interaction must not be a problem as far as we're
creating view in Ruby land (of course!), and it would not be needed in
near future. I'll try to implement some non-UI plugins next!

// NaHi

> On 09/21/2011 03:40 PM, Hiroshi Nakamura wrote:
>> Hi,
>>
>> I tried to port ui-samples plugin to Ruby yesterday.
>> https://github.com/cowboyd/jenkins-prototype-ruby-plugin/commit/06265d3395a1f5ff7c868e978242b0c904318c1d
>>
>>
>>
As you can see in commit log, there're lots of TODOs. All I'm doing at
>> present is just convert index.jelly to index.erb. No interesting
>> feature is implemented.
>>
>> Charles, Kohsuke, do you have suggestions about where I should
>> look first? Any comments are appreciated.
>>
>> // NaHi
>>
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)

iQEcBAEBAgAGBQJOe/EgAAoJEC7N6P3yLbI2yBIIAK8OlsCRLTq1aZWyzK8dm5NC
En6EmW+iAlzqqWPo40B4Njxwxsjo1Z61uX9nnhohTzepLCDsIR5TxZcluasE7P/3
Pvu39bg3x0TplYPguCrjOoLmYb0azEBSwgY7yg5Isa4V5enwW2OFDcrTpQdJdm6t
nSYLOBqfcrNOK/KEbQC3JyJOye+QyQ4se3z5EwG02UP2+FqkXrY062cU24Acb/M8
MtneUfadnRkp02Q3wl17mXs6Djhche36nW3VgfVSdombQIMxz35yzAhId2f8Fnl9
iXfIOk1ZdvMvVdASVr1qNnN2xB5qJup2GKfE9ZNRMm2OJN0+AkaJWxgiOi4rEqI=
=vKpb
-----END PGP SIGNATURE-----