Re: [Wonder-disc] Wonder Frameworks & Java Client with WebStart
Re: [Wonder-disc] Wonder Frameworks & Java Client with WebStart
- Subject: Re: [Wonder-disc] Wonder Frameworks & Java Client with WebStart
- From: John Huss <email@hidden>
- Date: Wed, 29 Apr 2009 09:48:29 -0500
+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@hidden> 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@hidden
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden