Something I'm looking at now is having the various beans expose their
content as hashmaps that could be used with the populate method in
BeanUtils. If your ActionForm bean's methods matched what the server
bean returned, the Action could handle getting the map and passing it to
ActionForm bean from bean populate.
populate( myActionFormBean, myServerBean.toMap() );
Using hashmaps for configuration is a very common technique, and
exposing values as strings is also common, so bulding a toMap() method
into into a data access or value object bean seems like a Good Thing --
with or without Struts.
Personally, I would say that it is OK to design your ActionForm beans
methods to match the server bean (but not the other way around).
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
[EMAIL PROTECTED] wrote:
>
> I have a small architectural question...
>
> I have a LoggingForm bean for displaying the logging parameters on our own
> server. This contains several variables - boolean whether logging enabled,
> String current severity, Vector of possible severities, along with Vector of
> categories, each of which is a Parameter object holding key, value, description.
>
> I have a server bean which encapsulates all calls to the Server, and all of the
> above variables are obtained from one call to the server which returns a list
> containing the above in a specified order. My question is whether it is okay to
> pass the LoggingForm to the server bean and have it fill all the variables at
> once, or is this breaking the MVC separation? Should I, instead, call the
> server bean each time, to get/set each of the variables?
>
> I know all this gets a little fuzzy at times, but would appreciate any input.
>
> Thanks,
>
> Dave
