DWR

Moving from RC2 to 3.0 as I will not have time to fix this the next few weeks...

Kyle Pinette has kindly offered to help out with this ticket so I am here providing some instructions from my analysis:

The actual output of creator definitions to script is done in DefaultRemoter. You can probably steal a lot from converters (see createDtoClassDefinition method).

What is a little more work is to get wildcard replacement working the same way as for converters. For converters you can define:
match="pkg.MyClass" javascript="*" -> MyClass in JS
match="pkg.MyClass" javascript="otherpkg.*" -> otherpkg.MyClass in JS
match="pkg.MyClass" javascript="**" -> pkg.MyClass in JS
You can find the code for converters in DefaultConverterManager.inferClassName(), while your code should center around DefaultCreatorManager. Note that we can also provide wildcards in the match string for converters (see DefaultConverterManager.addConverter()), but this is something we've said that we probably don't want to support for creators.

A small difference is that for creators we want to map to a lowercase name, ie:
match="pkg.MyCreator" javascript="*" -> myCreator in JS
as creators are mapped to an instance and not to a class.

Doing this for converters was part of a larger class mapping effort I initiated last year in this thread:
http://www.nabble.com/class-mapping-enhancements-td17750025.html
and this ticket relates to the E1 thread:
http://www.nabble.com/class-mapping-E1:-Support-"dot"-syntax-for-generated-JavaScript-class-names-td18370652.html
http://www.nabble.com/RE:-class-mapping-E1:-Support-"dot"-syntax-for-generated-JavaScript-class-names-td18868364.html
and E2 thread:
http://www.nabble.com/class-mapping-E2:-Support-wildcard-syntax-for-converters-using-class-mapping-td18370618i40.html
You'll find background on decisions in these threads, so it may be an interesting read. (Note that feature designs may change throughout the threads so put more weight on the later mails.)

Deliver your work as a patch attached to this ticket and I'll review it before commiting. Also add test cases to the testdwr project that test/illustrate the new features. You can see the "package" and wildcard converter tests in testMarshall.js (the test cases should at some point be reorganized into more files but we'll leave that for now).
Also think about preserving the code style (spaces instead of tabs, braces and newlines, similar spacing around parenthesis, etc).

Good luck and happy coding!

Mike, looks like you are working on this for RC2. If not go ahead and set it back to 3.0. I have also switched it to in progress as it looks like you are currently working it.

Correct David, thanks for reminding me. Yes, I checked in this support a couple of days ago and it's available from http://directwebremoting.org/bamboo/browse/DWRTRUNK-ALL-150.
I will go on with polishing a few things in the implementation and write some documentation notes in this ticket before closing it.

Implementation is complete. I'll return to this ticket shortly, adding documentation.

Here's a description of what has been implemented:

Remoted objects can now have a hierarchical JavaScript name, which means that a dotted name can be used in a creator's javascript attribute, and this will be interpreted as several levels of names much like packages. The mapping to JavaScript can be done in different ways and the default mapping in /dwr/interface will create JavaScript objects for each name level so that a hierarchical reference may be used. F ex, if the following is specified in dwr.xml:

<create creator="..." javascript="foo.bar.Fred">
    <param name="class" value="com.example.Fred"/>
</create>

then it will be possible to include this script:

<script src="dwr/interface/foo.bar.Fred.js"></script>

or, if preferring slash "/" separators:

<script src="dwr/interface/foo/bar/Fred.js"></script>

The script will define the needed object structure to make calls to the remoted proxy available as:

foo.bar.Fred.<call to your method>

in JavaScript.

The JavaScript mapping is done somewhat differently for other supported JavaScript module formats, see DWR-515 for explanation of these.

In addition to providing hierarchical identifiers, most characters are now allowed in identifiers, such as

- . [ ] { } =

and others. This f ex makes it possible to name remoted objects with a versioned identifier such as "MyProxy-1.0.4".

Wildcards are also allowed in the javascript attribute, in the same way used for converters, so the following can be used:

<create creator="..." javascript="*">
    <param name="class" value="com.example.Fred"/>
</create>

Resulting JS identifier: Fred

<create creator="..." javascript="foo.bar.*">
    <param name="class" value="com.example.Fred"/>
</create>

Resulting JS identifier: foo.bar.Fred

<create creator="..." javascript="**">
    <param name="class" value="com.example.Fred"/>
</create>

Resulting JS identifier: com.example.Fred