On Jul 11, 2006, at 3:51 PM, [EMAIL PROTECTED] wrote:

> <snip>
> I am not sure I am doing justice to the method since I have not  
> used it
> (yet) myself, but it makes sense.  Apparently its a well known method
> in other language circles (java) but has not been generaly picked  
> up by
> php people yet.

Well, I develop in Java as well, and this "pattern" seems a little  
over patterned to me. No idea if this is what you're after, but this  
is how I might do this in Cake.

Set up your Notes M,V, and C.
Set up your Lead M,V, and C.

In another 'triad', say, my UsersController, I can call in views from  
other places using a Cake function called requestAction(). The URL  
for this page might be /users/showLead/ with your params set up any  
number of ways (maybe /users/showLead/3/3/4/1 or the GET-style ones  
you've offered as examples already.)

In the V for the showLead action, you'd see two requestAction calls,  
each bringing in the Notes and Lead triads with the right params  
passed (as gathered from the URL).

Hope that helps some.

> <snip>
> Relational Databases are really very different from Objects.  A table
> is more like an array than an object.

You say toh-may-to, I say toh-maht-oh. Whatever suits you best.

>
>>
>>> I figure for 90% of my project, the typical Object Relational  
>>> Mapping
>>> method would probably work fine, to create the CRUD type pages  
>>> needed.
>>> But that last 10% would be a total bitch to create.  This is the  
>>> same
>>> problem I have with Codecharge Studio.
>>
>> What sort of things are happening in the 10%?
>
> I have a component that lists leads from the lead table.

I'd call that component a Model in Cake parlance.

> When listing
> leads, though, I may need to JOIN with multiple other tables to get  
> all
> the data for each lead.  The columns displayed in teh final HTML are
> user settable.  So, for each lead, it may need to be joined with, say,
> the notes table to get the latest note, the user table multiple times
> to get the people assigned to that lead, the conditions for that lead,
> etc.

Cake does this through model associations. Lead hasMany Note, for  
example. (http://manual.cakephp.org/chapter/6)

>
> The columns desired are stored in a few tables.  So I have a query  
> that
> loads up the 'view' and all the 'fields'.  These do map to objects.
> Once loaded, I can call the method on the view object to generate the
> SQL for the lead list.  Each of the field objects in the view object
> knows what table needs to be joined and what needs to be added to the
> FROM and WHERE parts.  So that big SQL statement is generated, and  
> then
> passed to the lead list object where it pulls in all the data and  
> lists
> it (the view object's field objects also know how to render themselves
> and are used here too).

Again, this is like three lines in a cake model. By creating a class  
like so (yes, it's only 6 lines):

<?php
class Lead extends AppModel
{
        var $hasMany = array('Note' => array('className' => 'Note'));
}
?>

You're able to do

$something = $this->Lead->find('Lead.id = ' . $id);

In a controller and have something like this as the value for  
$something:

Array
        Lead
                firstname = joe
                lastname = shmoe
        Notes
                0
                        title = blah
                        body = more blah
                1
                        title = another note
                        body = wasn't this easy?
                

> I am not sure how this maps to what Cake has built in.  It seems like
> my little view/field object system probably does map directly to the
> tables (and yes, I could take the resulting SQL and literaly make it a
> VIEW in MySQL and then not regenerate it each time, making things a  
> bit
> faster) but the SQL it generates for the lead list seems completely
> different from how most ORM systems work.  What I dont want is 1000
> lead objects, each with 50 other objects for each bit of data,
> resulting in who knows how many separate SQL queries...

Um... this would probably be a single JOIN as executed by a Cake  
model. Give the blog tutorial in the manual a try, and you could have  
experienced the magic instead of asking me about them. :)

-- John

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to