>
>
> 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.
>
I think that to get it more in line with the stupid-model-paradigm (SMP?
:) your beans could manage their dirty state, but the actual persistence
management be handled by a separate object, that takes the bean types in
overloaded methods.
eg:
persistDirtyBean(Organisation org) {...}
persistDirtyBean(Team team) {...}
persistDirtyBean(Investor investor) {...}
persistDirtyBean(Portfolio portfolio) {...}
persistDirtyBean(Stock stock) {...}
Then you could just throw whatever bean at it you needed. The class
itself could even iterate the tree itself, in that the Organisation
version of the PersistDirtyBean would get Team objects, and then from
this method could call the Team persist method for whatever team. Or you
can, in just as correct a manner, use it ad-hoc just throwing whatever
object. Means that the persist methods aren't living with their related
Object, so some OO guru may say it's not defending the faith.
There's just so many ways you can attack this. But I think that you're
in the right frame of mind to take it on at least. :)
>>> How complex are the types/structure of your hierarchy?...
>>>
> Pretty simple. Actually it almost maps exactly to your example
>
> Organization
> Team
> Investor
> Portfolio
> Stock
>
Simple until you have to persist the thing. :)
My definition of simple is when making a table you have a bean with a
collection of one type of object, that can be retrieved and updated with
one query.
Oh, I miss those days when people thought that just seeing data was
special...
...and that it was on the "Information Super-Highway"... there's a term
that brings on flash-backs.
Arron.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
