+1 However, packaging up a small collection of the classes that are actually useful would be even better. The ones that spring to my mind are:
ERXGenericRecord ERXKey ERXArrayUtilities ... other utilities On Wed, Apr 29, 2009 at 8:42 AM, David Avendasora <[email protected] > wrote: > Hi all, > > I'm trying to work out the best way to allow WO Java Client > applications to use parts of Wonder with no changes to Wonder, other > than adding some additional build products that should _not_ interfere > with non-JC projects. > > Basically, The client-side of a WebStart deployed JC project looks for > it's classes and Libraries in the /WebServerResources/Java directory > for the application and in /MyFramework.framework/WebServerResources/ > Java for any frameworks on the classpath. > > If you look at the Apple WebObjects frameworks you will see this > arrangement. The default build.xml file for new WO Frameworks and > Applications in WOLips has already been modified to create this .jar > file for any project where javaclient=true has been set in the > build.properties file. Yea progress! > > The problem is that none of the Wonder frameworks do this. In most > cases that's fine as many of the Wonder frameworks are either server- > specific, or they mix EOAccess calls in without regards to MVC > separation (why should ERXStringUtilities need access to the DB?) and > that's not going to be fixed/changed anytime soon. However, there are > a few frameworks that can be used on the client, WOJavaRebel for > example. > > I would like it if the Wonder build files could be modified to handle > client-side jars the same way that the standard WO Framework and > Application build.xml files have been modified. It keeps server- > specific classes from being put in the client-side jar and client- > specific classes from being put in the server-side jar. The build.xml > file checks the build.properties file for javaClient=true, if present, > it builds the /WebServerResources/Java/ProjectName.jar file. > > Since there aren't any client-specific classes in Wonder the server- > side jar would be the same as it is now. For the client-side .jar we'd > simply be adding all classes. In the future we could try to repackage > classes that are server-specific, client-specific or common so the > client-side jar would only contain the things that were functional on > the client, but we don't have to do that to start with since we'd only > turn it on for Frameworks that are actually useful to the client-side. > > What does everyone think? This shouldn't be difficult and it shouldn't > impact web-applications at all. > > Dave > > > > > ------------------------------------------------------------------------------ > Register Now & Save for Velocity, the Web Performance & Operations > Conference from O'Reilly Media. Velocity features a full day of > expert-led, hands-on workshops and two days of sessions from industry > leaders in dedicated Performance & Operations tracks. Use code vel09scf > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf > _______________________________________________ > Wonder-disc mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wonder-disc >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
