For most uses, just wrapping POJOs is sufficient. Several things have changed since the host object mechanism was created: * Rhino has implemented bean properties (getFoo/setFoo) as JavaScript properties (foo) * Java has implemented, and Rhino has supported, variable arguments to methods * Java's reflection APIs have gotten much faster With all these changes, the delta in functionality between wrapping POJOs and using host objects has substantially narrowed. And wrapping POJOs is much easier.
The main thing you can do with the host object APIs that you can't do with wrapping POJOs is writing generic property getters, for example as was done with http://mxr.mozilla.org/mozilla/source/js/rhino/examples/Matrix.java. And Hannes' new annotation-based host objects are definitely better than the mangled-name form. --Norris On Dec 29, 1:46 pm, Mark Storer <[email protected]> wrote: > Whoops. Take two: > > ---------- Forwarded message ---------- > From: Mark Storer <[email protected]> > Date: Tue, Dec 29, 2009 at 10:45 AM > Subject: Re: Host object vs wrapped > To: Daryl Stultz <[email protected]> > > On Tue, Dec 29, 2009 at 5:29 AM, Daryl Stultz <[email protected]> wrote: > > I do appreciate the annotations approach to writing host objects but it's > > actually off topic from my original post. > > I disagree. Observe: > > import org.mozilla.javascript.annotations.*; > public class MyEntity { > > private int foo; > @JSGetter > public int getFoo() { return foo; } > @JSSetter > public void setFoo(int foo) { this.foo = foo;} > public void save() { ... } > > } > > Done. No need for a separate wrapper class, you can simply annotate > what you want exposed, and Rhino will ignore the rest. > > Err... unless.... Are you required to extend ScriptableObject? That > could be a deal-breaker for many Domain Objects. All the examples > given examples do so... > > I suppose the Actual Requirement is to implement Scriptable... extra > work, but not the end of the world for some object that has to derive > from Something Else. > > --Mark > > > > On Tue, Dec 29, 2009 at 5:29 AM, Daryl Stultz <[email protected]> wrote: > > > On Tue, Dec 29, 2009 at 4:39 AM, Hannes Wallnoefer <[email protected]>wrote: > > > > I implemented the annotation based mechanism a half year ago or so, > > > here's my announcement on this list: > > > I do appreciate the annotations approach to writing host objects but it's > > actually off topic from my original post. I'm looking for two things: what > > is the advantage of using a host object vs. a POJO? Also, I'm looking for an > > easy-maintenance approach to wrapping my domain classes - this is the bigger > > need. Suppose I have this domain class: > > > public class MyEntity { > > > private int foo; > > public int getFoo() { return foo; } > > public void setFoo(int foo) { this.foo = foo;} > > public void save() { ... } > > > } > > > I could use this directly in JavaScript with the auto wrapping to make it > > scriptable. But I prefer to have a wrapper class: > > > public class JsMyEntity { > > > private MyEntity delegate; > > public int getFoo() { return delegate.getFoo(); } > > public void setFoo(int foo) { delegate.setFoo(foo); } > > > } > > > So if JsMyEntity is in my "JavaScript API" package, I can "find usages" of > > MyEntity.setFoo() and see that the method is exposed to the JS API. Also, as > > you can see, I have restricted access to the MyEntity.save() method by > > omitting it from the wrapper. The problem is that this approach is difficult > > to maintain especially with collections. I'd like a simpler wrapper class > > that automatically forwards to the delegate except perhaps when a delegate > > method is marked with an annotation prohibiting JS access. What I'm not > > clear on is if I can use features of Scriptable or ScriptableObject to > > create such a wrapper. > > > I've experimented with ScriptableObject and I see that I can override get > > and filter the method name, but the method (FunctionObject?) ultimately > > comes from the same object and I want it to come from the delegate. > > > -- > > > Daryl Stultz > > _____________________________________ > > 6 Degrees Software and Consulting, Inc. > >http://www.6degrees.com > > mailto:[email protected] > > _______________________________________________ > > dev-tech-js-engine-rhino mailing list > > [email protected] > >https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino > > -- > --Mark Storer > Professional Geek > > -- > --Mark Storer > Professional Geek _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
