Skip to content
This repository has been archived by the owner on Oct 29, 2020. It is now read-only.

select_list().options returns RemoteProxy object #2

Closed
caius opened this issue Jun 5, 2009 · 4 comments
Closed

select_list().options returns RemoteProxy object #2

caius opened this issue Jun 5, 2009 · 4 comments

Comments

@caius
Copy link
Contributor

caius commented Jun 5, 2009

I'm trying to get the list of <option>s in a <select>. This is what currently happens:

>> $browser.select_list(:id, "select_id").options
=> #<Culerity::RemoteObjectProxy:0x2158784 @remote_object_id=78, @io=#<IO:0x21a5fd4>

Testing using Celerity under jirb it should be returning an Array object.

irb(main):020:0> b.select_list(:id, "select_id").options
=> ["One", "Two", "Three"]

What I expect is for Culerity to return the array Celerity is returning.

@langalex
Copy link
Owner

langalex commented Jun 5, 2009

culerity currently proxies almost all objects and then hands any method calls to the actual object sitting in the java process. you should be able to use the proxy object as if it was the actual array. if not then this really is a bug.

@caius
Copy link
Contributor Author

caius commented Jun 5, 2009

Pushed my fix http://github.com/caius/culerity/commit/ea713b8ee6cdea88e74b4597ba1c5282717602b9 which fixes it by returning the original array to start with.

@langalex
Copy link
Owner

langalex commented Jun 5, 2009

the problem with your patch might be that when celerity returns an array of non primitive objects, then any method calls on those objects in the array would fail because they wouldn't be in the java process anymore. maybe checking recursively checking the contents of the array for their type would solve that.

@langalex
Copy link
Owner

fixed

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants