Whoa! Community!

Going through Project Wonder, it's amazing how much code and complexity it's accumulated to allow for different properties, configurations, WO versions, IDEs, build systems, deployment strategies etc... It really shows how the project evolved and was shaped by the needs, preferences and contributions of an ecosystem uncannily diverse for it's size.

Eliminating complexity

A lot of the complexity can be eliminated by making much stricter assumptions about an application's environment and configuration. wonder-slim does that and It's quite liberating, a relatively tiny example being how we determine whether an app is running in development mode.

Project Wonder contains a couple of interesting methods for this that will on every invocation check a few properties, check if we happen to be using Xcode, check if your application is an ERXApplication etc. etc.

Since slim operates under more strict assumptions this can be reduced to a single check for the existence of build.properties in the current working directory at app startup. Assigning the result of that check to a static final field also means that tiny boolean will almost certainly get inlined by the JVM when invoking isDevelopmentMode()and isDevelopmentModeSafe(). All of this makes for a shorter, nicer, simpler, and vastly more performant implementation of some pretty frequently invoked methods.

	private static final boolean _isDevelopmentMode = checkDevelopmentModeEnablingProjectBundle();

	private static boolean checkDevelopmentModeEnablingProjectBundle() {

		final boolean buildPropertiesExists = Files.exists(Path.of("build.properties"));

		if( buildPropertiesExists ) {
			System.setProperty("NSProjectBundleEnabled", "true");
			logImportantMessage( "build.properties found. Setting development mode. Setting NSProjectBundleEnabled=true" );
		}
		else {
			logImportantMessage( "No build.properties found. Assuming we're in production" );
		}

		return buildPropertiesExists;
	}
	
	public static boolean isDevelopmentModeSafe() {
		return _isDevelopmentMode;
	}

	public boolean isDevelopmentMode() {
		return _isDevelopmentMode;
	}

NSProjectBundleEnabled=true

The checking method is a bit longer than it has to be, theoretically it could really just be the single-liner Files.exists(Path.of("build.properties")).

But if we're in development mode, we know we're bundleless so we use this early opportunity to set NSProjectBundleEnabled=true (and log some info. Ok, not fantastic to have all those side-effects in a value returning method, needs some design work). This means you don't need to launch your application as a WOApplication in Eclipse/WOLips, since launching dev apps as plain java apps works fine when NSProjectBundleEnabled=true is set. Simpler and cleaner and works better with other IDEs, if that's your jam.

Yes, you can't override isDevelopmentMode() using a property anymore like in the original Wonder, but I don't recall ever doing or wanting that in my 26 years of WO. But if absolutely required, it could be re-added as a simple system property checked at the same time. And that property most definitely won't be WOIDE=Xcode.

What are the assumptions?

The basic assumptions that make slim's use and development simpler and easier aren't exactly constricting:
apart from perhaps the one about not doing anything specific to support EOF. That's one of my more selfish decisions. But that's besides the point. This project is about a web framework, not ORMs. Seriously though. Use Cayenne if you can.

• Modern JDK (>=current LTS)
• WO 5.4.3 (of course)
• Your application class inherits from ERXApplication
• WOOgnl-style inline bindings enabled (slim enables Parsley by default but you can use WOOgnl if you prefer)
• No EOF (as in; EOF will work fine but we don't do anything specific to support or augment it)
• "Normal" deployment (i.e. not deployed as a servlet, although this shouldn't be a complex addition if needed)
• The developer is willing to do things the way the framework expects rather than how they've always been done. May call for a tiny adjustment in way of thinking.
• There are more. I should really start documenting and codifying my own private mental assumptions.