A slimmed down version of Project Wonder, containing only the required basics to create and run a modern WO application.
To use this project your machine must be set up for WO development using maven. If you haven't done that, see the "Let's set it up" part here. Don't fear, this project has different versioning from the real Project Wonder and will not interfere with any other Project Wonder installations
- Clone the repository
- Run
mvn clean install
in the cloned repository's root or - …alternatively, Import the projects into your Eclipse workspace (using
Import existing projects into workspace
).
To use in an existing project you can just change the version for ERExtensions
and Ajax
to 8.0.0.slim-SNAPSHOT
in your pom.xml
. Note that since this project only includes a fraction of the original Wonder frameworks and code, compatibility is likely to be hit and miss.
Project Wonder is an old and storied collection of frameworks that's had many contributors. Over the years, it's accumulated a lot of cruft. This is an experimental project to see how Wonder can be improved, not by adding stuff but by removing stuff.
Below I enumerate a few primary goals of wonder-slim (from here on called just "Slim"), they all share the same ultimate goal, to make Wonder smaller, more manageable and maintainable, enabling faster development and delivery of features and improvements.
Project Wonder has a multitude of features and frameworks. This project is about the minimal subset that's required to create and run a modern basic WO application, nothing more, nothing less.
For this reason, the project picks four frameworks from Project Wonder as baseline, ERExtensions
, JavaWOExtensions
, Ajax
and WOOGNL
. JavaWOExtensions
and ERExtensions
have been combined since they serve a similar purpose. WOOGNL
has also been integrated into ERExtensions
in the package er.extensions.bettertemplates
and has lost it's dependency on OGNL (meaning it no longer supports OGNL expressions, just regular keyPaths and other standard associations).
This is really just an extension of "separate concerns", but since EOF is a huge part of many projects it merits a separate mention.
A web framework and a persistence framework are separate things and this project focuses only on the "web" part. Therefore, everything EOF-related has been removed. Note that this does not preclude EOF usage, because although EOF is not part of this project it doesn't mean EOF can't integrate well with it. But I consider that a separate effort.
For this reason, Slim's frameworks (notably ERExtensions) no longer do anything EOF-related nor does it use any code from JavaEOControl or JavaEOAccess. A WO application using it will still have to import these frameworks (due to JavaWebObjects referencing some classes there, such as WOEvent inheriting from EOEvent, WOSession having an EOEditingContext etc.)
ERExtensions
only pulls in two external dependencies slf4j-api
and reload4j
(as a temporary replacement for log4j 1.x) and Ajax
pulls in jabsorb
.
Note that JavaXML.framework
is not pulled in as a dependency, but rather exclusively excluded from the project's poms.
This might sound ironic since Slim is based on a closed framework. But we still reduce the usage of closed WO APIs as much as possible. This includes not using NS* collection classes, foundation utility classes etc.
This makes it easier to integrate with the java ecosystem when using and contributing code and also makes our code more reusable and future proof. That applies to both framework code and the resulting application code.
Over the years a lot of things have changed in Wonder and WO. To keep compatibility, newer releases often allow changes to be hidden, for example by keeping deprecated code around and activating it conditionally by looking at projects to see if they're "old" or by setting a property. This makes the codebase larger, harder to understand and harder to maintain. So to simplify development, "old" code is being removed and with it the option of doing things "the old way", whatever that may be.
To keep the build simple, Slim is only built using maven.
Slim targets Java 21 and does not support older JDKs. This is a part of the simplification of the development and environment through standardization.
Ok "FAQ" might be something of an overstatement, I haven't received a single question about this. But "potential questions" just sounds stupid.
No. While this is a usable framework in and off itself, it's also something of an exercise to just learn to navigate the Wonder Sources and WO's architecture, understand what's there, what's actually used, what can be improved etc. Hopefully, some of the refactorings and cleanups can be backported to Wonder itself, so everyone benefits.
In a perfect world, this effort might work it's way directly into Wonder itself. But that would require a huge effort, due to the huge amount of (highly interconnected) code in current Project Wonder.
Yes. I've used Slim in all of my active projects instead of Project Wonder for a while now. It's very nice to have an understandable, easily modifiable and (comparably) small base of framework code with a limited set of dependencies.
Sure. But be aware that the real question is probably "should I use it". I'm moving fast and breaking things at the moment and I'm not doing any releases, stable or otherwise. If there's interest in the project I might consider changing that.
Yes! Please! I'd love to get both feedback and contributions.
I should mention that this is not my own project. It's merely an organization of over two decades of work of dozens, even hundreds of people. To emphasize this, I've chosen to go the way of cloning the existing Wonder repository and keep attribution and history of the source files in question as much as possible. I have much love and respect for past contributors, many of whom are friends and colleagues.