Hi, My name is Rudolf de Grijs and I'm new to this list.
I'm intrigued by this discussion. Actually I was starting to write a new Controller class that behaves like XForm. Using such a chain I could: 1. transform the request into an XML document 2. transform this document using XSLT (actually this functionality is avaible, right?) 3. validate the document using a XML schema 4. finally store it in some XML database (well anything is possible) At the moment I have written the above mentioned functionality and I would like to build the right Controller classes. I do have the following question: How does the Controller class relate to the view? I do understand that I need to set the model via ControllerContext, but what type of objects can be passed? Should I pass an org.w3c.dom.Document or the class itself or can you pass anything as long as the corresponding view class knows how to handle this object? Just like Aapo I'm a bit lazy and I do not want to spend to much time to figure this out (I noticed that the section about developing your own Controller class still needs to be written in the Maverick manual. Probably it's not as trivial as one might think). Kind regards, Rudolf de Grijs -----Original Message----- From: Aapo Laakkonen [mailto:[EMAIL PROTECTED]] Sent: donderdag 12 december 2002 11:38 To: [EMAIL PROTECTED] Subject: RE: [Mav-user] Re: chained controllers > 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] ------------------------------------------------------- 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]
