RE: [repost] Special view information -> ActionForm or request?
Ahh. For situations where you have something like pageA > ProcessActionA > pageB ===> ProcessActionB where pageA and pageB need 2 different forms. Yes. You would have to "insert" a SetupActionB in the chain which results in: pageA > ProcessActionA > SetupActionB ===> pageB ===> ProcessActionB Yes, SetupActionB would have to know how to extract formA data from the request and populate formB. But this sounds like a wizard style process where it might be better to use a single form for the entire process. I think this problem/solution has been hashed out on this list many times and the solution is subject to the complexity of the process. This pattern just happens to work for me and keeps things clean and separate. robert > -Original Message- > From: Joe Germuska [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 18, 2003 4:00 PM > To: Struts Users Mailing List > Subject: RE: [repost] Special view information -> ActionForm or request? > > > >I have a dynamic form defined in my struts config file and > >mapped to both SetupAction and ProcessAction. I don't have > >to manually create the form because Struts does this for me. > >Its actually very simple: > >... > >How is that clumsy? Am I missing something? > > What if the dispatch to the page preceding "ProcessAction" depends on > the submission of some form other than the one you require to handle > "SetupAction." It seems that your solution only works if you don't > need an ActionForm in SetupAction for anything except preparing the > view. > > Joe > > > -- > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "If nature worked that way, the universe would crash all the time." > --Jaron Lanier > > - > 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]
RE: [repost] Special view information -> ActionForm or request?
I have a dynamic form defined in my struts config file and mapped to both SetupAction and ProcessAction. I don't have to manually create the form because Struts does this for me. Its actually very simple: ... How is that clumsy? Am I missing something? What if the dispatch to the page preceding "ProcessAction" depends on the submission of some form other than the one you require to handle "SetupAction." It seems that your solution only works if you don't need an ActionForm in SetupAction for anything except preparing the view. Joe -- -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "If nature worked that way, the universe would crash all the time." --Jaron Lanier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [repost] Special view information -> ActionForm or request?
> I don't understand this approach. If you need special info in
> the view you
> first call a SetupAction and then have that action forward to a
> ProcessAction?
Nope. SetupAction forwards to a page; not an action.
> Maybe it does work if
> the form bean is in session scope?
It works if your form bean is in request scope too. I rarely put my
form beans in session scope.
> Also, this sounds like action chaining
> to me, which is not considered a Struts best practice.
No again. This is not chaining actions. I think you misunderstood.
I go from a SetupAction to a page which renders the view. Then,
when a user submits the form for processing it goes to ProcessAction.
Both SetupAction and ProcessAction use the same form. When a validation
error occurs, then the user is forwarded to SetupAction. The form remains
in the request and any special data that needs to be retrieved is populated
in the form by SetupAction and forwarded to the page where the original user
input along with any validation errors are displayed.
robert
> -Original Message-
> From: Sgarlata Matt [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 18, 2003 2:19 PM
> To: Struts Users Mailing List
> Subject: Re: [repost] Special view information -> ActionForm or request?
>
>
> - Original Message -
> From: "Robert Taylor" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Sent: Thursday, September 18, 2003 2:02 PM
> Subject: RE: [repost] Special view information -> ActionForm or request?
>
>
> > Sorry for jumping in, but I've been lurking on this thread
> > and I use this pattern quite frequently.
> >
> > SetupAction ===> page ===> ProcessAction ===> page
> >
> > I have a dynamic form defined in my struts config file and
> > mapped to both SetupAction and ProcessAction. I don't have
> > to manually create the form because Struts does this for me.
> > Its actually very simple:
> >
> > In SetupAction:
> >
> > ActionForward forward = mapping.findForward("success");
> > DynaBean input = (DynaBean)form;
> > // populate input
> > return forward
> >
> > Upon validation failure, my ProcessAction input attribute is set to the
> > action mapping for SetupAction. I can see how this could be
> seen as a bit
> > of a hack, but its just using the existing framework to meet my
> > requirements.
>
> I don't understand this approach. If you need special info in
> the view you
> first call a SetupAction and then have that action forward to a
> ProcessAction? I thought this wouldn't work because the form bean is
> recreated with each pass through the ActionServlet. Maybe it does work if
> the form bean is in session scope? Also, this sounds like action chaining
> to me, which is not considered a Struts best practice.
>
> > If the data to display is static I just place it in ServletContext
> > when the application starts up and there is no need to necessarily have
> > a SetupAction.
>
> I think this is a standard approach and that it is considered a
> Struts best
> practice.
>
> > Upon validation, you can simply forward directly to the input page.
> >
> >
> > How is that clumsy? Am I missing something?
> >
> > robert
>
>
> -
> 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]
Re: [repost] Special view information -> ActionForm or request?
- Original Message -
From: "Robert Taylor" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Thursday, September 18, 2003 2:02 PM
Subject: RE: [repost] Special view information -> ActionForm or request?
> Sorry for jumping in, but I've been lurking on this thread
> and I use this pattern quite frequently.
>
> SetupAction ===> page ===> ProcessAction ===> page
>
> I have a dynamic form defined in my struts config file and
> mapped to both SetupAction and ProcessAction. I don't have
> to manually create the form because Struts does this for me.
> Its actually very simple:
>
> In SetupAction:
>
> ActionForward forward = mapping.findForward("success");
> DynaBean input = (DynaBean)form;
> // populate input
> return forward
>
> Upon validation failure, my ProcessAction input attribute is set to the
> action mapping for SetupAction. I can see how this could be seen as a bit
> of a hack, but its just using the existing framework to meet my
> requirements.
I don't understand this approach. If you need special info in the view you
first call a SetupAction and then have that action forward to a
ProcessAction? I thought this wouldn't work because the form bean is
recreated with each pass through the ActionServlet. Maybe it does work if
the form bean is in session scope? Also, this sounds like action chaining
to me, which is not considered a Struts best practice.
> If the data to display is static I just place it in ServletContext
> when the application starts up and there is no need to necessarily have
> a SetupAction.
I think this is a standard approach and that it is considered a Struts best
practice.
> Upon validation, you can simply forward directly to the input page.
>
>
> How is that clumsy? Am I missing something?
>
> robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [repost] Special view information -> ActionForm or request?
- Original Message - From: "Mainguy, Mike" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> Sent: Thursday, September 18, 2003 1:44 PM Subject: RE: [repost] Special view information -> ActionForm or request? > As far as the forms are concerned, I whole-heartedly agree that the current > notion of populating the form "one the way" to getting mapped to the view > seems pretty clumsy. I would almost advocate having the forms to be > "pulled" (as above) out of some persistant service thingy (highly technical > term). Of course, it would then require that we have some sort of populate > or load method that will do something before we process anything. It seems > also like a variation of how the dispatchaction works would be kinda cool. > Allowing, either based on URL or some other request info, you to determine > if you are doing a read or a write "before" you even get to the action would > be the better way to go. This discussion is getting me to thinking that in addition to the notion of an ActionForm we need a parallel formalized java bean that is in charge of non-form information that a view needs. Perhaps this object could be called an ActionView. This could be documented with types in the struts-config file and would provide not only a convenient API for JSP developers but would also improve the documentation of how data gets transferred from the Java to JSP layer. I can't decide if the ActionView should be populated before the execution of an Action, after the execution of an Action, or during the execution of an Action. I guess the most flexible would be for it to be populated during the execution of the Action. The ActionView could be saved to the request or session with a saveActionView() method. To configure the behavior of the saveActionView() method the element in struts-config could be extended with viewBeanName and viewBeanScope attributes which would mirror the name and scope attributes for ActionForms. Another random thought is that ActionView should probably be an interface so an existing JavaBean can be used if desired. If an existing JavaBean does not exist, one could be configured similarly to DynaActionForms in struts config in a section that had syntax nearly identical to that of . > Of course, that's just my perspective, but, your notion of the clumsiness of > stuffing data into the form in the Action (especially after the request data > has already been stuffed in there once) struck a chord with me. 100% agree. ActionForm feels like it is doing double-duty if you stuff things like java.util.List into it. ActionForm should really only have boolean and String values since these are the only values that can be automatically pulled from the request parameters. > Evidently the development in struts is a little more active than I thought, > I may have to start pulling down snapshots... > > -Original Message- > From: Joe Germuska [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 18, 2003 1:29 PM > To: Struts Users Mailing List > Subject: RE: [repost] Special view information -> ActionForm or request? > > > I don't have a very strong opinion, but for form *choices*, I've > always preferred to put them into some page-accessible context before > dispatching to a page. > > I wrote a class called DigestingPlugIn which was added to Struts > after the 1.1 release which is designed to make it easy to put a menu > like this into the application context so that it's always available > to all your pages, even if they don't go through an action before > display. Of course, if the choices are dynamic and specific to the > request or the session, this doesn't work, but for things like > sharing a menu of states or countries, it works pretty well. If you > aren't comfortable using unreleased Struts code, you can get a > library version of this class from http://demo.jgsullivan.com/struts/ > > Another alternative for request/session-specific options would be to > extend the OptionsCollection tag to be smarter about how it gets the > collection for iteration -- this would allow you to route people > directly to the JSP without needing to go through an action class. > > We've been having a vigorous discussion over the last couple of days > about the best way to prefill form *values* in a pre-validation > context, and to be honest, I feel like this is a use case which > Struts doesn't address very well. It feels clumsy to fool around > with creating an ActionForm and populating it "on the way" to the > view; should I just get over that? Or is this something about Struts > that deserves a closer look with an eye towards addressing the use > case more directly?
RE: [repost] Special view information -> ActionForm or request?
Sorry for jumping in, but I've been lurking on this thread
and I use this pattern quite frequently.
SetupAction ===> page ===> ProcessAction ===> page
I have a dynamic form defined in my struts config file and
mapped to both SetupAction and ProcessAction. I don't have
to manually create the form because Struts does this for me.
Its actually very simple:
In SetupAction:
ActionForward forward = mapping.findForward("success");
DynaBean input = (DynaBean)form;
// populate input
return forward
Upon validation failure, my ProcessAction input attribute is set to the
action mapping for SetupAction. I can see how this could be seen as a bit
of a hack, but its just using the existing framework to meet my
requirements.
If the data to display is static I just place it in ServletContext
when the application starts up and there is no need to necessarily have
a SetupAction.
Upon validation, you can simply forward directly to the input page.
How is that clumsy? Am I missing something?
robert
> -Original Message-
> From: Mainguy, Mike [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 18, 2003 1:44 PM
> To: 'Struts Users Mailing List'
> Subject: RE: [repost] Special view information -> ActionForm or request?
>
>
> As far as the forms are concerned, I whole-heartedly agree that
> the current
> notion of populating the form "one the way" to getting mapped to the view
> seems pretty clumsy. I would almost advocate having the forms to be
> "pulled" (as above) out of some persistant service thingy (highly
> technical
> term). Of course, it would then require that we have some sort
> of populate
> or load method that will do something before we process anything.
> It seems
> also like a variation of how the dispatchaction works would be kinda cool.
> Allowing, either based on URL or some other request info, you to determine
> if you are doing a read or a write "before" you even get to the
> action would
> be the better way to go.
>
> Of course, that's just my perspective, but, your notion of the
> clumsiness of
> stuffing data into the form in the Action (especially after the
> request data
> has already been stuffed in there once) struck a chord with me.
>
> Evidently the development in struts is a little more active than
> I thought,
> I may have to start pulling down snapshots...
>
> -----Original Message-----
> From: Joe Germuska [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 18, 2003 1:29 PM
> To: Struts Users Mailing List
> Subject: RE: [repost] Special view information -> ActionForm or request?
>
>
> I don't have a very strong opinion, but for form *choices*, I've
> always preferred to put them into some page-accessible context before
> dispatching to a page.
>
> I wrote a class called DigestingPlugIn which was added to Struts
> after the 1.1 release which is designed to make it easy to put a menu
> like this into the application context so that it's always available
> to all your pages, even if they don't go through an action before
> display. Of course, if the choices are dynamic and specific to the
> request or the session, this doesn't work, but for things like
> sharing a menu of states or countries, it works pretty well. If you
> aren't comfortable using unreleased Struts code, you can get a
> library version of this class from http://demo.jgsullivan.com/struts/
>
> Another alternative for request/session-specific options would be to
> extend the OptionsCollection tag to be smarter about how it gets the
> collection for iteration -- this would allow you to route people
> directly to the JSP without needing to go through an action class.
>
> We've been having a vigorous discussion over the last couple of days
> about the best way to prefill form *values* in a pre-validation
> context, and to be honest, I feel like this is a use case which
> Struts doesn't address very well. It feels clumsy to fool around
> with creating an ActionForm and populating it "on the way" to the
> view; should I just get over that? Or is this something about Struts
> that deserves a closer look with an eye towards addressing the use
> case more directly? I've been meaning to search the archives to see
> what discussions have come up, but since I'm sending this message, I
> guess I'll just dump it out there and see what people think...
>
> Joe
>
>
>
>
> At 12:35 -0400 9/18/03, Mainguy, Mike wrote:
> >I also would like other's opinion on this. Right now, use a service
> >locator style class to stuff all my lookup stuff into the request
> >object manually. I have, however, used collections in the formbeans for
>
RE: [repost] Special view information -> ActionForm or request?
As far as the forms are concerned, I whole-heartedly agree that the current notion of populating the form "one the way" to getting mapped to the view seems pretty clumsy. I would almost advocate having the forms to be "pulled" (as above) out of some persistant service thingy (highly technical term). Of course, it would then require that we have some sort of populate or load method that will do something before we process anything. It seems also like a variation of how the dispatchaction works would be kinda cool. Allowing, either based on URL or some other request info, you to determine if you are doing a read or a write "before" you even get to the action would be the better way to go. Of course, that's just my perspective, but, your notion of the clumsiness of stuffing data into the form in the Action (especially after the request data has already been stuffed in there once) struck a chord with me. Evidently the development in struts is a little more active than I thought, I may have to start pulling down snapshots... -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2003 1:29 PM To: Struts Users Mailing List Subject: RE: [repost] Special view information -> ActionForm or request? I don't have a very strong opinion, but for form *choices*, I've always preferred to put them into some page-accessible context before dispatching to a page. I wrote a class called DigestingPlugIn which was added to Struts after the 1.1 release which is designed to make it easy to put a menu like this into the application context so that it's always available to all your pages, even if they don't go through an action before display. Of course, if the choices are dynamic and specific to the request or the session, this doesn't work, but for things like sharing a menu of states or countries, it works pretty well. If you aren't comfortable using unreleased Struts code, you can get a library version of this class from http://demo.jgsullivan.com/struts/ Another alternative for request/session-specific options would be to extend the OptionsCollection tag to be smarter about how it gets the collection for iteration -- this would allow you to route people directly to the JSP without needing to go through an action class. We've been having a vigorous discussion over the last couple of days about the best way to prefill form *values* in a pre-validation context, and to be honest, I feel like this is a use case which Struts doesn't address very well. It feels clumsy to fool around with creating an ActionForm and populating it "on the way" to the view; should I just get over that? Or is this something about Struts that deserves a closer look with an eye towards addressing the use case more directly? I've been meaning to search the archives to see what discussions have come up, but since I'm sending this message, I guess I'll just dump it out there and see what people think... Joe At 12:35 -0400 9/18/03, Mainguy, Mike wrote: >I also would like other's opinion on this. Right now, use a service >locator style class to stuff all my lookup stuff into the request >object manually. I have, however, used collections in the formbeans for >this. I can't, off the top of my head, think of any significant >advantages to using a form bean. One disadvantage, however, is you can >only have 1 form bean per action, so lookups across multiple actions >will need to have duplicate code. > > >-Original Message- >From: Sgarlata Matt [mailto:[EMAIL PROTECTED] >Sent: Thursday, September 18, 2003 10:15 AM >To: Struts Users Mailing List >Subject: [repost] Special view information -> ActionForm or request? > > >Sorry for the repost. Has this already been discussed? I couldn't >find it in the archives. > >Original message: > >Sometimes views need special information to display correctly, like a >bean with the values needed to render a dropdown list. Is it >considered a Struts best-practice to include this information in the >ActionForm or should the Action which prepares this information store >the information in the request instead? > >Thanks, > >Matt > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > >This message and its contents (to include attachments) are the >property of Kmart Corporation (Kmart) and may contain confidential >and proprietary information. You are hereby notified that any >disclosure, copying, or distribution of this message, or the taking >of any action based on information contained herein is strictly >prohibited. Unauthorized use of information c
RE: [repost] Special view information -> ActionForm or request?
I don't have a very strong opinion, but for form *choices*, I've always preferred to put them into some page-accessible context before dispatching to a page. I wrote a class called DigestingPlugIn which was added to Struts after the 1.1 release which is designed to make it easy to put a menu like this into the application context so that it's always available to all your pages, even if they don't go through an action before display. Of course, if the choices are dynamic and specific to the request or the session, this doesn't work, but for things like sharing a menu of states or countries, it works pretty well. If you aren't comfortable using unreleased Struts code, you can get a library version of this class from http://demo.jgsullivan.com/struts/ Another alternative for request/session-specific options would be to extend the OptionsCollection tag to be smarter about how it gets the collection for iteration -- this would allow you to route people directly to the JSP without needing to go through an action class. We've been having a vigorous discussion over the last couple of days about the best way to prefill form *values* in a pre-validation context, and to be honest, I feel like this is a use case which Struts doesn't address very well. It feels clumsy to fool around with creating an ActionForm and populating it "on the way" to the view; should I just get over that? Or is this something about Struts that deserves a closer look with an eye towards addressing the use case more directly? I've been meaning to search the archives to see what discussions have come up, but since I'm sending this message, I guess I'll just dump it out there and see what people think... Joe At 12:35 -0400 9/18/03, Mainguy, Mike wrote: I also would like other's opinion on this. Right now, use a service locator style class to stuff all my lookup stuff into the request object manually. I have, however, used collections in the formbeans for this. I can't, off the top of my head, think of any significant advantages to using a form bean. One disadvantage, however, is you can only have 1 form bean per action, so lookups across multiple actions will need to have duplicate code. -Original Message- From: Sgarlata Matt [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2003 10:15 AM To: Struts Users Mailing List Subject: [repost] Special view information -> ActionForm or request? Sorry for the repost. Has this already been discussed? I couldn't find it in the archives. Original message: Sometimes views need special information to display correctly, like a bean with the values needed to render a dropdown list. Is it considered a Struts best-practice to include this information in the ActionForm or should the Action which prepares this information store the information in the request instead? Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "If nature worked that way, the universe would crash all the time." --Jaron Lanier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [repost] Special view information -> ActionForm or request?
Good points. Originally I was leaning towards including everything in my form beans. We are using nothing but dynamic form beans in my app, so using this style the section of your struts-config file essentially becomes documentation for your JSP authors. However, lately I've been thinking it's better to store things in the request and your post gives some good reasons for that. I'm wondering how the best way to document this stuff for a JSP author would be; javadoc doesn't apply here ;) I will have to look into the service locator pattern. That could be of some help. Thanks, Matt - Original Message - From: "Mainguy, Mike" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> Sent: Thursday, September 18, 2003 12:35 PM Subject: RE: [repost] Special view information -> ActionForm or request? > I also would like other's opinion on this. Right now, use a service locator > style class to stuff all my lookup stuff into the request object manually. > I have, however, used collections in the formbeans for this. I can't, off > the top of my head, think of any significant advantages to using a form > bean. One disadvantage, however, is you can only have 1 form bean per > action, so lookups across multiple actions will need to have duplicate code. > > > -Original Message- > From: Sgarlata Matt [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 18, 2003 10:15 AM > To: Struts Users Mailing List > Subject: [repost] Special view information -> ActionForm or request? > > > Sorry for the repost. Has this already been discussed? I couldn't find it > in the archives. > > Original message: > > Sometimes views need special information to display correctly, like a bean > with the values needed to render a dropdown list. Is it considered a Struts > best-practice to include this information in the ActionForm or should the > Action which prepares this information store the information in the request > instead? > > Thanks, > > Matt > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. > > > > - > 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]
RE: [repost] Special view information -> ActionForm or request?
I also would like other's opinion on this. Right now, use a service locator style class to stuff all my lookup stuff into the request object manually. I have, however, used collections in the formbeans for this. I can't, off the top of my head, think of any significant advantages to using a form bean. One disadvantage, however, is you can only have 1 form bean per action, so lookups across multiple actions will need to have duplicate code. -Original Message- From: Sgarlata Matt [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2003 10:15 AM To: Struts Users Mailing List Subject: [repost] Special view information -> ActionForm or request? Sorry for the repost. Has this already been discussed? I couldn't find it in the archives. Original message: Sometimes views need special information to display correctly, like a bean with the values needed to render a dropdown list. Is it considered a Struts best-practice to include this information in the ActionForm or should the Action which prepares this information store the information in the request instead? Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
