RE: Stupd question about Struts and EJB.
If the validate() method does the type checking then we must implement type conversion code and type checking code in every single form bean we write! On large systems, this is sometimes very unfun. Any thoughts? You could use a Visitor pattern for an application Validator. Each form would implement a Visitable interface and could be passed to the application Validator where it (the Validator) would then determine which validation to use for the form, perform the validation, and return successfully or through some exception. This way, all validation logic can reside in one location. The kind of bends some OO concepts (encapsulation), but is a nice way to decouple the validation logic from each form. HTH Robert
Re: Stupd question about Struts and EJB.
EJBs come in two flavours (as opposed to flavors), session beans and entity beans. Session beans represent business logic and rules, entity beans represent a row in the database. The model that you'd use is to have Actions do the basic processing of form elements into data beans (just regular beans, nothing special), but no business rules. The Action then calls a session bean with the data bean to do something (eg. usdate user details in the database). The session bean connects to the database with an entity bean (or more than one depending on the database structure). Visually, you'd have JSP = Action = Session Bean= Entity Bean = Database Hope that helps. At 06:37 AM 27/02/01 -0500, you wrote: I am in the process of convincing my company to go with MVC and Struts. As with any thing new, people are sometimes resistant to change. One of the opposition questions I am getting is, how will this work with EJB(problem is I don't know too much about EJB currently). Do the EJB's references just go in the Form and Action Bean and every thing else behaves the same? Are there any obvious points that I can bring up on the subject? Any help on this subject would be much appreciated! Thanks, Cameron Ingram -- Kumera - a new Open Source Content Management System for small to medium web sites written in Perl and using XML http://www.cyber4.org/kumera/index.html
Re: Stupd question about Struts and EJB.
As far as struts 1.0, the Form bean is used only to redisplay information to the jsp page. Typically the EJB might be loaded/unloaded in the action class. If you search www.mail-archives.co,m Craig talked more about this in detail. In future version of struts this may be enhanced. -Rob Cameron Ingram0 wrote: I am in the process of convincing my company to go with MVC and Struts. As with any thing new, people are sometimes resistant to change. One of the opposition questions I am getting is, how will this work with EJB(problem is I don't know too much about EJB currently). Do the EJB's references just go in the Form and Action Bean and every thing else behaves the same? Are there any obvious points that I can bring up on the subject? Any help on this subject would be much appreciated! Thanks, Cameron Ingram
Re: Stupd question about Struts and EJB.
Hello, Robert Leland wrote: As far as struts 1.0, the Form bean is used only to redisplay information to the jsp page. Typically the EJB might be loaded/unloaded in the action class. If you search www.mail-archives.co,m Craig talked more about this in detail. My understanding is that with struts you should keep your EJBs entirely independant of anything to do with struts or servlets. You can and should however have a standard naming convention for the getters and setters across the EJB, the ActionForm and the html form elements. this allows you to call PropertyUtils.copyProperties(java.lang.Object dest, java.lang.Object orig) when you are ready to store the details entered by the user. Please let me know if this does not sound right. Cheers, Nick In future version of struts this may be enhanced. -Rob Cameron Ingram0 wrote: I am in the process of convincing my company to go with MVC and Struts. As with any thing new, people are sometimes resistant to change. One of the opposition questions I am getting is, how will this work with EJB(problem is I don't know too much about EJB currently). Do the EJB's references just go in the Form and Action Bean and every thing else behaves the same? Are there any obvious points that I can bring up on the subject? Any help on this subject would be much appreciated! Thanks, Cameron Ingram
RE: Stupd question about Struts and EJB.
I use EJBs without using copyProperties although it's a matter of preference. I have a set of JavaBeans that you could call "Data Beans" because they are often similar to my Entity Beans and they don't contain any business logic. They are struts free and I pass these data beans to some EJB components. I often nest the data bean inside the ActionForm class as a property and use the Struts nested property functionality to populate the Data JavaBean directly. Sometimes I don't use a nested JavaBean and I just pass the individual properties of the form to the EJB component. I like using nested java beans better than calling copyproperties because if I have a Databean anyway, I don't want to have to redefine lots of getters and setters in the Struts form bean. Hal -Original Message- From: Nick Pellow [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 27, 2001 5:23 PM To: [EMAIL PROTECTED] Subject: Re: Stupd question about Struts and EJB. Hello, Robert Leland wrote: As far as struts 1.0, the Form bean is used only to redisplay information to the jsp page. Typically the EJB might be loaded/unloaded in the action class. If you search www.mail-archives.co,m Craig talked more about this in detail. My understanding is that with struts you should keep your EJBs entirely independant of anything to do with struts or servlets. You can and should however have a standard naming convention for the getters and setters across the EJB, the ActionForm and the html form elements. this allows you to call PropertyUtils.copyProperties(java.lang.Object dest, java.lang.Object orig) when you are ready to store the details entered by the user. Please let me know if this does not sound right. Cheers, Nick In future version of struts this may be enhanced. -Rob Cameron Ingram0 wrote: I am in the process of convincing my company to go with MVC and Struts. As with any thing new, people are sometimes resistant to change. One of the opposition questions I am getting is, how will this work with EJB(problem is I don't know too much about EJB currently). Do the EJB's references just go in the Form and Action Bean and every thing else behaves the same? Are there any obvious points that I can bring up on the subject? Any help on this subject would be much appreciated! Thanks, Cameron Ingram
Re: Stupd question about Struts and EJB.
I have the similar case with Beans not implemented "Serializable". I will use PropertyUtils.copyProperties(destBean, srcBean) to propogate the properties. Nick Pellow wrote: Hello, Robert Leland wrote: As far as struts 1.0, the Form bean is used only to redisplay information to the jsp page. Typically the EJB might be loaded/unloaded in the action class. If you search www.mail-archives.co,m Craig talked more about this in detail. My understanding is that with struts you should keep your EJBs entirely independant of anything to do with struts or servlets. You can and should however have a standard naming convention for the getters and setters across the EJB, the ActionForm and the html form elements. this allows you to call PropertyUtils.copyProperties(java.lang.Object dest, java.lang.Object orig) when you are ready to store the details entered by the user. Please let me know if this does not sound right. Cheers, Nick In future version of struts this may be enhanced. -Rob Cameron Ingram0 wrote: I am in the process of convincing my company to go with MVC and Struts. As with any thing new, people are sometimes resistant to change. One of the opposition questions I am getting is, how will this work with EJB(problem is I don't know too much about EJB currently). Do the EJB's references just go in the Form and Action Bean and every thing else behaves the same? Are there any obvious points that I can bring up on the subject? Any help on this subject would be much appreciated! Thanks, Cameron Ingram
Re: Stupd question about Struts and EJB.
[EMAIL PROTECTED] wrote: This is the approach that I am using, but to simplify the design I have interconnected the view and model. I would like to eliminate this coupling- so if anyone has some suggestions or could recommend a pattern I could apply please let me know :) What I am doing is creating entity beans that resemble the ActionForm as much as possible- for the most part there is a loose 1 to 1 relationship between entity EJB and ActionForm. There are some exceptions, but this is how 80% of the app is designed. I use session EJBs to manage the entity EJBs and map these to appropriate ActionForms (using the Struts copyProperties util). So, the session EJB must be aware of the ActionForm, since this is the object that it returns. To persist data, the ActionServlet obtains a reference to the session EJB and would send a save() method I have implemented the ActionForm which then is copied to an entity EJB. Ideally there should be a proxy between the EJB tier and the Struts tier, so the session EJB does not need to be aware of the ActionForm. But, I am not about to create another intermediate object with the same properties and setters/getters. Some of my forms have up to 30 properties so this is way too much work! I think this should be done automatically. One more thing- the copyProperties requires that properties are the same type. But, the view is basically just String-based where the ejb tier consists of real Date, BigDecimal, etc... So what I find myself doing is creating additional methods in the ActionForm that make this transformation. For example setCustomerId(BigDecimal) and setCustomerIdStr(String). Then use the string version for Struts, and when copyProperties is invoked it will map the BigDecimal value to the EJB. Perhaps I should extend copyProperties to support basic type conversions- or has this already been done elsewhere? thoughts or suggestions? Bob, I can see what you mean. The RequestUtils.populate(Object bean, String prefix, String suffix, HttpServletRequest request) methods do no type conversions. So do you call the additional conversion methods during the validate() method on the ActionForm? I am very new to struts as is, but as I far as I can tell from reading the implementation of the above method, the ActionForm can only have String properties. Is this correct? If so, it would be nice if the ActionForm could support types other than String and the struts engine would convert these in a similar fashion as Ant does to the attributes in the xml build file. An error message could be returned to the user if they entered a String into an Integer field, say. This behavour may not be always desired, so it could be switched on and off in the Action. This may open a can of worms however, Date formats spring to mind. However, comming from a background of using tags in anger, I wrote a lot of code converting Strings to other objects, (mostly Longs, ints, (B)booleans ). Just my 2 Bobs worth. cheers, Nick Thanks, Bob -Original Message- From: Nick Pellow [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 27, 2001 5:23 PM To: [EMAIL PROTECTED] Subject: Re: Stupd question about Struts and EJB. Hello, Robert Leland wrote: As far as struts 1.0, the Form bean is used only to redisplay information to the jsp page. Typically the EJB might be loaded/unloaded in the action class. If you search www.mail-archives.co,m Craig talked more about this in detail. My understanding is that with struts you should keep your EJBs entirely independant of anything to do with struts or servlets. You can and should however have a standard naming convention for the getters and setters across the EJB, the ActionForm and the html form elements. this allows you to call PropertyUtils.copyProperties(java.lang.Object dest, java.lang.Object orig) when you are ready to store the details entered by the user. Please let me know if this does not sound right. Cheers, Nick In future version of struts this may be enhanced. -Rob Cameron Ingram0 wrote: I am in the process of convincing my company to go with MVC and Struts. As with any thing new, people are sometimes resistant to change. One of the opposition questions I am getting is, how will this work with EJB(problem is I don't know too much about EJB currently). Do the EJB's references just go in the Form and Action Bean and every thing else behaves the same? Are there any obvious points that I can bring up on the subject? Any help on this subject would be much appreciated! Thanks, Cameron Ingram
Re: Stupd question about Struts and EJB.
At 11:17 AM 2/28/01 +1100, Nick Pellow wrote: I am very new to struts as is, but as I far as I can tell from reading the implementation of the above method, the ActionForm can only have String properties. Is this correct? If so, it would be nice if the ActionForm could support types other than String and the struts engine would convert these in a similar fashion as Ant does to the attributes in the xml build file. Actually, Struts will attempt to convert values as it populates a form bean. This is done in BeanUtils.populate(), which is called right at the end of RequestUtils.populate(). However, the problem is what to do if it can't be converted. For example, if I define a form bean property as an int, and the request contains "abc", what should Struts do? In 1.0, it will set the property to a (configurable) default value, but that's not a good solution when there's no obvious candidate meaning "invalid" (e.g. for a boolean). It also destroys the original user input, so when validate() fails and returns the user to the input form, you can no longer display to them the mistake they made. (By default, in the situation I described above, the user would see "0" where they entered "abc".) So it's really best if form bean properties are all strings. What you *can* do, though, is have your validate() method check that the value can be converted to what you want, and return an error if it can't. For example, you might use Integer.parseInt() to ensure that a valid integer was entered. -- Martin Cooper Tumbleweed Communications
Re: Stupd question about Struts and EJB.
Martin,
[EMAIL PROTECTED] wrote:
At 11:17 AM 2/28/01 +1100, Nick Pellow wrote:
I am very new to struts as is, but as I far as I can tell from reading
the implementation of the above method,
the ActionForm can only have String properties. Is this correct?
If so, it would be nice if the ActionForm could support types other than
String and the
struts engine would convert these in a similar fashion as Ant does to
the attributes in the xml build file.
Actually, Struts will attempt to convert values as it populates a form
bean. This is done in BeanUtils.populate(), which is called right at the
end of RequestUtils.populate().
Ooops, thats what I was looking for but did not find.
However, the problem is what to do if it
can't be converted. For example, if I define a form bean property as an
int, and the request contains "abc", what should Struts do?
Struts could create an ActionErrors object with an ActionError for each
conversion error.
If an error does get raised at that early stage, then one will no doubt
be raised later on
in the Action. The difference is that the coder has to
a) check for the conversion error again,
b) raise an error again.
It also means that checking for such user mistakes is spread across
mulitple layers in the application
and also across multiple components within the system. I think it would
be nice to centralize
such type checking in one part of the system.
The error message strings could be defined in a similar fashion to
errors.header and errors.footer.
Maybe something like:
errors.conversion.NumberFormatException=You must enter a number for the
{0} field, not {1}.
Then when Struts comes across a type error, it raises the error then and
there, using a resource
such as the one above to report to the user.
As mentioned earlier in this thread this option could be configurable in
Struts as it may not
always be desirable.
In 1.0, it will set the property to a (configurable) default value, but
that's not a good solution when there's no obvious candidate meaning
"invalid" (e.g. for a boolean). It also destroys the original user input,
so when validate() fails and returns the user to the input form, you can no
longer display to them the mistake they made. (By default, in the situation
I described above, the user would see "0" where they entered "abc".)
So it's really best if form bean properties are all strings. What you *can*
do, though, is have your validate() method check that the value can be
converted to what you want, and return an error if it can't. For example,
you might use Integer.parseInt() to ensure that a valid integer was entered.
If the validate() method does the type checking then we must implement
type
conversion code and type checking code in every single form bean we
write!
On large systems, this is sometimes very unfun.
Any thoughts?
Regards,
Nick
--
Martin Cooper
Tumbleweed Communications
