Right now, DboSource is the best example available.  Examining the
relationship between Model and DboSource shows us that (besides doing
HABTM relationships, where we're still working on abstracting a few
things) a custom DataSource really only needs a few methods in order
to support a full range of CRUD operations.  The essential methods are
as follows:

query() - for generic, low-level queries (i.e., you might pass raw XML
data to this for a web service DataSource)
listSources() - optional; shows what tables or interfaces a model can
bind to.
describe() - returns an array containing a field list and descriptions
for each field in a given source; try doing a dump of
Model::loadInfo() to see the structure this should be in.

These ones are pretty self-explanatory:
create()
read()
update()
delete()
lastNumRows()
lastAffected()

$columns - your DataSource needs a columns property that maps
DataSource-native data types to Cake meta-types.

To get started, you can copy dbo_source.php and get rid of all other
methods besides the ones above.  It might look scary, but almost all
of the code in it is database-specific, and won't apply to whatever
DataSource you might like to implement.  If you're able to implement
the methods above for your DataSource (using DboSource as a guide),
you can get up and running with support for almost all model
operations, other than hasAndBelongsToMany relationships, and
Model::findNeighbors().

kabturek wrote:
> Hi Nate,
> this is interesting - could you write somthing more about it ? (a
> post ;) ? )
> Maybe some example ?
> What are the conventions for such datasources etc?
> Up until now - people just used $useTable = false and put all the
> logic in the model.
> greets,
> Marcin Domanski
>
> On Feb 7, 3:46 am, "nate" <[EMAIL PROTECTED]> wrote:
> > I definitely wasn't agreeing with you, but I wasn't really making fun
> > of you either.  I'll give you a hint: there's a reason why we have a
> > base DataSource class, which is extended by DboSource, which talks to
> > the database on behalf of a model.  Felix's Google Analytics model is
> > actually a pretty poor example.  Not because Felix is a bad coder or
> > anything (quite the contrary), but because up till now, there are a
> > few things that people really haven't clearly understood (or perhaps,
> > there are a few things we haven't made clear for people).  Basically
> > what I'm trying to say is that you should never have to extend Model
> > in that way.  Models are designed to *model* data, not handle the
> > details of accessing it.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake 
PHP" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to