I do have some experience with Rhino, I actually integrated it into DataVision a few weeks ago for Javascript formula support (new release coming at some point!). I hadn't considered it for this... I'll have to think about it a bit. Off the top of my head it seems like it might be a little heavyweight for this application, meaning it's one more dependency if this whole idea ever got added to Struts, something I'd bet everyone (certainly me) tries to avoid as much as possible. But that's just my gut reaction, I'll consider it a bit more.
As far as use cases go, this is actually based on something a user posted a few hours ago, not something I'd ever thought of... He was asking about how he could have a Javascript object on a page and get that into a Java object on the server. I think his basic thought was that since he's structured his pages to use objects to store and manipulate data, it might be nice to be able to easily convert that to a class in his Actions to work with. I just took it a step further and considered the other path... what if you have a Java object and you want to get yourself a Javascript object with the same state as the Java object? Especially when dealing with richer user interfaces as I'm sure you know, you tend to get into client-side scripting and dynamic HTML more... I do a tremendous amount of that here at work because I'm kind of known for being able to make web apps look, feel and work like a fat client, but that comes at the cost of complexity on the client-side. Many of us like to use OOP techniques on the client-side as we do on the server-side, so being able to convert objects from the client to the server and vice-versa with a minimum of fuss is an attractive idea. The alternative is of course extra code on the pages (or in taglibs) to render values into Javascript variables, and then munging Javascript variables into form fields to be submitted and than manually populating any objects that might need to be on the server. A standard way of doing such a thing might be quite helpful. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Fri, October 29, 2004 4:01 pm, David Graham said: > Have you looked at Rhino http://www.mozilla.org/rhino/ ? It lets you > access Java from JS and JS from Java so you might not need to handle types > if you just pass the JS into the Rhino interpreter. > > I'm not sure I understand the use cases for your proposal though. > > David > > --- [EMAIL PROTECTED] wrote: > >> Craig (and everyone else), based on what you mentioned on the User's >> list, I'd like to make the following proposal, get some feedback from >> everyone and go off and work on it... I prefer getting at least some >> level of buy-in from you guys before I spend any time on it... >> >> The basic idea is being able to convert a Javascript object to a Java >> object, and vice-versa. Let's deal with it in two steps... >> >> To convert from Javascript to Java, I propose we add a new form tag to >> the HTML taglib called 'html:jsObject'. This would act like an >> html:hidden element, but with some differences. >> >> The 'styleId' element would always render the HTML id attribute as >> 'jsoXXXX' where XXXX is the name as specified in 'styleId' for an >> html:jsObject tag. This would be needed to avoid name conflicts with an >> object named the same thing as the form field. >> >> The html:form element would need to have a new attribute added, >> 'jsoAware'. When set to true, an added onSubmit handler would be >> rendered that grabs Javascript objects in page scope named according to >> the 'styleId' of the html:jsObject tags and sets the value of the >> corresponding html:jsObject tag for each one. >> >> So, a developer has to (a) set jsoAware true on html:form and (b) add an >> html:jsObject element for each object they wish to serialize. As I >> understand it, the browser will create a string out of the object (I >> need to verify this frankly, but I'm taking it on faith at this point), >> so that becomes the value of the jsObject field. That gets us >> serialization on the client-side integrated with the taglibs. >> >> Next, as Craig said, we create a new JSJavaConverter. Pass this the >> class to convert to (maybe an ActionForm? maybe something else?) and >> the string as submitted as the jsObject field... >> >> ...and here's the first problem I see... what about data types? >> Javascript is typeless, Java obviously isn't. My thought here is that >> we put a restraint on any Javascript class to be converted: you as a >> developer must provide a dataTypeXXXX field for each data field, where >> XXXX is the name of the field. These would be set to one of a set of >> known values (i.e., string, double, etc). I'm thinking we can add >> another tag, maybe html:jsObjectConstants, that will render Javascript >> defining the data type constants. A developer can throw this tag into >> their class (or at page-level, whichever) and use them in the class to >> define the data types. >> >> I think that gives us enough information to attempt conversions on the >> fields of the Javascript class. The converter I don't think would be >> terribly difficult to write, once I know the structure of the >> serialization the browser performs (hopefully it's name/value pairs and >> is delimited in some way, then it's almost cake). >> >> Now, moving on to converting a Java object to Javascript... >> >> That should be even easier... Just write a converter to call toString() >> on all class fields. I'm thinking I'd write a generic >> 'JavascriptObjectClass' for use in the converter as the target class. >> This would probably be as simple as a class with nothing but a HashMap >> in it that contains the field names and values. Heck, maybe just >> passing it a HashMap class is sufficient, I'll have to think about that >> a bit (if it is, even simpler and better!) >> >> Then we'd need a new html:renderJSObject tag that would, you guessed it: >> accept the name of an object (in the response? not sure...) and render >> the Javascript for it based on the HashMap. >> >> Obviously this will only reconstitute an object's state, not it's >> methods. I think that's perfectly logical but it does place some >> limitations on the usefulness of this potentially... I could see an >> attribute of html:renderJSObject that says either (a) render an entire >> Javascript class, i.e., the state is all I'm interested in, or (b) just >> render variable declarations... this would assume that the developer is >> writing Javascript and basically wants the tag to "insert" the state >> code into the rest of the class definition. >> >> So, if you have a JSP that you want to have a Javascript object in that >> contains data retrieved from a database for example, in your Action you >> get your data in some class (some DTO for instance) and then ask the >> converter to convert that to a JavascriptObjectClass (or a HashMap, >> whichever way thatgoes). In your JSP you have html:renderJSObject and >> lo and behold, you have your class! >> >> Does this all make sense? Does it sound useful? What problems do you >> see that I'm not? As I said, I wouldn't mind doing this, but if >> everyone thinks it's a stupid idea then I don't want to waste time. >> Thanks all! >> >> -- >> Frank W. Zammetti >> Founder and Chief Software Architect >> Omnytex Technologies >> http://www.omnytex.com >> >> On Fri, October 29, 2004 2:23 pm, Craig McClanahan said: >> > That's a pretty interesting idea. >> > >> > If you registered a Converter (in BeanUtils) that knew how to convert >> > a String to a TestObject (and back), I'll bet you could get >> > BeanUtils.populate() to do what you want. >> > >> > Craig >> > >> > >> > On Fri, 29 Oct 2004 13:07:49 -0400, Ed DeMaio <[EMAIL PROTECTED]> >> wrote: >> >> I have a javascript object that I store in a hidden form field. It >> >> seems to be submitted to the servlet as an array of strings, where >> the >> >> indices are the values of the properties of the javascript Object. >> >> >> >> Basically I'm wondering how I can have a javascript object mapped to >> a >> >> java object, instead of simply into an array of strings. It seems to >> >> have something to do BeanUtils.populate(), but really I'm not sure. >> If >> >> anyone can even point me in some vaguely helpful direction it would >> be >> >> much appreciated, as I have been searching for days. >> >> >> >> Below is an example in case my description was unclear... >> >> >> >> my jsp file includes: >> >> >> >> <script type="javascript"> >> >> var test = new Object(); >> >> test.property1 = "qwerty"; >> >> test.property2 = 7; >> >> >> >> window.onload = function() { >> >> document.getElementById('form1').test.value = >> >> test; >> >> } >> >> </script> >> >> >> >> <html:form styleId="form1"......> >> >> <html:hidden property="test" styleId="test" /> >> >> <html:submit property="submit" /> >> >> </html:form> >> >> >> >> my ActionForm class contains the following getter and setter method: >> >> >> >> public TestObject getTest() { return testObj; } >> >> public void setTest(TestObject test) { this.testObj = test; } >> >> >> >> and my TestObject class contains the following getter and setter >> >> methods: >> >> >> >> public String getProperty1() { return prop1; } >> >> public void setProperty1(String s) { this.prop1 = s; } >> >> >> >> public Integer getProperty2() { return prop2; } >> >> public void setProperty2(Integer i) { this.prop2 = i; } >> >> >> >> and when the form is submitted, i would like the test object in my >> >> action form populated with the properties from the javascript test >> >> object that was submitted. >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> > --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > > _______________________________ > Do you Yahoo!? > Express yourself with Y! Messenger! Free. Download now. > http://messenger.yahoo.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
