Mensaje citado por joern turner <joern.turner-S0/GAf8tV78@xxxxxxxxxxxxxxxx>:
> hello,
>
> ah, this is going to be a fruitful discussion ....
>
> Ulrich Nicolas Lissé wrote:
> >
> > hi,
> >
> > here is my voting regarding the adapter interface
> >
> > * getProperty/setProperty methods
> > while following the 'Submission and session' thread, these methods have
> > already rendered very useful. they provide a most flexible data passing
> > mechanism between chiba core and its embedding application. however, the
> > property names to be used should follow a naming convention. ideally,
> > the common property names are stored in the same or another interface
> > for convenience.
> > +1
> again, i also agree to this methods.
>
> +1
Ok, if we just think about getting/setting properties, it is easy to plain a Map
object instead an Adapter, isn't it? I think the Adapter needs to solve more
troubles than this, encountered while using Chiba from different environments
and to fulfil common needs. For example, how to meet this requirements?
1) I need to create a Bean/DynaBean representing the instance data an put it
into another place. I may create a special *bean://context/name* submission
handler and return it within the response Map, the Adapter has to *handle* that;
or let the Adapter Implementation call getXMLContainer() or whatever new method
to obtain the instance data, and create the Bean/DynaBean on its own. Here we
have a justification for handleProcess(Object), I think. :-|
2) Another question to solve, maybe with the Adapter help, is to manage several
ChibaBean instances. Usually the application using Chiba would start several
client requests each one dealing with a different form. Think about it, ok? :-)
> > * init/release methods
> > this resembles some component oriented life-cycle mechanism. i don't
> > think it should be included in the adapater interface. don't get me
> > wrong: it is a very good practice to *implement* classes that way, but i
> > think our interface has another purpose. i think it would be better, to
> > make an adapter *implementation* implement some life-cycle interface
> > additionally when needed (e.g. in a cocoon environment).
> > 0
You're right this time, Ulrich. I agree. Removing methods... pip... pip... :-)
> > * buildUI/handleProcess methods
> following this plan the same would apply to the UIGenerator. this is
> hosted in the ServletAdapter but should reside in ChibaBean itself
> (pluggable for sure).
I see plugging a new UIGenerator is a special need for Chiba. View my later
messages in the mailing list about it. Maybe the Adapter is not the right place
to plug in them, specially if we are talking about several form instances, in
that case the ChibaBean, that is, the Chiba engine, would we the correct one.
> the more i think the more i'm happy with this approach - ChibaBean was
> always meant to become a JavaBean-like component and this also means it
> should be manageable through the API of a single class instance (the
> chibaBean instance) without the need to handle different class instances
> (as currently in ServletAdapter: it has to deal with ChibaBean and the
> UIGenerator separately).
>
> i always hesitated to move UIGenerator into ChibaBean cause it may
> simply be not needed by a specific app e.g. a full java app that
> interacts with the processor via eventhandling would not need it. a
> compromise for the moment would be to make the use of a UIGenerator
> optional.
I see no trouble whith this. If you don't need a generator just use *null* or
*default* objects. That's the way Ant uses BuildListener, or JAXP processors use
ErrorListener for example.
--
Eduardo Millán
Technical Telecommunications engineer, specialist in Telematics
Java programmer and analyst
ALBA Software: http://www.albasoft.com
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
|
