As for the type information, I think it's doable to get the Javascipt->Java conversion to be type-aware by requiring those dataTypeXXXX fields in the Javascript class that I mentioned. I could certainly see making it optional, i.e., if a dataTypeXXXX field isn't found for a corresponding field XXXX, then it will be converted to a string and that's that. In fact, I think I like that idea quite a bit!
On the point of the methods, I too thought about what could be done with prototypes... I think I'd prefer to take a bit of an evolutionary approach though and just go with the fields first... But later on I think it might be very doable to reconstitute the object based on a prototype and thereby get the methods too.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Craig McClanahan wrote:
Wouldn't a Map that had String-valued keys be a reasonable Java object representation of a JavaScript object? That way you can have an arbitrary set of properties, and deal with them by name instead of by index. In the JavaScript->Java direction, you'd probably make the values all Strings too (unless the serialization includes type information), but you'd have more flexibility going the other way.
I don't see losing the methods as that big a loss, given a convenient way to transport data back and forth. On the other hand, I'll bet there's some way to use prototypes at the client end to resurrect the methods too.
Craig
On Fri, 29 Oct 2004 12:33:24 -0700 (PDT), [EMAIL PROTECTED] <[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]
--------------------------------------------------------------------- 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]
