No on both counts. I don't care for map-backed implementations because you can't get compile-time checking, although for dynamic situations, they are the best thing you have. I prefer business rules interfaces. My book doesn't go into Struts quite that far -- it uses the basic features and architecture of Struts to show how it works, and allow comparisons to other frameworks.
Thanks for the quick reply. - I don't care for map-backed implementations because you can't get compile-time checking, although for dynamic situations, they are the best thing you have. I prefer business rules interfaces. Q1) compile time checking? Q2) What are the business rules interfaces? Please elaborate. Are they something that Struts provide or your customized interfaces? I am still relatively new to Struts and it would help to know it's limitations. Regards, Anand Mathuria
If you use ActionForms, you have distinct types associated with each ActionForm property. That means when Struts populates the ActionForm, it handles conversions for you. IOW, the framework does type conversions based on the underlying types of the properties (there are well defined rules within Struts to determine how that happens). This is what I referred to as "compile time checking", although that term is a little misleading here -- it's a leftover term from a previous, similar problem. When you use maps, everything goes into the map as a String, meaning that:
All values come back to you as a String, and you have to write your own conversions
It is possible to mis-type the name of a property, and thus the framework won't populate the form correctly
In some situations, you don't know all the properties up front, so you have to use dynamic properties. Struts also has a mechanism called "DynaForms" which offers some of the advantages of both the above approaches.
Q2) What are the business rules interfaces? Please elaborate. Are they something that Struts provide or your customized interfaces?
This is a de-coupling technique that is widely used by Struts developers. Instead of having your entities directly sub-class ActionForms (bad practice because you are mixing Framework code with your model (the entities)), you create interfaces that include all the properties of the entity (called Business Rules Interfaces). Then, your actual entity classes and the ActionForm both implement the interface, and the ActionForm encapsulates one of your entity classes. The interface creates a contract between the business rules and the ActionForm, and the ActionForm proxies the property values to the encapsulated entity. This is a relatively advanced use of ActionForms, but it offers some great advantages from a design standpoint because the entities are
completely decoupled from the framework
the interface ensures that both the ActionForm and the entity agree on what information is needed
Thanks for the detailed explanations. I have used Struts List/Map backed implementation and I take care of conversions from String to the respective types. So if the result set retrieves multiple rows of data from database, the List backed implementation allowed me to display the multiple rows dynamically on the JSP using Struts iteration tags and I could associate the values to the properties by using the following syntax: "current[" + recordNo.intValue() + "].value(FIELD_NAME)" However, I could not find the syntax for configuring validation.xml anywhere in the Struts documentation or on internet. <field property="current[0 <--- can't configure to Nth or Ith element].value(WEATHER_CODE)" depends="required"> <arg0 key="label.weather"/> </field> I could not configure it to dynamically validate N number of items from the list. Will appreciate if any one can help with this syntax / configuration. Regards, Anand
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop