BaseBean questions [was] [ANN] Struttin' With Struts beta (newbies esp. welcome)

[Rick Reumann <r...@reumann.net>]

Thanks vic for the kind words and feedback. I replied to you privately.
Rest of this email is in regard to the BaseBeans stuff I looked it.
Comments below...

On Wed, Mar 12,'03(08:51 PM GMT-0500), Vic wrote:
   
> So consider using list/collection based beans. Ex:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/bP/WEB-INF/src/war/org/apache/scaffoldingLib/base
> Note that I use iBatis.com DAO, a good and fast SQL based DAO.
> 

I've been looking at the classes from the link above and I think
what would really help me is seeing an actual web app implement the
org.apache.scaffoldingLib.base.BaseBean and see it being used for CRUD
operations. I think you had a web app to download on your basebeans.com
site but I'm not sure what to download to see this in action (should I
look at the Portal download?)

For the sake of this discussion lets consider an application that would
allow a user to view Employees, insert an employee, update an employee
etc. (I'm thinking of updating my lessons, with your approval of course,
to incorporate some of these ideas, but I want to make sure I understand
them first:)

Using the List backed BaseBean idea, it appears that all the ActionForm
beans would extend BaseBean. I guess the big difference in this
approach, compared to the others I've seen documented, is your Form
beans are actually responsible for a lot more than just being holders
for simple form field properties.

So lets take a typical example of where a user wants to update Employee
information on a form.  I take it our EmployeeFormBean would have your
usual firstName, lastName fields, but then rather than pass this bean
off to be converted into a Data Transfer Object and then passed off to a
model layer to be updated, you would instead simply do something like
this in your Action:

(in the execute or dispatch method of an Action called for doing an
update):

EmployeeFormBean emp = (EmployeeFormBean)form;
emp.save(); //????

To do this would we need to override the BaseBean's save() method? I
assume you also would need to provide an implementation of the BaseDAO's
update(List l) method? I'm really starting to get lost here:) I think I
need a simple walk through of what would take place upon a simple update
of an employee. I'm also confused what would be held in this List (what
type of objects is it holding) and how we would know what to update in
the List? 

I also don't see how the DAOIBase fits into the picture (it has a
doUpdate(List l, String s) method but none of the classes from the link
you gave seem to implement it. The BaseBean seems to want
implementations of DAO and not DAOIBase. 

I think I should stop asking questions until I first get a better handle
on an example implentation of a BaseBean and what kind of objects are
stored in the List that backs it. If the list is used for display
purposes, such as for displaying a List of employees to the user, I get
it (I think:).. you'd have an EmployeeFormBean (which extends BaseBean)
that stores a List of EmployeeBean objects (not EmployeeFormBean
objects). I'm not sure I have that use of the List backed Form Bean
correct? Assuming I do, I'm still really confused on how the
insert/update works using a BaseBean implementation.  Where does the
transfer take place from the FormBean fields that get submitted into a
bean that some DAO could use to successfuly peform the insert/update?

Im a bit under the weather so hopefully I didn't babble too much:) I'd
really like to understand the implementation of a BaseBean better since
it sounds very interesting (yet completely different from the way I've
been using FormBeans so far).
 
 

-- 
Rick Reumann
Struttin' with Struts: 
http://www.reumann.net/do/struts/main

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

Re: BaseBean questions [was] [ANN] Struttin' With Struts beta (newbies esp. welcome)

[Vic Cekvenich <vc...@basebeans.com>]

Rick Reumann wrote:
> On Thu, 13 Mar 2003 06:22:58 -0500
> Vic Cekvenich <vc...@basebeans.com> wrote:
>  
> 
>>Also, a bean should not do persistence, but should delegate. So I
>>create a "helper" object, a DAOImplementation. ( a DAO also has a
>>base). One thing is obvoice, a baseBean needs to CRUD, so it makes
>>sense to baseBean { public void save() { DAO.update(); }}
> 
> 
> I love the OO approach to your code, I'm just still very confused about
> how a simple implementation of a BaseBean would work in calling a DAO to
> save itself? In other words, what gets passed to the DAO from the
> BaseBean implementation to do the CRUD?
> 
> For example in a case where you had:
> 
> EmployeeFormBean extends BaseBean
> 
> I would take it EmployeeForBean would need to hold user fields such as
> firstName, lastName, address, etc with appropriate getter and setters.
> How do these fields then get passed to your DAO for the CRUD operations?
> 


A bean has getters and setters as you said, and it gets and sets them to 
a list (of a maps), where a list is a property of the Bean!
So that is why I say list/collection backed bean.
So no DAO here, and simple to "fake" for a prototype, even multi row.


Then on
bean.save(){
myDAO.update(localList);
}
That is the beans part! It delegates, so no magic or secret.


3rd, in DAO update (list l) {
// code to intalize a transaction
// code to iterate the list
// code to update each row
//code to commit, release
// Suprisingly, this code can be generic/reusable via OO
}

Yes, your implemenation is great. I will walk you over the phone.

hth,
V


> Thanks,
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

Re: BaseBean questions [was] [ANN] Struttin' With Struts beta (newbies esp. welcome)

[Rick Reumann <r...@reumann.net>]

On Thu, 13 Mar 2003 06:22:58 -0500
Vic Cekvenich <vc...@basebeans.com> wrote:
 
> Also, a bean should not do persistence, but should delegate. So I
> create a "helper" object, a DAOImplementation. ( a DAO also has a
> base). One thing is obvoice, a baseBean needs to CRUD, so it makes
> sense to baseBean { public void save() { DAO.update(); }}

I love the OO approach to your code, I'm just still very confused about
how a simple implementation of a BaseBean would work in calling a DAO to
save itself? In other words, what gets passed to the DAO from the
BaseBean implementation to do the CRUD?

For example in a case where you had:

EmployeeFormBean extends BaseBean

I would take it EmployeeForBean would need to hold user fields such as
firstName, lastName, address, etc with appropriate getter and setters.
How do these fields then get passed to your DAO for the CRUD operations?

Thanks,

-- 
Rick Reumann

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

Re: BaseBean questions [was] [ANN] Struttin' With Struts beta (newbies esp. welcome)

[Vic Cekvenich <vc...@basebeans.com>]

Rick Reumann wrote:
> Thanks vic for the kind words and feedback. I replied to you privately.
> Rest of this email is in regard to the BaseBeans stuff I looked it.
> Comments below...
> 
> On Wed, Mar 12,'03(08:51 PM GMT-0500), Vic wrote:
>    
> 
>>So consider using list/collection based beans. Ex:
>>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/bP/WEB-INF/src/war/org/apache/scaffoldingLib/base
>>Note that I use iBatis.com DAO, a good and fast SQL based DAO.
>>
> 
> 
> I've been looking at the classes from the link above and I think
> what would really help me is seeing an actual web app implement the
> org.apache.scaffoldingLib.base.BaseBean and see it being used for CRUD
> operations. I think you had a web app to download on your basebeans.com
> site but I'm not sure what to download to see this in action (should I
> look at the Portal download?)

I have not release yet, so no download. It does work, but you have to 
CVS out of sf.net or I can e-mail you separate. It's work in progress, 
dispatch is not done yet.
(I am time slicing as is everyone doing open source. As soon as a few 
more things work, I will create a early build for easier download (non-cvs))
You are welcome to use my code, its Apache license, (or develop a module 
you check in to my code, for example "user registration", similar to 
employee list above)

> 
> For the sake of this discussion lets consider an application that would
> allow a user to view Employees, insert an employee, update an employee
> etc. (I'm thinking of updating my lessons, with your approval of course,
> to incorporate some of these ideas, but I want to make sure I understand
> them first:)
> 
> Using the List backed BaseBean idea, it appears that all the ActionForm
> beans would extend BaseBean. I guess the big difference in this
> approach, compared to the others I've seen documented, is your Form
> beans are actually responsible for a lot more than just being holders
> for simple form field properties.

My design is this: A bean should delegate DAO.
Being list/collection bean is not "controversial".
Having "zero-copy" beans is.
  This lets JSTL, Model 1, SOAP, etc. etc use beans, and it's easy to 
unit test (see my abstract testIt() in bean). Also, "my" beans are 
seriazable, so server can fail over and recover session beans, or during 
development, you do not have to login.
People have called this approach simpler. When writing a complex 
application, a simpler design is helpfull.

The other design is "as intended by developers of Struts", for example:
http://www.eyde.net/eyde/index.do?date=20021021#213801 (a Struts blog)
or variation in Scaffolding in struts.sf.net.
There is a lot of DAO-type code in Action, and copying of fields, and 
being Struts bound.
Advantage is that it can more easily display "wrong" data in Validation.

Explore both.


> 
> So lets take a typical example of where a user wants to update Employee
> information on a form.  I take it our EmployeeFormBean would have your
> usual firstName, lastName fields, but then rather than pass this bean
> off to be converted into a Data Transfer Object and then passed off to a
> model layer to be updated, you would instead simply do something like
> this in your Action:
> 
> (in the execute or dispatch method of an Action called for doing an
> update):
> 
> EmployeeFormBean emp = (EmployeeFormBean)form;
> emp.save(); //????
> 
> To do this would we need to override the BaseBean's save() method? I
> assume you also would need to provide an implementation of the BaseDAO's
> update(List l) method? 

I use OO, I am very comfortable leveraging OO, since OO increases re 
usability and productivity. (and I am a certified OO instructor for like 
8 years)
Let me just say: "is a/has a", which is even on a Sun Java Cert. 
Developer exam.
Or extends/delegates is the other way. So let me try to explain the 
implementation.
There are things that are in common with beans, like *apples and 
oranges*! If you are trained in functional decomposition, top/down, 
bottom up, or structural design, you look for differences.
But OO is like genetic: Apples and Oranges are trees, grow fruit, you 
can eat it, it can peel, etc. So they are 98% same!

Point is is crate a baseBean, that I extend to create concrete form 
beans. Any code the I find that is common, I put in base (which I call 
programing after design, since even after I created a lot of concrete 
beans, I can add code and they all benefit).

Also, a bean should not do persistence, but should delegate. So I create 
a "helper" object, a DAOImplementation. ( a DAO also has a base).
One thing is obvoice, a baseBean needs to CRUD, so it makes sense to
baseBean { public void save() { DAO.update(); }}

So each concrete bean has a concrete DAO, since each bean needs it's own 
specific CRUD.
But ... I can also write generic CRUD in base DAO and baseBean, via 
reflection, getMetaData, etc.

All I am saying is extend and delegate.

One more wrinkle. DB access it the slowest part of J2EE architecture, is 
well known. A DAO design that works in development might not stale in 
production. So... Everyone *should* be able to change the DAO 
implementation without affecting the rest of the application. For 
example, Stuarts can render view via Velocity, Stxx in Borwser or JSP.
So it makes sense that you should be able to change from JDO,OJB, 
Hibernate to another persistence, if you picked the wrong one (most 
people do pick the wrong one). So I advocate that a DAO should be an 
interface, do you can say this in a bean
DAO d = new MyDAOChoice().
If you code to interface in your bean, you can replace the DAO 
mechanism. (I think everyone should use SQL based DAO (ex: ibatis, 
rowset, commonsSQL, etc.
Why? (I do not want to write a book here) ADO.net does not do O/R 
pasterns, because O/R ends up making relational in the end, and on any 
complex form, O/R can be very slow. ) So use a DAO interface.

This is just modular MVC programing, reuse, delegate, make it modular so 
you can replace the M of the MVC.

Java is OO capable, but people can code object disoriented, and it 
compiles just fine.



I'm really starting to get lost here:) I think I
> need a simple walk through of what would take place upon a simple update
> of an employee. I'm also confused what would be held in this List (what
> type of objects is it holding) and how we would know what to update in
> the List? 
> 

Lets talk voice.

> I also don't see how the DAOIBase fits into the picture (it has a
> doUpdate(List l, String s) method but none of the classes from the link
> you gave seem to implement it. The BaseBean seems to want
> implementations of DAO and not DAOIBase. 
> 
> I think I should stop asking questions until I first get a better handle
> on an example implentation of a BaseBean and what kind of objects are
> stored in the List that backs it. If the list is used for display
> purposes, such as for displaying a List of employees to the user, I get
> it (I think:).. you'd have an EmployeeFormBean (which extends BaseBean)
> that stores a List of EmployeeBean objects (not EmployeeFormBean
> objects). I'm not sure I have that use of the List backed Form Bean
> correct? Assuming I do, I'm still really confused on how the
> insert/update works using a BaseBean implementation.  Where does the
> transfer take place from the FormBean fields that get submitted into a
> bean that some DAO could use to successfuly peform the insert/update?
> 
> Im a bit under the weather so hopefully I didn't babble too much:) I'd
> really like to understand the implementation of a BaseBean better since
> it sounds very interesting (yet completely different from the way I've
> been using FormBeans so far).
>  

V
>  
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org