Re: Validation Best Practices?
That looks like an interesting project. There are a lot of things that I like about what they are doing. There are a lot of things that could be handle that way. My fear with making everything a seperate Rule class is that some things cannot be encoded as a simple rule. Somevalidation needs too much information and requires too much external information. This framework would be great as something to build on top of though. Thanks for pointing it out. Tom Joachim Ansorg-3 wrote: > > Tom, > I've read this thread with great interest. > > Currently I'm thinking about the validation problem as well. I looked at > springmodule's Bean validation framework. > (https://springmodules.dev.java.net/docs/reference/0.8/html/validation.html#beanValidator). > > Looks quite interesting to me. > Does somebody have any experience using it together with Struts 2? > > Do you have any experience now using validators in seperate classes? > If yes, which validation framework did you choose and what is you > opinion now after using this approach? > > Thanks for any hints, > Joachim > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Validation-Best-Practices--tf4685400.html#a13606501 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation Best Practices?
Tom, I've read this thread with great interest. Currently I'm thinking about the validation problem as well. I looked at springmodule's Bean validation framework. (https://springmodules.dev.java.net/docs/reference/0.8/html/validation.html#beanValidator). Looks quite interesting to me. Does somebody have any experience using it together with Struts 2? Do you have any experience now using validators in seperate classes? If yes, which validation framework did you choose and what is you opinion now after using this approach? Thanks for any hints, Joachim I think drools would be way overkill for simple validation. Not only would there be a high learning curve, I don't think it would handle the most involved cases. I really think we need to do Java by default. The reason I included a way to autofind the validation class is to mimic how the existing xml validation automatically works. I'm OK with doing delegation to another validator in the validate() method of the action, I just thought it might be nice to have convention over explicit delegation, but I'm open to other ideas. I would definitely use another validation API under the hood. My idea would be to have a standard set of convenience validation methods in the super class that defers to either commons validation or Spring's validation support. I'd like the validation code to be as concise as possible, an API similar to Spring's valang might work--except in java code instead of a custom language. If others would find this kind of thing useful, I think it would be useful to create a googlecode project to begin a proof of concept. Work through what the API would look like because I think it would be a great alternative to the validation framework that's in place now. (And as I stated before, I would love to use this both at the UI level and at the business logic/component level) Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation Best Practices?
Just wanted to point out: http://jcp.org/en/jsr/detail?id=303 which is relevant to our discussion. No activity on this JSR since July of '06. I'm not convinced that annotations really solve the problem. I think for anything more than simple type checking you need a true programming language to define the validation rules. -- View this message in context: http://www.nabble.com/Validation-Best-Practices--tf4685400.html#a13477655 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation Best Practices?
vels of the application". > Are you talking about doing something like validating an object returned > from a database (presumably by something like hibernate)? > > If that's the case, you might want to consider letting the objects known > how to validate themselves with something like a "boolean isValid()" > method. And them maybe delegate within that to a validator class (and > delegate *to* that from S2). > > Then you could easily ask the object, at any point, if it was valid > regardless of whether it was instantiated and populated from scratch, > instantiated and populated by a DAO, instantiated and populated by > Struts 2 after a form-post, etc. > > If you really want to get jiggy with the "automatic" stuff you could > even do AOP interception on your setters/getters/constructors. That way > you couldn't even set a property on an object that was invalid (the AOP > interceptor would throw an exception). Although the AOP route makes it > tougher to do validations that involve multiple-fields (you'd probably > want to combine setter-AOP with something like an isValid() method). > > Anyway, I'm still thinking through this myself (obviously) as I plan the > re-write our our current xml-based validators. The top choices at the > moment are: > > * Implement validation in a simple java class. Probably do S2 > integration simply by delegating to that class in the S2 validate() > method. > > * Bite the bullet, climb the curve, and use Drools (Jboss Rules). > > Curious to know what you settle on. > > - Gary > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Validation-Best-Practices--tf4685400.html#a13473039 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation Best Practices?
Tom Schneider wrote: This is essentially what we're doing as well, but it is far from an ideal situation. The issue I've seen is that you can't easily use the validators from the xml in the validate() method. Another disadvantage is that validation is in 2 different places. Also, some of our validate() methods get pretty verbose--about 400 lines in one instance I looked at. We'd also like to use the same validation code in the UI and in our business components. Additionally, sometimes we need to call into the process layer to perform certain validation. It also is hard to reuse validation using this technique. Yes. I did a lot of Webwork XML-based validation in our project (and ending up writing a good chunk of the current validation-related docs and I found out how it *really* worked) and, in the end, decided it has been pretty much a bad idea to do validation this way. It's just not suited (IMO) for anything complex for the reason you note above and many others (no refactor support in most IDE's, very difficult to write and debug complex OGNL expressions, confusing and redundant validation syntax, etc) Others seem to concur, during my exploration/documentation effort I asked essentially the same questions as you guys have (on the WebWork lists) and the general suggestion was to only use the XML-validation framework for simple stuff. * integrate Spring's valang into struts 2 * replace the current xml with validation via ruby * replace the current xml with validation via Java, in a class separate from the action Other options you might also consider are: * integrate commons validation into Struts 2 Not suggesting this, just saying. * integrate a "rules" framework like JBoss Drools This, IMO, holds promise if you need an atom-bomb worth of validation capability. The last option [java-based validation] has the most promise. That's one of our two top options: implement validation in Java classes corresponding to the "validated" class. It'll either be that or something like Drools. But Drools seems like complete overkill just as Struts 2 xml-based validation is underkill. Something along the lines of: FooAction and FooActionValidator which is automatically executed via an interceptor like the validate() method is now. FooActionValidator would have helper methods to make the validation logic very concise. I'd also like an interface like ValidationAware to capture the validation errors from lower levels of the application. (e.g. the process and dao layers) So, anyone think I'm totally off base? +1 on implementing validation in java. Easily testable if you write your validation class well. And yah, you could setup an interceptor and do a whole "auto-find-the-validator-class" sort of thing. But why? It's almost as easy to delegate, within the existing "validate" method and it's likely to be way more ide-refactor compatible than some sort of auto-class-loader thing. I'm not quite sure what you mean by "lower levels of the application". Are you talking about doing something like validating an object returned from a database (presumably by something like hibernate)? If that's the case, you might want to consider letting the objects known how to validate themselves with something like a "boolean isValid()" method. And them maybe delegate within that to a validator class (and delegate *to* that from S2). Then you could easily ask the object, at any point, if it was valid regardless of whether it was instantiated and populated from scratch, instantiated and populated by a DAO, instantiated and populated by Struts 2 after a form-post, etc. If you really want to get jiggy with the "automatic" stuff you could even do AOP interception on your setters/getters/constructors. That way you couldn't even set a property on an object that was invalid (the AOP interceptor would throw an exception). Although the AOP route makes it tougher to do validations that involve multiple-fields (you'd probably want to combine setter-AOP with something like an isValid() method). Anyway, I'm still thinking through this myself (obviously) as I plan the re-write our our current xml-based validators. The top choices at the moment are: * Implement validation in a simple java class. Probably do S2 integration simply by delegating to that class in the S2 validate() method. * Bite the bullet, climb the curve, and use Drools (Jboss Rules). Curious to know what you settle on. - Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation Best Practices?
This is essentially what we're doing as well, but it is far from an ideal situation. The issue I've seen is that you can't easily use the validators from the xml in the validate() method. Another disadvantage is that validation is in 2 different places. Also, some of our validate() methods get pretty verbose--about 400 lines in one instance I looked at. We'd also like to use the same validation code in the UI and in our business components. Additionally, sometimes we need to call into the process layer to perform certain validation. It also is hard to reuse validation using this technique. All these issues indicate that an alternative to the current validation is needed. This is especially true for bigger apps that have multiple layers and very complex validation at multiple levels. Don and I were discussing this yesterday on #struts and here are some of the options we came up with: * integrate Spring's valang into struts 2 * replace the current xml with validation via ruby * replace the current xml with validation via Java, in a class separate from the action The last option has the most promise. Something along the lines of: FooAction and FooActionValidator which is automatically executed via an interceptor like the validate() method is now. FooActionValidator would have helper methods to make the validation logic very concise. I'd also like an interface like ValidationAware to capture the validation errors from lower levels of the application. (e.g. the process and dao layers) So, anyone think I'm totally off base? I'm not ready to implement anything yet, however, I think this might solve some of the issues that we've been having with our validation. Tom Igor Vlasov wrote: > > I use validate() method from ActionSupport for complex bussines > validation.(it works in WorkFlowInterceptor). > > Sometime, for trivial fields, i can use Struts ValidationFramework.(it > works after ParameterInterceptor) > > -- View this message in context: http://www.nabble.com/Validation-Best-Practices--tf4685400.html#a13453669 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation Best Practices?
I use validate() method from ActionSupport for complex bussines validation.(it works in WorkFlowInterceptor). Sometime, for trivial fields, i can use Struts ValidationFramework.(it works after ParameterInterceptor) Sean Kleinjung-2 wrote: > > Hey, > > I have a question concerning where validation should be performed, and > what people feel best practices are. Specifically, I have a number of > business objects that validate parameters supplied to their setters > for correctness, and throw IllegalArgumentExceptions if something is > invalid. For example, in a hypothetical Person class I would have: > > ... > public void setAge(int age) { > if (age < 0) throw new MyInvalidValueException("some i18n-ed > error msg"); > this.age = age; > } > > > This is done so that if there is a failure to properly validate at > some other layer of the application, it will fail-fast and allow the > problem to be debugged more easily. (It also gives confidence that all > references to a business object do not contain invalid data.) > > Now, we are using Struts2 and intend to use the provided annotations > for validation. The problem is, if I create the app so that HTTP > parameters are set directly on the business objects (by using a 'name' > value of "person.name" for a form field, for example), these > exceptions will prevent the value from being set, so validation is > never performed (and no errors are set on the action). > > The way I see it, I have three options: > > 1) Remove all validity checks from the business objects, and rely on > Struts to validate incoming data, and the DAO layer to validate them > before inserting. This would probably be the simplest option, but I > wanted to get peoples thoughts on it first. Are argument checks like > the ones above a good idea? Or is it better to have these type of > objects be dumb-data transfer objects that will carry any value they > are given? > > 2) Duplicate all properties of the business objects on the struts > actions, where they can be validated using the validation annotations. > The action methods must then copy the values into the business objects > as needed. This would allow the business objects to remain unchanged, > but has a lot of duplication and maintenance overhead if fields are > added/removed/changed. (It basically reminds me of the nightmare of > Struts1 form beans :p ) > > 3) Extend the ParametersInterceptor and/or validation interceptor to > do some kind of "magic" involving catching the argument exceptions, > setting appropriate errors on the action, and preserving the invalid > values so that they can be redisplayed on the form. This option is > definitely the most work (and I haven't looked at the Struts source > closely enough to know exactly how much is involved, and if its even > possibly to do in an elegant fashion). > > So in addition to commenting on the above specific situation, the > general question is this: should business objects be self-validating, > and how should they handle validation errors? > > Thanks in advance for any input, > Sean Kleinjung > AV Support, Inc. > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Validation-Best-Practices--tf4685400.html#a13423610 Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Validation Best Practices?
Hey, I have a question concerning where validation should be performed, and what people feel best practices are. Specifically, I have a number of business objects that validate parameters supplied to their setters for correctness, and throw IllegalArgumentExceptions if something is invalid. For example, in a hypothetical Person class I would have: ... public void setAge(int age) { if (age < 0) throw new MyInvalidValueException("some i18n-ed error msg"); this.age = age; } This is done so that if there is a failure to properly validate at some other layer of the application, it will fail-fast and allow the problem to be debugged more easily. (It also gives confidence that all references to a business object do not contain invalid data.) Now, we are using Struts2 and intend to use the provided annotations for validation. The problem is, if I create the app so that HTTP parameters are set directly on the business objects (by using a 'name' value of "person.name" for a form field, for example), these exceptions will prevent the value from being set, so validation is never performed (and no errors are set on the action). The way I see it, I have three options: 1) Remove all validity checks from the business objects, and rely on Struts to validate incoming data, and the DAO layer to validate them before inserting. This would probably be the simplest option, but I wanted to get peoples thoughts on it first. Are argument checks like the ones above a good idea? Or is it better to have these type of objects be dumb-data transfer objects that will carry any value they are given? 2) Duplicate all properties of the business objects on the struts actions, where they can be validated using the validation annotations. The action methods must then copy the values into the business objects as needed. This would allow the business objects to remain unchanged, but has a lot of duplication and maintenance overhead if fields are added/removed/changed. (It basically reminds me of the nightmare of Struts1 form beans :p ) 3) Extend the ParametersInterceptor and/or validation interceptor to do some kind of "magic" involving catching the argument exceptions, setting appropriate errors on the action, and preserving the invalid values so that they can be redisplayed on the form. This option is definitely the most work (and I haven't looked at the Struts source closely enough to know exactly how much is involved, and if its even possibly to do in an elegant fashion). So in addition to commenting on the above specific situation, the general question is this: should business objects be self-validating, and how should they handle validation errors? Thanks in advance for any input, Sean Kleinjung AV Support, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Form field validation - best practices
In our application, the implementation for error message handling is: using a HashMap for error messages with the form propertyName as the key. This prevents duplicate messages for form fields. Taking one example use-case: zipCode, rules are: must be numeric, and must be at least 5-digits in length. Debated in our group is the need for having both messages presented to the user if "qwe" were entered for a zip code. Granted, this simple use case may not be the best example of needing multiple messages. But we feel the implementation should support it. Changing the HashMap key to propertyName+messageName would suffice, but the need for this change is pending our findings on best-practices. I searched the archives for "+validation +'per field' " with few results that did not really address this question.
Re: validation -- best practices
Suzanne Rizzo wrote: I don't know if this is a good practice or not, but my app uses two entries in struts-config. One with validate="true" and one with validate="false". I 've never actually used the validate="true" in my code; I have an action superclass that checks for the request type. If it's a GET, I do anything I need to then forward to the JSP. If it's a POST, I run validation manually then continue on. (I POST all form submissions out of habit.) It's a little more work in the code, I suppose, but since it's a superclass I don't really think about it anymore. That might be another way around the issue without any link fixup/etc. as long as you're POSTing to the same action that shows the form. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: validation -- best practices
I don't know if this is a good practice or not, but my app uses two entries in struts-config. One with validate="true" and one with validate="false". When linking to the page for the first time, I link to the action with the validation turned off. When submitting the form, I submit to the action with the validation turned on. This way I can use a struts action instead of a jsp for the initial page, but the initial page doesn't show errors before the user gets a chance to enter information. Peter Maas <[EMAIL PROTECTED]> 06/08/2005 08:28 AM Please respond to "Struts Users Mailing List" To Struts Users Mailing List cc Subject RE: validation -- best practices I also perform client side validation, however what I don't want is validation BEFORE the user actually got a change to enter data... which is what happens now... On Wed, 2005-06-08 at 07:45 -0400, Kalyanasundaram, Arun Sakthi (Cognizant) wrote: > Hi Peter, > > The validation that is basically performed in the approach you have > specified is client side validation. > > Please elaborate more why you want to make a server hit before the data > is validated and corrected in Client side itself. > > Thanks and Regards, > Arun Sakthi > -Original Message- > From: Peter Maas [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 08, 2005 5:08 PM > To: Struts Users Mailing List > Subject: validation -- best practices > > I have a question about the validation in struts. > > Imagine that we have: > > - jsp page containing the form to be validated > - formbean extending from ValidatorForm > - action to be executed on submit > - validation rules using the validation plugin > > If we put the 'validate' attribute to true in the struts-config and call > the action the form is validated correctly... but even before actually > submitting data! > > I know this can be avoided by directy calling the jsp, but especially in > the case of 'retrofitting' an application by adding validation to form > this quite often needs refactoring of links and forwards... > > What would be the way to do this? > > -- Ing. P.F.M. Maas M.A. Application Architect / Streaming Noterik Multimedia BV Prins Hendrikkade 120 1011 AM Amsterdam The Netherlands Tel: +31 (0)205929966 (office) Tel: +31 (0)205929973 (direct line) Fax: +31 (0)204688405 Web: www.noterik.nl -- Take a look at our streaming solutions: http://www.streamedit.com/demo.html Get firefox: http://www.mozilla.org/products/firefox/ --- :wq! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: validation -- best practices
Peter- I assume you have redirected your forms submittal to your customised Validator? e.g. tag displays "onSubmit=return validateMyForm(this)" Martin- - Original Message - From: "Peter Maas" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" Sent: Wednesday, June 08, 2005 8:28 AM Subject: RE: validation -- best practices I also perform client side validation, however what I don't want is validation BEFORE the user actually got a change to enter data... which is what happens now... On Wed, 2005-06-08 at 07:45 -0400, Kalyanasundaram, Arun Sakthi (Cognizant) wrote: Hi Peter, The validation that is basically performed in the approach you have specified is client side validation. Please elaborate more why you want to make a server hit before the data is validated and corrected in Client side itself. Thanks and Regards, Arun Sakthi -Original Message- From: Peter Maas [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 5:08 PM To: Struts Users Mailing List Subject: validation -- best practices I have a question about the validation in struts. Imagine that we have: - jsp page containing the form to be validated - formbean extending from ValidatorForm - action to be executed on submit - validation rules using the validation plugin If we put the 'validate' attribute to true in the struts-config and call the action the form is validated correctly... but even before actually submitting data! I know this can be avoided by directy calling the jsp, but especially in the case of 'retrofitting' an application by adding validation to form this quite often needs refactoring of links and forwards... What would be the way to do this? -- Ing. P.F.M. Maas M.A. Application Architect / Streaming Noterik Multimedia BV Prins Hendrikkade 120 1011 AM Amsterdam The Netherlands Tel: +31 (0)205929966 (office) Tel: +31 (0)205929973 (direct line) Fax: +31 (0)204688405 Web: www.noterik.nl -- Take a look at our streaming solutions: http://www.streamedit.com/demo.html Get firefox: http://www.mozilla.org/products/firefox/ --- :wq! - 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: validation -- best practices
I also perform client side validation, however what I don't want is validation BEFORE the user actually got a change to enter data... which is what happens now... On Wed, 2005-06-08 at 07:45 -0400, Kalyanasundaram, Arun Sakthi (Cognizant) wrote: > Hi Peter, > > The validation that is basically performed in the approach you have > specified is client side validation. > > Please elaborate more why you want to make a server hit before the data > is validated and corrected in Client side itself. > > Thanks and Regards, > Arun Sakthi > -Original Message- > From: Peter Maas [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 08, 2005 5:08 PM > To: Struts Users Mailing List > Subject: validation -- best practices > > I have a question about the validation in struts. > > Imagine that we have: > > - jsp page containing the form to be validated > - formbean extending from ValidatorForm > - action to be executed on submit > - validation rules using the validation plugin > > If we put the 'validate' attribute to true in the struts-config and call > the action the form is validated correctly... but even before actually > submitting data! > > I know this can be avoided by directy calling the jsp, but especially in > the case of 'retrofitting' an application by adding validation to form > this quite often needs refactoring of links and forwards... > > What would be the way to do this? > > -- Ing. P.F.M. Maas M.A. Application Architect / Streaming Noterik Multimedia BV Prins Hendrikkade 120 1011 AM Amsterdam The Netherlands Tel: +31 (0)205929966 (office) Tel: +31 (0)205929973 (direct line) Fax: +31 (0)204688405 Web: www.noterik.nl -- Take a look at our streaming solutions: http://www.streamedit.com/demo.html Get firefox: http://www.mozilla.org/products/firefox/ --- :wq! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: validation -- best practices
Hi Peter, The validation that is basically performed in the approach you have specified is client side validation. Please elaborate more why you want to make a server hit before the data is validated and corrected in Client side itself. Thanks and Regards, Arun Sakthi -Original Message- From: Peter Maas [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 5:08 PM To: Struts Users Mailing List Subject: validation -- best practices I have a question about the validation in struts. Imagine that we have: - jsp page containing the form to be validated - formbean extending from ValidatorForm - action to be executed on submit - validation rules using the validation plugin If we put the 'validate' attribute to true in the struts-config and call the action the form is validated correctly... but even before actually submitting data! I know this can be avoided by directy calling the jsp, but especially in the case of 'retrofitting' an application by adding validation to form this quite often needs refactoring of links and forwards... What would be the way to do this? -- Ing. P.F.M. Maas M.A. Application Architect / Streaming Noterik Multimedia BV Prins Hendrikkade 120 1011 AM Amsterdam The Netherlands Tel: +31 (0)205929966 (office) Tel: +31 (0)205929973 (direct line) Fax: +31 (0)204688405 Web: www.noterik.nl -- Take a look at our streaming solutions: http://www.streamedit.com/demo.html Get firefox: http://www.mozilla.org/products/firefox/ --- :wq! - 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]
validation -- best practices
I have a question about the validation in struts. Imagine that we have: - jsp page containing the form to be validated - formbean extending from ValidatorForm - action to be executed on submit - validation rules using the validation plugin If we put the 'validate' attribute to true in the struts-config and call the action the form is validated correctly... but even before actually submitting data! I know this can be avoided by directy calling the jsp, but especially in the case of 'retrofitting' an application by adding validation to form this quite often needs refactoring of links and forwards... What would be the way to do this? -- Ing. P.F.M. Maas M.A. Application Architect / Streaming Noterik Multimedia BV Prins Hendrikkade 120 1011 AM Amsterdam The Netherlands Tel: +31 (0)205929966 (office) Tel: +31 (0)205929973 (direct line) Fax: +31 (0)204688405 Web: www.noterik.nl -- Take a look at our streaming solutions: http://www.streamedit.com/demo.html Get firefox: http://www.mozilla.org/products/firefox/ --- :wq! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]