Struts design: All actions in one ActionClass
Hi, What is the best way to design my application? Is it better to a) Put all my actions for a particluar area (i.e. creating, editing and deleting user accounts) in one Action class or b) Use a seperate action class for every action in my application or c) Put all of the actions for a particular workflow in a single Action class. I am looking to have an application that is easy to maintain and flexible. Suggestions/Advice would be most appreciated. thanks Jordan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts design: All actions in one ActionClass
-Original Message- From: Jordan Thomas [mailto:[EMAIL PROTECTED]] What is the best way to design my application? Is it better to a) Put all my actions for a particluar area (i.e. creating, editing and deleting user accounts) in one Action class or b) Use a seperate action class for every action in my application or c) Put all of the actions for a particular workflow in a single Action class. (b) in general is the best choice. Actions are basically like event handlers in a GUI. The drawback to (b) of course is that you: * have a lot of classes * have a lot of people potentially stepping on each other to add mappings to the configuration file Occasionally, when (b) is really, really overkill I'll use (c), but I usually regret it later. Just one man's opinion. Cheers, Laird -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts design: All actions in one ActionClass
For me, it's easy to maintain seperate actions. If you want to group different actions in one Action class, you might use a DispatchAction with a method for each process. Hope it helps Patrice - Original Message - From: Jordan Thomas [EMAIL PROTECTED] To: Struts-User [EMAIL PROTECTED] Sent: Wednesday, December 11, 2002 7:05 PM Subject: Struts design: All actions in one ActionClass Hi, What is the best way to design my application? Is it better to a) Put all my actions for a particluar area (i.e. creating, editing and deleting user accounts) in one Action class or b) Use a seperate action class for every action in my application or c) Put all of the actions for a particular workflow in a single Action class. I am looking to have an application that is easy to maintain and flexible. Suggestions/Advice would be most appreciated. thanks Jordan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts design: All actions in one ActionClass
Definitely b. It will be far easier to maintain. If you're worried about having a lot of actions you can look at DispatchAction or using DynaBeans. David From: Jordan Thomas [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts-User [EMAIL PROTECTED] Subject: Struts design: All actions in one ActionClass Date: Wed, 11 Dec 2002 19:05:36 +0100 Hi, What is the best way to design my application? Is it better to a) Put all my actions for a particluar area (i.e. creating, editing and deleting user accounts) in one Action class or b) Use a seperate action class for every action in my application or c) Put all of the actions for a particular workflow in a single Action class. I am looking to have an application that is easy to maintain and flexible. Suggestions/Advice would be most appreciated. thanks Jordan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts design: All actions in one ActionClass
Abolutely go with option B. We did this and if you keep all of your actual business logic outside of your actions (the only way to fly) then you end up with lots of small and easy to understand/maintain actions. This worked for us, so I'm not speaking from theory here. :-) Simon - Simon P. Chappell [EMAIL PROTECTED] Java Programming Specialist www.landsend.com Lands' End, Inc. (608) 935-4526 -Original Message- From: Jordan Thomas [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 12:06 PM To: Struts-User Subject: Struts design: All actions in one ActionClass Hi, What is the best way to design my application? Is it better to a) Put all my actions for a particluar area (i.e. creating, editing and deleting user accounts) in one Action class or b) Use a seperate action class for every action in my application or c) Put all of the actions for a particular workflow in a single Action class. I am looking to have an application that is easy to maintain and flexible. Suggestions/Advice would be most appreciated. thanks Jordan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts design: All actions in one ActionClass
where do you do your business logic ? -Original Message- From: Chappell, Simon P [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 12:52 PM To: Struts Users Mailing List Subject: RE: Struts design: All actions in one ActionClass Abolutely go with option B. We did this and if you keep all of your actual business logic outside of your actions (the only way to fly) then you end up with lots of small and easy to understand/maintain actions. This worked for us, so I'm not speaking from theory here. :-) Simon - Simon P. Chappell [EMAIL PROTECTED] Java Programming Specialist www.landsend.com Lands' End, Inc. (608) 935-4526 -Original Message- From: Jordan Thomas [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 12:06 PM To: Struts-User Subject: Struts design: All actions in one ActionClass Hi, What is the best way to design my application? Is it better to a) Put all my actions for a particluar area (i.e. creating, editing and deleting user accounts) in one Action class or b) Use a seperate action class for every action in my application or c) Put all of the actions for a particular workflow in a single Action class. I am looking to have an application that is easy to maintain and flexible. Suggestions/Advice would be most appreciated. thanks Jordan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts design: All actions in one ActionClass
In business logic classes completely outside of the Struts arena. Check out the PowerPoint presentation that I have on my website's Struts page. http://simonpeter.com/techie/java/struts/index.html This will explain some of the layering and separation that we put into our recent system. Simon - Simon P. Chappell [EMAIL PROTECTED] Java Programming Specialist www.landsend.com Lands' End, Inc. (608) 935-4526 -Original Message- From: Ron Day [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 1:01 PM To: Struts Users Mailing List Subject: RE: Struts design: All actions in one ActionClass where do you do your business logic ? -Original Message- From: Chappell, Simon P [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 12:52 PM To: Struts Users Mailing List Subject: RE: Struts design: All actions in one ActionClass Abolutely go with option B. We did this and if you keep all of your actual business logic outside of your actions (the only way to fly) then you end up with lots of small and easy to understand/maintain actions. This worked for us, so I'm not speaking from theory here. :-) Simon - Simon P. Chappell [EMAIL PROTECTED] Java Programming Specialist www.landsend.com Lands' End, Inc. (608) 935-4526 -Original Message- From: Jordan Thomas [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 12:06 PM To: Struts-User Subject: Struts design: All actions in one ActionClass Hi, What is the best way to design my application? Is it better to a) Put all my actions for a particluar area (i.e. creating, editing and deleting user accounts) in one Action class or b) Use a seperate action class for every action in my application or c) Put all of the actions for a particular workflow in a single Action class. I am looking to have an application that is easy to maintain and flexible. Suggestions/Advice would be most appreciated. thanks Jordan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts design: All actions in one ActionClass
Does this also count for the JSP's? It would seem that it would be better to reuse the JSp's where possible which seems possible. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 11 December 2002 7:27 PM To: [EMAIL PROTECTED] Subject: Re: Struts design: All actions in one ActionClass Definitely b. It will be far easier to maintain. If you're worried about having a lot of actions you can look at DispatchAction or using DynaBeans. David From: Jordan Thomas [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts-User [EMAIL PROTECTED] Subject: Struts design: All actions in one ActionClass Date: Wed, 11 Dec 2002 19:05:36 +0100 Hi, What is the best way to design my application? Is it better to a) Put all my actions for a particluar area (i.e. creating, editing and deleting user accounts) in one Action class or b) Use a seperate action class for every action in my application or c) Put all of the actions for a particular workflow in a single Action class. I am looking to have an application that is easy to maintain and flexible. Suggestions/Advice would be most appreciated. thanks Jordan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts design: All actions in one ActionClass
I apply this theory to jsps as well. Each JSP displays one thing; otherwise, you'll end up with something resembling a perl script with a bunch of if statements. This allows you to reuse the jsp in other places that need that same view (or tile). David From: Jordan Thomas [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: Struts design: All actions in one ActionClass Date: Wed, 11 Dec 2002 20:43:51 +0100 Does this also count for the JSP's? It would seem that it would be better to reuse the JSp's where possible which seems possible. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 11 December 2002 7:27 PM To: [EMAIL PROTECTED] Subject: Re: Struts design: All actions in one ActionClass Definitely b. It will be far easier to maintain. If you're worried about having a lot of actions you can look at DispatchAction or using DynaBeans. David From: Jordan Thomas [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts-User [EMAIL PROTECTED] Subject: Struts design: All actions in one ActionClass Date: Wed, 11 Dec 2002 19:05:36 +0100 Hi, What is the best way to design my application? Is it better to a) Put all my actions for a particluar area (i.e. creating, editing and deleting user accounts) in one Action class or b) Use a seperate action class for every action in my application or c) Put all of the actions for a particular workflow in a single Action class. I am looking to have an application that is easy to maintain and flexible. Suggestions/Advice would be most appreciated. thanks Jordan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts design: All actions in one ActionClass
On Wednesday, December 11, 2002, 1:05:36 PM, Jordan wrote: JT a) Put all my actions for a particluar area (i.e. creating, editing and JT deleting user accounts) in one Action class I guess I am in the minority here but lately I've been building one big DispatchAction class that acts as my controller. To me it seems very easy to maintain as each method name in the DispatchAction corresponds to something easy to understand: ie: updateEmployee(... ) insertEmpployee(... ) getEmployees( ... ) Even though this class can become very large it's very simple to work with since a) any decent IDE will show you the methods at a glance in this DispatchAction so it's just as easy to find what you need in the class as it is looking in a directory structure. b) There isn't any business logic in each of the action methods. Each action basically just handles passing the form off to a service object. In my action methods I do stuff like put certain things into request or session scope, create ActionMessages, and figure out what ActionForward to set up. That's about it. The only real drawback that I can see to this approach of one DispatchAction is it prevents other team members from working on some tasks if the one DispatchAction is getting all mucked up. Doesn't seem like a big drawback to me, though since it should only take a minute or two to add a new method to the DispatchAction. The other drawback I find is sometimes if you aren't careful the struts-config file can get confusing, but this is probably do more to my laziness. I say this because, when I can, I try to make one defined Action in the config take several dispatch values. For example I might have a mapping like: !-- Dispatch values: enterProject,insertProject,updateProject -- action path=/projects type=com.outback.taskmanager.actions.TaskManagerAction name=projectForm scope=request validate=true parameter=dispatch forward name=enterProject path=/WEB-INF/jsp/projectForm.jsp/ forward name=insert-success path=/WEB-INF/jsp/confirmation.jsp/ forward name=update-success path=/WEB-INF/jsp/confirmation.jsp/ /action Notice that if I didn't add the comments above the action it could later get confusing what action methods in your DispatchAction correspond to this action mapping. I'd be curious to know if anyone else does something similar or if I'm way off base here. To me it seems like a clean way to do things. Just me 2cents. If the approach above is bad/wrong, please let me know. Thanks, -- Rick mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts design: All actions in one ActionClass
Just for a different perspective... If we took that approach we could conceivably have hundreds of actions that looked almost identical except for the value of a few variables. So, we're building a model layer that creates and invokes components in a standardized way. So, (when it's all built) we will write hundreds of components with little nuggets of business logic to a standard interface and we'll have a couple of generic actions that perform commands on those components based on parameters in the request or settings in ActionMappings. If there are special cases where the controller logic for a component is just too complex, we'll write more actions. Or, if another application would use the components differently, they can create more actions. But for our application, this approach greatly increases productivity and eases maintenance b/c there is less code to write. Now, the drawback is that it looks a lot like EJB, except that the container is a single broker or factory class. But the advantage is that our developers can focus their attention on the business logic, focusing less attention on who called me or where do I go next. Greg -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 2:09 PM To: [EMAIL PROTECTED] Subject: RE: Struts design: All actions in one ActionClass I apply this theory to jsps as well. Each JSP displays one thing; otherwise, you'll end up with something resembling a perl script with a bunch of if statements. This allows you to reuse the jsp in other places that need that same view (or tile). David From: Jordan Thomas [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: Struts design: All actions in one ActionClass Date: Wed, 11 Dec 2002 20:43:51 +0100 Does this also count for the JSP's? It would seem that it would be better to reuse the JSp's where possible which seems possible. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 11 December 2002 7:27 PM To: [EMAIL PROTECTED] Subject: Re: Struts design: All actions in one ActionClass Definitely b. It will be far easier to maintain. If you're worried about having a lot of actions you can look at DispatchAction or using DynaBeans. David From: Jordan Thomas [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts-User [EMAIL PROTECTED] Subject: Struts design: All actions in one ActionClass Date: Wed, 11 Dec 2002 19:05:36 +0100 Hi, What is the best way to design my application? Is it better to a) Put all my actions for a particluar area (i.e. creating, editing and deleting user accounts) in one Action class or b) Use a seperate action class for every action in my application or c) Put all of the actions for a particular workflow in a single Action class. I am looking to have an application that is easy to maintain and flexible. Suggestions/Advice would be most appreciated. thanks Jordan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts design: All actions in one ActionClass
David Graham wrote: Definitely b. It will be far easier to maintain. If you're worried about having a lot of actions you can look at DispatchAction or using DynaBeans. I'll second that. For a project we started back in Feb 2001, I used small Action classes. I went away on my Honeymoon in May and came back 3 weeks later and moved on to another project. One of the developers that took over the project merged a number of the actions edit, delete, create, list into one big ugly mess. New developers that same along used that same pattern when adding new Actions, ugh ! Now 18 months later we have 5+ projects using the same set of core Action classes and there is alot of complaints about how hard it to maintain ! We are now moveing to break up those action classes. Some people just have to learn the hard way , and very expensive too I might add -Rob David From: Jordan Thomas [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts-User [EMAIL PROTECTED] Subject: Struts design: All actions in one ActionClass Date: Wed, 11 Dec 2002 19:05:36 +0100 Hi, What is the best way to design my application? Is it better to a) Put all my actions for a particluar area (i.e. creating, editing and deleting user accounts) in one Action class or b) Use a seperate action class for every action in my application or c) Put all of the actions for a particular workflow in a single Action class. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re[2]: Struts design: All actions in one ActionClass
On Wednesday, December 11, 2002, 4:16:31 PM, Rob wrote: RL One of the developers that took over the project merged a number of the RL actions RL edit, delete, create, list into one big ugly mess. Was this all being done a 'normal' action class or a DispatchAction class? I think a DispatchAction class that handles these three related operations in one class is actually very clean and easy to maintain. I could totally see the problem if it was all trying to be done from a typical action within a standard execute or perform method. -- Rick mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re[2]: Struts design: All actions in one ActionClass
Well, I guess I'll have to look into the DispatchAction thing. I've not heard of it before today. It sounds real similar to what we're doing. -Original Message- From: Rick Reumann [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 3:29 PM To: Struts Users Mailing List Subject: Re[2]: Struts design: All actions in one ActionClass On Wednesday, December 11, 2002, 4:16:31 PM, Rob wrote: RL One of the developers that took over the project merged a number of the RL actions RL edit, delete, create, list into one big ugly mess. Was this all being done a 'normal' action class or a DispatchAction class? I think a DispatchAction class that handles these three related operations in one class is actually very clean and easy to maintain. I could totally see the problem if it was all trying to be done from a typical action within a standard execute or perform method. -- Rick mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re[2]: Struts design: All actions in one ActionClass
Well, I guess I'll have to look into the DispatchAction thing. I've not heard of it before today. It sounds real similar to what we're doing. Also see LookupDispatchAction which works great if you have one form with several different actions that could happen depending on which button the user presses. The only thing I had to do with LookupDispatchAction was override 'execute' and provide a default behavior since it will blow up if the parameter you specify is not present in the request. -- Wendy
Re: Struts design: All actions in one ActionClass
There's nothing wrong with using one dispatch action for each form but if you start putting other stuff in there you're in trouble. The action would be straightforward if you had getForm, updateForm, and insertForm type of methods. Since they're calling business logic methods the action will be small. David From: Rick Reumann [EMAIL PROTECTED] Reply-To: Rick Reumann [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Re: Struts design: All actions in one ActionClass Date: Wed, 11 Dec 2002 15:51:37 -0500 On Wednesday, December 11, 2002, 1:05:36 PM, Jordan wrote: JT a) Put all my actions for a particluar area (i.e. creating, editing and JT deleting user accounts) in one Action class I guess I am in the minority here but lately I've been building one big DispatchAction class that acts as my controller. To me it seems very easy to maintain as each method name in the DispatchAction corresponds to something easy to understand: ie: updateEmployee(... ) insertEmpployee(... ) getEmployees( ... ) Even though this class can become very large it's very simple to work with since a) any decent IDE will show you the methods at a glance in this DispatchAction so it's just as easy to find what you need in the class as it is looking in a directory structure. b) There isn't any business logic in each of the action methods. Each action basically just handles passing the form off to a service object. In my action methods I do stuff like put certain things into request or session scope, create ActionMessages, and figure out what ActionForward to set up. That's about it. The only real drawback that I can see to this approach of one DispatchAction is it prevents other team members from working on some tasks if the one DispatchAction is getting all mucked up. Doesn't seem like a big drawback to me, though since it should only take a minute or two to add a new method to the DispatchAction. The other drawback I find is sometimes if you aren't careful the struts-config file can get confusing, but this is probably do more to my laziness. I say this because, when I can, I try to make one defined Action in the config take several dispatch values. For example I might have a mapping like: !-- Dispatch values: enterProject,insertProject,updateProject -- action path=/projects type=com.outback.taskmanager.actions.TaskManagerAction name=projectForm scope=request validate=true parameter=dispatch forward name=enterProject path=/WEB-INF/jsp/projectForm.jsp/ forward name=insert-success path=/WEB-INF/jsp/confirmation.jsp/ forward name=update-success path=/WEB-INF/jsp/confirmation.jsp/ /action Notice that if I didn't add the comments above the action it could later get confusing what action methods in your DispatchAction correspond to this action mapping. I'd be curious to know if anyone else does something similar or if I'm way off base here. To me it seems like a clean way to do things. Just me 2cents. If the approach above is bad/wrong, please let me know. Thanks, -- Rick mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
