On Feb 27, 2005, at 5:59 PM, Sylvain Wallez wrote:

Alex Romayev wrote:

I'm sort of split on this one. Would be interested in hearing other people's opinions/ideas.

There are pros and cons in doing this separation. Technically if in a typical design you would almost need to have 3 layers of beans:

1. Form Beans - used to save forms to.
2. Business Beans.
3. Data Beans -used for data persistence by say OJB or in my case Hibernate.


The Form Beans are useful, as it is frequently not possible to have the business object model available during binding. For example, it's a complex model and you are using the "Builder" pattern to properly create all the beans and their relationships or only part of the model comes from the user input and the rest from querying other systems, e.g. LDAP.


Ok, but for simple cases, you really don't need a form bean. CForms has its own data model used to shield the application data from request parameters. If you need partial binding on a repeater, have a look at the <fb:repeater> binding that can bind to existing objects without recreating them from scratch.

Hmm... this takes me back to my original question. I have a list of objects that I need to edit. Two problems:


1. I only have 1 property that I need to edit, however, it seems that I need to specify read-only ("load") bindings for all other multiple properties, so that they don't get overwritten. Is there a way to instruct the repeater-binding to not overwrite all elements, but the ones I need, for example:

  <fb:repeater id="items"
    parent-path="."
    row-path="item">

    <fb:on-bind>
      <!-- This is the attribute I want to edit -->
      <fb:value id="editable" path="editable"/>

     <!-- Do not overwrite all other attributes -->
      <fb:value id="*" path="*" direction="load"/>
    </fb:on-bind>
...

2. It appears that it is not possible to specify addmethod="add", where add is the add(Object o) of a Collection in "fb:insert-bean" when the real object being added to the list is of a different type, i.e. add(MyObject). This means that I still need to implement a wrapper bean with the add(MyObject) method.

In summary, all I'm trying to do is have a form that allows to edit one field in each item in a list and in order to achieve this (unless I'm missing something) I have to implement a wrapper object and a binding that lists all of the other completely unused attributes... talk about keeping it simple ;-)


And for more complex cases, you can also use the <fb:javascript> binding where you do anything you want to load/save the form. LDAP could go there (or in a class called there).


Business Beans provide a stronger model. For example, you might not want to have getPassword() method on your User bean and have isValidPassword(String password) instead or not provide some of the setter methods to ensure immutability of some of your fields.


The isValidPassword() isn't IMO a binding concern, but a validation problem.

True, but exposing getPassword() is a security concern ;-)


Hence, there is a need to have Data Beans, where each property has a gettter and a setter and this way can be mapped to database tables.

HOWEVER:

If I want to add an attribute I would need to change:
1. Database table
2. Object/relational mapping
3. Data bean
4. Business bean
5. Form bean
6. Form definition
7. Form binding
8. Potentially a betwixt mapping if you use the bean to stream out XML for you presentation
9. Various mapping methods, such as Form Bean to Business bean, etc


Bloody nightmare!!!


Thoughts?


Yes: forget about Form bean, and bind the form to Business bean or Data bean if there's really a need for it.

Sylvain

--
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to