Le Jeudi 20 Juillet 2006 12:31, Frank Schönheit - Sun Microsystems Germany a
écrit :
> Hi Éric,
Hi Frank,
> > In any case, I have the impression that we need a
> > lot more brainstorming and fresh sexy ideas before we engage into such a
> > big task ;-).
>
> My favourite sexy idea ATM is to have a generic driver, which is
> parametrized with a few obejcts doing the actual implementation.
Ah. That's a violent change!
In fact, I was wondering why it was not written that way. My guess was that
drivers might be very different one with another, so it made little sense to
take the object-oriented approach: one very generic driver class, and
overloaded methods in derived classes that would do the real implementation
for the various databases. I was thinking that having a common source code
framework and then sharing all common code through libraries (like the "file
driver" library or the "SQL parsing" analysis) was intentional.
In particular, there are drivers that just pass on SQL requests to connectors,
and others that need reproduce the hard job of decoding the SQL requests. I
thought that such drivers would be too different to derive from a simple
class.
> That
> is, there's a lot of drivers which duplicate a lot of code (as you
> already noticed). A basic infrastructure for at least the simple drivers
> (which mainly differ in the code to access the concrete table data)
> could be much smaller than today's collection of single drivers. For
> instance, imagine a XTableDataProvider which hides the table data
> access, and which is plugged into a GenericPlainTableConnectionDriver
> (or so :), which does all the stuff which is currently duplicated in the
> drivers.
When I think in terms of OOP, you think in terms of UNO programming ;-).
Funny.
> That would be my favourite first step, and probably get rid of the text,
> dBase, KAB, evoab(1) drivers (and tremendously ease the implementation
> of new "plain table access" drivers).
>
> In a next step, this could be further parametrized by some
> XSortHandler/XFilterHandler (or so) interfaces, which have a default
> implementation for the above drivers, but is adapted to the backends
> which support sorting/filtering themself.
> This would allow us to get rid of the mozab and evoab2 drivers, /me thinks.
>
> The next steps would be more difficult, since the other drivers are
> different in much more aspects than the two above ("how to provide table
> data", and "how to apply orders/filters"), which is more difficult to
> abstract.
>
> But even with those "few" steps, I think we would significantly ease the
> development of drivers which access people's pet flat data store.
Indeed.
> > We should open somewhere a "blackboard" where to put such ideas for
> > infrastructure change. With "pros" and "cons" for each idea.
>
> http://wiki.services.openoffice.org/wiki/Main_Page :)
Will do.
--
- Maman, quel est le cri de la fourmi ?
- La fourmi croonde, mon chéri.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
