hello,
ah, this is going to be a fruitful discussion ....
Ulrich Nicolas Lissé wrote:
Eduardo Millán wrote:
Here you are (attached) the 'Adapter' interface i thought during this
morning.
Suggestions, reviews and critics are accepted ;-)
Regards.
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
* 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
that seems to be a point for me. i think Uli might be right here.- from
my perspective our first and most prominent task here it to define the
minimal interface that's needed by an application to interact with the
ChibaBean. lifecycle management although surely important is not part of
this task. in this respect i would agree with Uli.
we have to clearly define what purpose this interface is going to
fulfill to separate these aspects. i'll return to this further down.
* buildUI/handleProcess methods
i have a problem here understanding what the interface's intent really
is. i think it should be replacement for envrionment adapter.
envrionment adapter is - in all its ugliness - simply a hook from the
processing core to its environment or embedding application (you name
it). the new interface has to reflect that, which it perfectly does with
property access. but now some processing-oriented stuff comes into play.
right. i suspect that we look at this interface with different
expectations/views:
[1] as a way to exchange some app-specific information between the
application using Chiba and Chiba itself. i think this view is what Uli
is promoting here. the EnvironmentAdapter was born this way; when
hacking the first version of Chicoon we needed a way to pass back the
responses from Chiba submits to the Cocoon action.
[2] as a facade between application and Chiba meaning that the
application is interacting with Chiba exclusively through interface
methods. this would allow to exchange the Adapter/Context implementatin
without changing application code.
both purposes are equally justified depending on what should be
achieved. lets try to handle them seperately: [1] would be satisfied by
the get/setProperty methods proposed by Eduardo and Uli would be right
saying this is a single well-defined purpose for that interface.
after studying the sources again, i come to the following result: the
problem with the current implementation is that the controller API is
somewhat scattered between ChibaBean and ServletAdapter (as the impl of
EnvironmentAdapter) - while ChibaBean has all the methods to init and
configure the processor as well as lifecycle support (shutdown) the
ServletAdapter adds the UIGenerator functionality and the runtime
interaction with the processor (checkValue which updates the state of
the processor with new datavalues).
for my taste ChibaBean should provide the full API needed by an
application to drive complete XForms sessions. the consequence from this
would be to move the checkValue method to ChibaBean (should be renamed
setValue - not to confuse with setvalue action) and therefore completing
the interaction part (dispatch is already there). this way all 'atomic'
operations with XForms would be accessible directly without an Adapter.
it would also prevent the Adapter to grab into the guts of Chiba (as
now) to get access to some control.
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).
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.
comments anybody?
imho, this doesn't have to exposed for two reasons:
1. why should a component or class *using* that interface (like
submission) see process handling details ?
in the light of the above thought i tend to agree here.
2. these processing related method signatures seem to be special to web
adapters.
i'm not really clear about the intended usage of the interface: which
components makes use of it and how ? which component manages
implementations of that interface ? please try to lighten up things a
bit, eduardo. i think, we have to separate between finding a new
adapater or context interface and mining an abstract web adapter class.
until then,
-1
* implementation after 0.9.4 release
+1
lets take the time +1
as a first step i would propose to create an interface
'ApplicationContext' with the get/setProperty methods. we can integrate
this and go on with the next steps one by one.
Joern
regards, uli.
-------------------------------------------------------
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
| 
