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
