> One neat characteristic of this chaining > process is that Controllers can call > ControllerContext.setParam() to define > extra params to the view. If the view...
Great! > I'm a little puzzled by the original use > case. The good news is that it sounds like > our chaining approach is exactly what you're > looking for: Yes, but i didn't knew the inner workings and i was too lazy to view source code, it's great! > ...but this seems like the kind of place where > you would _want_ a client redirect. Otherwise > the URL is going to be left in an ugly state. It was a bad example, I know, :-). > BTW, there is yet another way of chaining controllers > together in Maverick. It is possible to write a custom > View for Maverick that does the chaining. So you could > have a snippet of config like this: Gee... this only get's better! :-))))) > ...but I'm not sure this buys you anything more than the > approach Jim mentioned (combined with the patch that I > will apply tonight to keep the context persistent :) Again, I have to say that you guys beat me 0-10. This is so simple framework, but somehow it has managed to do right decisions on so many things... I finally found the framework that satisfies my needs (I have tried mainly Struts and WebWork before this). > I'm actually interested in hearing more about the > use cases that drive the need for this; I've never > had a desire to do this in my web applications. As I said. This chaining makes it possible to write reusable code. With chaining you can (but you don't have to) manage logging, audit, transactions, authentication, authorization etc. things in pluggable manner (you can do these kind of things without chaining and in many places it's even better to do it without chaining). In development time you just write commands and test them. Then when you start to deploy you place these actions in proper chain that make possible to do the things mentioned above (everything you need to do is modify XML mapping file). This is also great in team development environment as the developers can do simple things that are independent units of work and test them easily. They do not possibly need to know the whole process, just one piece of chain. eg. (not very good [so lame and simple], but i hope you see my point) Developer #1: Build code that stores user to database Developer #2: Build code that checks for the correct input Developer #3: Build code that changes some parameter input to MD5 hash. Developer #5: Build code that checks whether there is already user with same user name. Developer #6: Build a view with User registration form etc. Then we just chain this: User posts information, then chain is executed: - check input and return something - check if user already exists and return something - md5 hash the password and return success - store user to db and return something I real world, people would write more complicated chains, I think? What else? We can now use eg. Input checking controller in eg. case where User wants to modify his information. We can reuse MD5 hash command is reusable, ... I'm I completely lost, do you see the usefulness of this, or am I alone with this? ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ [INVALID FOOTER]
