>>you could drive it exactly as you've described having the beans manage
>>their dirty state and have a one-to-one level mapping from the
>>persistence mechanism to nested bean (ie: have each nested bean know how
>>it's to be stored). There are various ways to take this back to the MVC
>>paradigm keeping the model totally separate, using patterns etc.
I like beans managing dirty state becuause I could possibly have one method
that can handle several different structures if it's designed right.
Maybe this:
Have all DataBeans implement an interface lets day DirtyInterface that
defines
2 methods:
public String getDirtyAttribute() and
public void callJDBC(String dirtyAttribute)
the dirtyAttribute class member could be one of several values:
insert
update
delete
(select)
callJDBCbean(String dirtyAttribute) would call a JDBCbean corresponding to
the databean,
not sure how to define this, maybe in a way similar to the mapping of
Actions?
So then in the Action associated with the ActionForm we could pass the
ActionForm into a Method that will call getDirtyAttribute and callJDBCbean
for each bean that is nested within the ActionForm.
Having trouble thinking of way to iterate through the beans, but I think
it's possible.
>>How complex are the types/structure of your hierarchy?...
Pretty simple. Actually it almost maps exactly to your example
Organization
Team
Investor
Portfolio
Stock
-john
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
