OT: Re: Spring and XWork in Ti

Ted Husted wrote: . Many other .NET applications ... Here is one C# ex: http://www.castleproject.org/movies/CoR_Overview_Smallmod.htm -- thx, .V Broadband interface (RIA) + mail box safety = Roomity.com *Your* clubs, no sign up to read, ad supported; try bro

Re: Spring and XWork in Ti

On 9/2/05, Don Brown <[EMAIL PROTECTED]> wrote: > Ted Husted wrote: > > Well, in the spirit of discussion ... > > > > An important consideration is where to put the composition. We haven't > > figured out how to use the Spring.Web wizards yet, so for our .NET > > apps we've been decomposing the "pa

Re: Spring and XWork in Ti

Ted Husted wrote: Well, in the spirit of discussion ... An important consideration is where to put the composition. We haven't figured out how to use the Spring.Web wizards yet, so for our .NET apps we've been decomposing the "pages" or "dialogs" into User Controls. The actual ASPX page then bec

Re: Spring and XWork in Ti

On 9/1/05, Joe Germuska <[EMAIL PROTECTED]> wrote: > but that XML is not a very nice way to define everything that needs > to happen, and object-level composition is also likely to be awkward > for some of these kinds of things. Well, in the spirit of discussion ... An important consideration i

Re: Spring and XWork in Ti

At this stage in the project, we are exploring problems and solutions. It can be misleading to follow the dev discussion thinking this is what the user will need to know and understand in order to use the project. Each of the components discussed here are solutions to problems. What Ti is try

Re: Spring and XWork in Ti

As MF says: "Comprehensiveness is the enemy of comprehensibility". To that end, if there is a way to have one, but not both, it's a plus. Spring + CoR + WebWork + XYZ... that looks scary (and still not defulting to "Ajax"). Don, If you like IoC, lets start w/ HiveMind (or whatever IoC + iBati

Re: Spring and XWork in Ti

At 12:41 PM -0700 9/1/05, Don Brown wrote: Hmm...well there are three main issues we are discussing here, although you mention at the end they do have some overlap: 1. Framework-level request processing 2. Action-level processing 3. Application-level page flow/workflow When was referring to co

Re: Spring and XWork in Ti

Hmm...well there are three main issues we are discussing here, although you mention at the end they do have some overlap: 1. Framework-level request processing 2. Action-level processing 3. Application-level page flow/workflow When was referring to commons-chain being a poor match for workflow

Re: Spring and XWork in Ti

Well, that is pretty cool. But, using Chain, I wouldn't use a filter. I'd define two commands, one to start the timer and one to stop the timer. The timer would go into the context, which is thread-safe. Then wherever we wanted to use the timer commands, we'd turn the command into a chain (if it

Re: Spring and XWork in Ti

On 9/1/05, Don Brown <[EMAIL PROTECTED]> wrote: Therefore, my point is an interceptor chain is better suited to a scalable, > linear process flow, while chain is better for decision points. And > neither, > I'd argue, is well suited for a robust, configurable workflow, and this > surely > we can

RE: Spring and XWork in Ti

As a dev list lurker, let me say I too am "really enjoying this discussion". I'm learning a ton. Jay http://www.vtgroup.com/ -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Thursday, September 01, 2005 1:06 PM To: Struts Developers List Subject: Re: S

Re: Spring and XWork in Ti

Perhaps an example would help convey what I'm trying to say: Take a simple case where you want to processing time and log it to a file. As a XWork interceptor, it would look like this: long startTime = System.currentTimeMillis(); String result = invocation.invoke(); long executionTime =

Re: Spring and XWork in Ti

On 9/1/05, Don Brown <[EMAIL PROTECTED]> wrote: >In that case, I find interceptors more practical, as they allow > you to have code before and after processing that uses method variables. With > Chain, you have to use a Filter and even then, there is no way to share > variables between the two blo

Re: Spring and XWork in Ti

Joe Germuska wrote: Just as we discovered Chain commands were difficult to use for Struts users (all the casting for one), Ti users will generally write interceptors and not chain commands. Interceptors are more natural, support around operations better due to easier use local variables, and

Re: Spring and XWork in Ti

Just as we discovered Chain commands were difficult to use for Struts users (all the casting for one), Ti users will generally write interceptors and not chain commands. Interceptors are more natural, support around operations better due to easier use local variables, and provider easier acces

Re: Spring and XWork in Ti

This is a good question that deserves a wiki writeup as I'm guessing I'll get asked it a lot :) While chain and xwork interceptors do overlap some in theory, they overlap very little in practice. Chain is a general purpose, chain of responsibility pattern that is better suited, IMO, for gener

Re: Spring and XWork in Ti

On 8/31/05, Don Brown <[EMAIL PROTECTED]> wrote: > I should really list this out on the wiki site. The short of it is XWork > gives us an Action framework, interceptor > chains, expression language support, l18n, validation, and the value stack. Do we need both interceptor chains and CoR chains

Re: Spring and XWork in Ti

Joe Germuska wrote: So, I really do have work I should be doing, but I couldn't help looking around XWork a little bit, and I'm just wondering why Ti needs to use both it and Spring anyway? What are the various services offered by each that aren't offered by the other? I should really list