First, let me say that one of the things I've loved about the XDoclet community is that its been very best-practices focused. When folks ask questions about how to do something with XDoclet that violates basic EJB common sense and best practices then usually the community says "what are you nuts?!" and then provides examples of more typical ways of doing things. I'm not necessarily saying this is the case here, because you certainly have a very good grasp on a complex scenario, but let me add some thoughts below....
On Friday, March 21, 2003, at 09:54 AM, Chris Butler wrote:
All our form beans are wrappers for beans generated by XDoclet as
ValueObjects from CMP2 EJBs. Thus I would need to first change the EJB
template to allow for putting a tag in an EJB which would create
*another* tag in our ValueObject, which would be later parsed by
strutsvalidationxml...
I think you'll find the Struts best practices being one of not embracing the idea of a one-to-one mapping of form bean to value objects per se. Sure, in reality it comes out that way often, but its one of the reasons ActionForm is a rigid class and not an interface you can simply implement on value objects.
Others are doing similar things with mapping value objects to Struts forms as well.
In our current application we have a complex O/R tier (not using CMP or entity beans, thankfully!). But each of our objects has a value object associated with it. Form beans were created (manually, essentially) that map to the web forms, but not necessarily to value objects. In the actions we re-map form beans back to value objects, sometimes brute-force, but generally with BeanUtils.copyProperties and a set of custom Converters.
And... all our forms used struts nested tags and nested beans. We have
a few fairly complex attribute trees that would be a pain to reconstruct
from a flattened form. Struts nested tags are *fantastic* for handling
this behavior.
Be careful not to let the exceptions get in the way here. If you can get 99.9% of the way there with the current <strutsvalidationxml>, perhaps it'd be more pragmatic to program the remaining tougher pieces as a merge point static file (which is supported too).
Anyway... so it seems the biggest impediment to handling the
auto-validation check is the lack of ability to be able to add a struts
validator tag in non-form beans (as a result of project separation and
XDoclet EJB generation). However, I'm not sure why I would ever want to
put validator tags in beans that might not be related to the web app at
all. Also, introducing a dependency between the EJB code and the webapp
code is very undesirable.
My argument here would be to only use beans in form beans that are for, and only for, the web tier.
Has anyone else who uses XDoclet generated ValueObjects in forms run into this issue? It most likely would come up with folks who are using nested tags heavily in managing forms.
Good luck! And I'll certainly do what I can to assist or support any changes you need to make to the validation.xml generation to better accommodate a standard scenario. I want to avoid putting exceptional scenarios into XDoclet though. I'm sure we can find a happy medium though.
Erik
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
