Hi Francois, my pleasure. I don't think there are many people using slim or ng, understandably since they're in development, I don't push them much, they have little documentation no release train (versioning) and often see daily changes. To my knowledge, slim is currently only used in ~15 projects, all governed by myself. And admittedly, treating it more like an internal framework has been convenient since it allows me to "move fast and break stuff". I really do appreciate the interest you and others have shown the project though, despite it's somewhat chaotic public state, so thanks! But it's long overdue that I start stabilizing this and making releases and even documentation, since there's at least some interest. For a couple of years I've just always had that "one more thing" to get right before starting that process, but yeah… It's time. Just need to finish one more thing :D.
And I should probably clarify that "slim" probably isn't for everyone. The "wonder" part of the effort's name can be considered a misnomer that happened only because the project started out as a fork of Wonder. "slim" focuses entirely on WO the web framework, while I see the actual Project Wonder as being much more about it's huge collection of functionality and utility frameworks, explicitly designed and meant for use with EOF, WOF and the Foundation APIs. So… Ironically, turns out slim was really about removing most of what Wonder actually is from Wonder. So: - If you're heavily invested in WO/EOF/Wonder's frameworks and plan on staying with WO/EOF forever, Ramsey is probably covering your bases better with wonder8 (pardon Ramsey, if I'm misinterpreting your work. Just guessing at things here really) - If you only want the "web framework" part, want to reduce your dependence on Foundation/WO/EOF/WO in general and move your apps forward within the more generic Java universe, while keeping the WO ideology/methodology alive through open source (focusing on integration with ng-objects and Cayenne since that's where I'm going/partially gone), slim might be for you. Finally, to prevent misunderstanding: "wonder-slim" is an isolated effort. None of the other WO-related projects I'm working on at https://github.com/undur/ (modulo, Parsley, vermilingua, the jetty adaptor etc.) require it or depend on it and will work fine with apps using either plain WO or actual Project Wonder. Cheers, - hugi > On 3 Feb 2026, at 12:49, Francois BIENTZ <[email protected]> wrote: > > Hi Hugi > > Thank you so much for all these explanations. > I thought more people are trying out Wonder-slim and ng-objects , very > interesting projects and great work. > Francois > >> Le 3 févr. 2026 à 01:09, Hugi Thordarson <[email protected]> a écrit : >> >> … to add a non-wall-of-text reply; you can of course also just revert the >> change I made by setting the default request handler back to something more >> traditional: >> >> public Application() { >> setDefaultRequestHandler( requestHandlerForKey( >> componentRequestHandlerKey() ) ); >> // or the DA handler, as I generally preferred: >> // setDefaultRequestHandler( requestHandlerForKey( >> directActionRequestHandlerKey() ) ); >> } >> >> - hugi >> >> >>> On 2 Feb 2026, at 22:17, Hugi Thordarson <[email protected]> wrote: >>> >>> Hi Francois. >>> >>> Once again, sorry for the trouble. I keep treating wonder-slim as if I'm >>> the only one using or touching it, forgetting to check how my changes >>> affect other projects or people. Planning on making a release in the next >>> couple of weeks to fix the situation. >>> >>> The error you're seeing occurs because I changed the default request >>> handler in wonder-slim, and I'm not handling the default/initial request >>> yet (should probably just be mapped to the Main component by default like >>> in regular WO). >>> I've added some code to SlimSample to show how this can be handled, until I >>> add default handling in wonder-slim itself: >>> >>> https://github.com/undur/wonder-slim-sample/blob/2c129dc3bbe3efabbba259c3a54e89b162f52495/SlimSample/src/main/java/slim/app/Application.java#L18-L42 >>> >>> The only thing really required was the first two lines, mapping "/". The >>> other just demonstrates some of the things you can do with the routing API >>> (under development). >>> You can play around with the URLs listed there (from the server root so >>> invoke them using URLs like: http://localhost:12345/plain-response ). >>> >>> --- Why I'm doing this --- >>> In regular WO/Wonder applications, the component request handler is the >>> default request handler by default (meaning that by default the "Main" >>> component gets returned for the initial request). >>> I've changed this in wonder-slim, so that the default request handler is >>> now a "route handler" that checks the URL that was entered and handles the >>> request appropriately, as seen in the demonstration code above. >>> Note this only applies for URLs that don't start with an adaptor prefix. >>> Regular WO URLs still work and get handled as normal - that initial request >>> failing is the only visible change now if you're not using routing. >>> The basic idea is based off something I've been using for years in my >>> applications. But this particular change makes URLs in development and >>> production identical. So: >>> >>> - https://www.productionsite.com/pages/faq >>> - http://localhost:1200/pages/faq >>> >>> …both look and get handled the same way, and that makes life absolutely >>> lovely. >>> >>> But there's of course really a longer story behind the why. >>> >>> --- Why I'm ACTUALLY doing this --- >>> The 404 response returned by the routing request handler if the route is >>> not handled, gets a marker key in it's userInfo dictionary: >>> >>> https://github.com/undur/wonder-slim/blob/8a29554cc7895f363018f18168601de19f1f842c/ERExtensions/src/main/java/er/extensions/routes/RouteTable.java#L170 >>> >>> If the application is using the Jetty adaptor ( >>> https://github.com/undur/wo-adaptor-jetty ) it will check for this key and >>> if present, the adaptor knows WO didn't handle the request so it passes it >>> to the next handler in Jetty's request handler chain for handling: >>> >>> https://github.com/undur/wo-adaptor-jetty/blob/7e3ffe7101bb6e9e081043fb6036748604629b4b/src/main/java/com/webobjects/appserver/WOAdaptorJetty.java#L216-L219 >>> >>> This allows "WO" applications to exist with other applications, and only >>> urls that WO can handle get handled by WO. >>> "The next handler" in Jetty's chain can be anything. But in my case, that's >>> of course the Jetty based ng-objects adaptor :). >>> This means I can serve WO and ng-objects from the same application, >>> allowing me to gradually migrate apps feature-by-feature. >>> I'll be writing more about this soon, haven't done it yet since it's still >>> under development. And these changes shouldn't affect you at all if you're >>> not using the routing stuff. >>> >>> But here's a sample on my own site. The first URL is served by WO, the >>> second one by NG. >>> >>> - https://www.hugi.io/news/ >>> - https://www.hugi.io/ng/ >>> >>> BTW, the routing stuff is unrelated to/not dependent on any of >>> wonder/wonder-slim and can be moved to a separate library as a standalone >>> feature if anyone is interested in using it. I just added it to "slim" >>> since it was quick and easy. >>> >>> And pardon never being able to answer the simplest question without a wall >>> of text. >>> >>> Cheers, >>> - hugi >>> >>> >>> >>>>> On 2 Feb 2026, at 20:30, Francois BIENTZ via Webobjects-dev >>>>> <[email protected]> wrote: >>>> >>>> I’m sorry for the previous post >>>> >>>> I tried again the wonder-slim-sample in a wonder-slim "environment" >>>> maven 3.9 , Jdk 25 >>>> >>>> When I run the app , I get this message in the browser : >>>> No route found for URL: /cgi-bin/WebObjects/SlimSample.woa >>>> >>>> Did something change ? >>>> >>>> Thank you >>>> Francois >>> >> >
