Yeah, I was pretty excited when I read about them earlier this month, but also wondered "where the heck have these guys been for the last six months?!" If I'd known what they were up to, I'd have pitched in. I think there are appreciable differences that have yet to be realized between the two (I haven't read their code at all), but definitely a lot of conceptual crossover. I'm not worried about it though, and don't want to create an adversarial vibe with anyone. I'm convinced that if anything, there's more room for collaboration these days between the different groups, and not less.
I don't talk about IoC as a selling point, but it's in there. On the Shocks website, there's a commented out section in the navigation called "Marketecture" which will include a link to a "buzzword compliance" page. There I'll address things like IoC, AOP, "pointcutting" and the like. Actions (be they application specific or systemwide) do what they do when told; the container uses metadata to build sequences, and that metadata is very simple to alter at runtime (given the right tools it could be made effortless). It gives you extremely fine-grained control over the application design, and the IoC helps promote pluggable components. Of course you can make your actions dependent upon information from other actions through the different contexts (effectively overriding the IoC), but the nature of the platform does not encourage this behavior. : ) -- N. Alex Rupp ([EMAIL PROTECTED]) ----- Original Message ----- From: "Martin Cooper" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Monday, November 17, 2003 2:14 PM Subject: Re: Greets > It sounds like you might have re-invented (aspects of) Spring: > > http://www.springframework.org/ > > Perhaps without the explicit IoC part, though. ;-) > > -- > Martin Cooper > > > > On Mon, 17 Nov 2003, n. alex rupp wrote: > > > Hello, all. > > > > I've been meaning to drop in for quite a while. I've been following Struts for > > a couple of years and using it with few complaints or questions. Earlier this > > year I hit some roadblocks in an application design, downloaded and read the > > entirety of the source code and took some issues with the architecture. > > However, since Struts' feature offering is top-notch and since the servlet > > framework community is rife with division, I decided not to be an ass and > > complain about it unless I was willing to back it up with some CODE. Instead, I > > went shopping. I checked out webwork, read the entirety of Rickard's code, and > > even forked off a small branch for my purposes, but came to similar conclusions > > about the design. > > > > But again, I didn't think it would be productive or polite to force the issue to > > either of your two communities. It's been my experience that a lot of people > > will gripe and criticize other people's software--especially the most popular > > and used software, but they'll never add a lick of positive, constructive > > feedback in the form of living code, the ultimate contribution to our little > > society. Code speaks louder than words. > > > > So anyway, while working on clientware for the MX4J and Geronimo projects this > > autumn, I designed and wrote a servlet framework from scratch to handle my > > needs. It has an aspect-oriented workflow engine that can add crosscutting > > system logic (like form processing, L10N, security, logging, etc) dynamically at > > runtime (without having to mess around with the bytecode). It can trade actions > > across classloader boundaries, enabling web applications to span across multiple > > .WAR files. This allows users to drop in a new .WAR with new metadata and new > > actions, which updates the application workflow at runtime across all modules in > > the application namespace. It handles workflow versioning and version rollback > > (in case you make changes you come to regret). It does instance pooling of all > > components and sequences. Every aspect of the system can be managed with JMX at > > runtime. To my knowledge, it should work with every type of Presentation > > technology. The concerns of the underlying framework are separated from those > > of the feature platform. Almost every component in the core framework and the > > corresponding feature platform ultimately implement one of three interfaces: > > DataSource, Workflow or Action; I didn't even try to reconcile with the MVC > > antipattern because I don't think it reflects the needs of the technology. > > > > All end-user interaction with the framework is done through a simple client > > package. The configuration file is dirt-simple and is processed into metadata > > beans in the framework which are pooled and used to direct workflow. > > > > Basically, it's just really neat and I'm having a lot of fun working on it : ) > > > > The reason I'm telling you all this is because I designed it so you could > > implement your entire feature platform (form processing & validation, i18n, > > resource bundles, whatever) on top of it, without much difficulty. Of course, I > > don't *expect* you guys to do this, but it's possible and probably wouldn't be > > that tough. Same goes for WW and other frameworks. So now (surprise) you have > > even *more* options. > > > > (I also noticed that you guys are working on a chaining implementation. Since > > my core framework performs this, I thought I should finally get in touch.) > > > > It's licensed under the Academic Free License (the ultimate business-friendly OS > > license), and I've got the beginnings of a web page up for it at > > http://shocks.sf.net. There are API docs and sample code available, although > > the framework is in alpha and I'm still refactoring the core components. (Oh > > yeah--the core is pluggable, too, in case we decide to hate it later on ; ) > > > > If this interests any of you, please drop me a line. I've got some test > > applications running successfully against it, and I'll be using it to build a > > management console for Geronimo. If there is any way I can help you guys out, > > please let me know. If not, good luck and > > > > Kind Regards, > > -- > > N. Alex Rupp ([EMAIL PROTECTED]) > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
