Yes, just an interface is perhaps better than a class.
But how do you "connect" your implemented object to data sources ? You
still need some kind of adapters and an abstraction layer, no ?
I keep in mind the datagrid example, which - i think - might just take
an object as a data-source.
This object may be an implementation through a source adapter.
What do you think about that schema (you can rename Zend_Data as you
want ) :
Data (db, xml, array, ...)
|
|
Zend Component (Zend_Db, Zend_Xml, ...)
|
|
Specific Zend_Data_Adapter (with specific common methods implementation)
|
|
Abstraction Layer ( ? )
|
|
Zend_Data Object (with common methods)
As i'm working on a ZF implementation of PEAR quickform and datagrid, i
may be interested in developping such components for community.
nerVo schrieb:
But in a more advanced way of using ZF for developping web
application, soon or later, some components like automatic datagrids
or automatic forms will emerge.
And that's not the only reason.
If you think about it, in most cases, a web application consists in
manipulating datas from user to database, and from database to user.
But database is not the only data connector in the scene. I think
about xml, rss, php arrays, csv files, etc...
I was pondering similar things, but I am not really sure if having all
those adaptors extend from a common base class is the way to go. I'd
rather define an interface that includes methods most commonly used in
data retrieval / updating, like search(), save() and the likes...
you'd also need some means of iterating over the collections, thus a
collection object returned by, for example a search() method could
just implement a standard SPL iterator.
What do you think?
CU
Markus
