Newbie: Composition by Association - Pagination Class general question.

Hello,

I have a Animals DAO class that I'd like to apply a pagination class to =
it.

Between this two classes, there will be a composition relation (more
precisely, an association one). My question is:

Is a Pagination that "has a" Animal. OR Is a Animal that "has a" =
pagination?
Should we create on Class Pagination a property named $_animal OR, =
should we
create on class Animal a property named $_pagination?=20

I'm inclined to accept the second one, since, if I put the property =
$_animal
on my classe Pagination, I will end up, on the Pagination Class, with so
many properties as pagination objects... :s



Any help please?
M=E1rcio


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Newbie: Composition by Association - Pagination Class

2009/7/19 MEM :
> Hello,
>
> I have a Animals DAO class that I'd like to apply a pagination class to it.
>
> Between this two classes, there will be a composition relation (more
> precisely, an association one). My question is:
>
> Is a Pagination that "has a" Animal. OR Is a Animal that "has a" pagination?
> Should we create on Class Pagination a property named $_animal OR, should we
> create on class Animal a property named $_pagination?
>
> I'm inclined to accept the second one, since, if I put the property $_animal
> on my classe Pagination, I will end up, on the Pagination Class, with so
> many properties as pagination objects... :s

Pagination is the generically applicable class - it should know
nothing about what specifically it's paginating.

-Stuart

--
http://stut.net/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Newbie: Composition by Association - Pagination Class general question.

> Pagination is the generically applicable class - it should know
> nothing about what specifically it's paginating.

Ok... but I need to grab values of my DAO classes, I mean, even if we =
paginate images on a directory or records on a database table, the =
pagination should have a $limit, and a offset, a way to count how many =
item there are to work with... So it must be related with the DAO (or =
other thing) on some way, so that I can grab those values and play with =
them on the pagination class...

Should I use a Decorator Pattern to make this relation between the =
pagination and the DAO ?


Regards,
Márcio


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Newbie: Composition by Association - Pagination Class

2009/7/19 MEM :
>> Pagination is the generically applicable class - it should know
>> nothing about what specifically it's paginating.
>
> Ok... but I need to grab values of my DAO classes, I mean, even if we pag=
inate images on a directory or records on a database table, the pagination =
should have a $limit, and a offset, a way to count how many item there are =
to work with... So it must be related with the DAO (or other thing) on some=
way, so that I can grab those values and play with them on the pagination =
class...
>
> Should I use a Decorator Pattern to make this relation between the pagina=
tion and the DAO ?

I don't know how your other classes are arranged, but personally I'd
build pagination into a class that provides raw data access, then
inherit that for specific types of data like animals. Efficient
pagination is too tightly coupled to the data source to be separate.

-Stuart

--=20
http://stut.net/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Newbie: Composition by Association - Pagination Class general question.

> I don't know how your other classes are arranged,=20

myPDO.class.php -> Singleton. Makes the connection to the database =
possible.

generalDAO.class.php -> Abstract DAO Class, grabs the myPDO instance and =
could have other methods on the future that are shared for all the DAO =
classes.

AnimalsDAO.class.php -> DAO class with insertAnimal(); deleteAnimal(); =
updateAnimal(); countAnimal(); selectSpecificAnimam() methods...

The same goes for the VetDAO.class.php.


> but personally I'd
> build pagination into a class that provides raw data access, then
> inherit that for specific types of data like animals. Efficient
> pagination is too tightly coupled to the data source to be separate.

According to the above, does this suggestion of yours still apply?=20
If so, what is the buzzword that I should look at so that "inherit that =
for specific types of data like animals" could be possible? What/where =
should I look/search to accomplish your suggestion?


Regards,
Márcio=20


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Newbie: Composition by Association - Pagination Class

2009/7/19 MEM :
>> I don't know how your other classes are arranged,
>
> myPDO.class.php -> Singleton. Makes the connection to the database possible.
>
> generalDAO.class.php -> Abstract DAO Class, grabs the myPDO instance and could have other methods on the future that are shared for all the DAO classes.
>
> AnimalsDAO.class.php -> DAO class with insertAnimal(); deleteAnimal(); updateAnimal(); countAnimal(); selectSpecificAnimam() methods...
>
> The same goes for the VetDAO.class.php.
>
>
>> but personally I'd
>> build pagination into a class that provides raw data access, then
>> inherit that for specific types of data like animals. Efficient
>> pagination is too tightly coupled to the data source to be separate.
>
> According to the above, does this suggestion of yours still apply?
> If so, what is the buzzword that I should look at so that "inherit that for specific types of data like animals" could be possible? What/where should I look/search to accomplish your suggestion?

I would say your pagination logic belongs in myPDO.class.php. Where I
have this functionality it's as simple as two arguments to the method
that gets data, $page and $perpage. Setting both to false would
retrieve all rows.

-Stuart

--
http://stut.net/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Newbie: Composition by Association - Pagination Class general question.

=20
> I would say your pagination logic belongs in myPDO.class.php. Where I
> have this functionality it's as simple as two arguments to the method
> that gets data, $page and $perpage. Setting both to false would
> retrieve all rows.

Interesting but, still no clue, on this side, about how to accomplish =
that. I'm still a newbie.=20
Can you throw some key words so that I can google them and look for a =
way to implement that?

Thanks,
Márcio






--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Newbie: Composition by Association - Pagination Class

2009/7/19 MEM :
>
>> I would say your pagination logic belongs in myPDO.class.php. Where I
>> have this functionality it's as simple as two arguments to the method
>> that gets data, $page and $perpage. Setting both to false would
>> retrieve all rows.
>
> Interesting but, still no clue, on this side, about how to accomplish that. I'm still a newbie.
> Can you throw some key words so that I can google them and look for a way to implement that?

I don't know much about PDO, but in raw MySQL SQL you'd have something
similar to this...

function Select($table, $where, $page = false, $perpage = 20)
{
$sql = 'select * from '.$table.' where '.$where;
if ($page !== false)
{
$sql .= ' limit '.(($page-1)*$perpage).', '.$perpage;
}
// now run the query and return the results
...
}

Obviously this is highly simplified but should give you the general
idea. If you still don't get it I suggest you find something open
source that does pagination (any blogging system should work as an
example) and look at the source code.

-Stuart

--
http://stut.net/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Newbie: Composition by Association - Pagination Class general question.

Two things strike me as wrong with your thinking:

(1) The idea that you have a separate DAO for each entity instead of a
single generic DAO which can act for any entity in the system.
(2) The idea that pagination requires its own class, and therefore needs
this "is-a" and "has-a" nonsense.

As for (1) even in my pre-OO days I was used to using a single generic DAO
for all database access. The only time that more than one DAO existed was
for a different DBMS engine. This is why I have one DAO class for MySQL, one
for PostgreSQL and another for Oracle. If you are incapable of writing a
single generic DAO then it just shows that you still have a lot to learn.
For an idea on how this works take a look at
http://www.tonymarston.net/php-mysql/databaseobjects.html

As for (2) it should be obvious that pagination is not an entity in its own
right that has its own properties and methods, it is merely a function which
can be performed on any entity within the system. It should also be obvious
that the requirements of pagination cannot be satisfied in a single class as
some of the processing has to be handled in the presentation (UI) layer
while the remainder is handled in the data access layer. The presentation
layer needs a means to submit a request for a particular page number as well
as the page size (rows per page). These two values are sent to the DAO which
then translates them into values for LIMIT and OFFSET. After the DAO has
issued the sql SELECT statement it needs to return two values - the current
page number and the last available page number. The presentation layer then
needs a mechanism to display these two values. This is explained in
http://www.tonymarston.net/php-mysql/pagination.html

If you still don't see how this works then you can run my sample application
at http://www.tonymarston.net/php-mysql/sample-application.html You can even
download the code so that you can step through it with your debugger.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org


""MEM"" wrote in message
news:000701ca0867$992912e0$cb7b38a0$@com...
Hello,

I have a Animals DAO class that I'd like to apply a pagination class to it.

Between this two classes, there will be a composition relation (more
precisely, an association one). My question is:

Is a Pagination that "has a" Animal. OR Is a Animal that "has a" pagination?
Should we create on Class Pagination a property named $_animal OR, should we
create on class Animal a property named $_pagination?

I'm inclined to accept the second one, since, if I put the property $_animal
on my classe Pagination, I will end up, on the Pagination Class, with so
many properties as pagination objects... :s



Any help please?
Márcio



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Newbie: Composition by Association - Pagination Class general question.

> I don't know much about PDO, but in raw MySQL SQL you'd have something
> similar to this...
>=20
> function Select($table, $where, $page =3D false, $perpage =3D 20)
> {
> $sql =3D 'select * from '.$table.' where '.$where;
> if ($page !== false)
> {
> $sql .=3D ' limit '.(($page-1)*$perpage).', '.$perpage;
> }
> // now run the query and return the results
> ...
> }

I believe I understand the pagination logic.=20
If I'd like to put some general mysql function, I will put them on the =
abstract DAO class. However, I will not use a general CRUD because a DAO =
pattern works pretty well for now, and I still don't understand if there =
is any advantage by using a general CRUD and DAO together. But, apart =
from that, I do get the pagination logic I believe. What I don't get is =
how that logic could be related with the DAOs.

Anyway, I will try to code some lines to see what comes out...


Regards and thanks for your time Stuart,
Márcio




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Re: Newbie: Composition by Association - Pagination Class general question.

> As for (1) even in my pre-OO days I was used to using a single generic
> DAO
> for all database access. The only time that more than one DAO existed
> was
> for a different DBMS engine. This is why I have one DAO class for =
MySQL,
> one
> for PostgreSQL and another for Oracle. If you are incapable of writing
> a
> single generic DAO then it just shows that you still have a lot to
> learn.
> For an idea on how this works take a look at
> http://www.tonymarston.net/php-mysql/databaseobjects.html

I'm absolutly sure that I have a lot to learn. Really a lot. :-)
I have post some days ago, a way for using a generic CRUD class and DAO, =
but
I get no replys so I wrongly suppose that my question was a nonsense
question, and that CRUD and DAO would be a nonsense.


> As for (2) it should be obvious that pagination is not an entity in =
its
> own
> right that has its own properties and methods, it is merely a function
> which
> can be performed on any entity within the system.

Ok...

> It should also be
> obvious
> that the requirements of pagination cannot be satisfied in a single
> class as
> some of the processing has to be handled in the presentation (UI) =
layer
> while the remainder is handled in the data access layer.=20

That's why I was thinking on using a Decorator Object on the Pagination
Class (that will retrieve DAO values to operate).


> The
> presentation
> layer needs a means to submit a request for a particular page number =
as
> well
> as the page size (rows per page). These two values are sent to the DAO
> which
> then translates them into values for LIMIT and OFFSET. After the DAO
> has
> issued the sql SELECT statement it needs to return two values - the
> current
> page number and the last available page number. The presentation layer
> then
> needs a mechanism to display these two values. This is explained in
> http://www.tonymarston.net/php-mysql/pagination.html

Thanks for explain the workflow! I will read.

>=20
> If you still don't see how this works then you can run my sample
> application
> at http://www.tonymarston.net/php-mysql/sample-application.html You =
can
> even
> download the code so that you can step through it with your debugger.

I haven't learn how to use a debugger yet. And I'm sure it would help me =
a
lot on understanding some data workflow...


Thanks,
M=E1rcio=20


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Re: Newbie: Composition by Association - Pagination Class general question.

> > As for (1) even in my pre-OO days I was used to using a single
> generic
> > DAO
> > for all database access. The only time that more than one DAO =
existed
> > was
> > for a different DBMS engine. This is why I have one DAO class for
> MySQL,
> > one
> > for PostgreSQL and another for Oracle. If you are incapable of
> writing
> > a
> > single generic DAO then it just shows that you still have a lot to
> > learn.
> > For an idea on how this works take a look at
> > http://www.tonymarston.net/php-mysql/databaseobjects.html
>=20
> I'm absolutly sure that I have a lot to learn. Really a lot. :-)
> I have post some days ago, a way for using a generic CRUD class and =
DAO,
> but I get no replys so I wrongly suppose that my question was a
> nonsense question, and that CRUD and DAO would be a nonsense.
>=20

I'm trying to use PDO with prepare statements and BindParam, so I'm =
afraid
that my "newbility" doesn't allow me to pass directly from your example =
to
one that uses PDO.
Also, I also intend to use fetchObject method instead of fetchAssoc =
quite
often, with also puts your tutorial far away from my capacities. Because =
of
this, I'm trying to follow what I can get on the web, using PDO and =
general
CRUD operations:

BUT:

Here:=20
1) http://oopgarden.richardknop.com/index/view/1

or Here:
2) http://phpro.org/tutorials/Easy-Access-With-PDO-CRUD.html

when we have to create complex querys by using limits, order, etc... =
either
they are inexistent possibilities (like on the link 2), or, like on link =
1
they are so close to the equivalent sql sintax that I'm questioning the
advantage of having a general DAO CRUD class at all (supposing that the =
only
advantage is that we write less words on the code).

Please advice, besides the fact that we "never have to code any of the =
SQL
SELECT, INSERT, UPDATE or DELETE statements for any table as they will =
be
generated at runtime.", is there any other advantage on using a general =
DAO
class instead of one DAO class for each table?


:(

Regards,
M=E1rcio


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Newbie: Composition by Association - Pagination Class general question.

""MEM"" wrote in message
news:002001ca0898$5d183840$1748a8c0$@com...
> > As for (1) even in my pre-OO days I was used to using a single
> > generic DAO for all database access. The only time that more
> > than one DAO existed was for a different DBMS engine. This
> > is why I have one DAO class for MySQL, one for PostgreSQL
> > and another for Oracle. If you are incapable of writing a
> > single generic DAO then it just shows that you still have a lot to
> > learn. For an idea on how this works take a look at
> > http://www.tonymarston.net/php-mysql/databaseobjects.html
>
> I'm absolutly sure that I have a lot to learn. Really a lot. :-)
> I have post some days ago, a way for using a generic CRUD class and DAO,
> but I get no replys so I wrongly suppose that my question was a
> nonsense question, and that CRUD and DAO would be a nonsense.
>
> I'm trying to use PDO with prepare statements and BindParam, so I'm afraid
> that my "newbility" doesn't allow me to pass directly from your example to
> one that uses PDO.

Why not? Why can't you replace a call to a mysqli function with a call to a
PDO function?

> Also, I also intend to use fetchObject method instead of fetchAssoc quite
> often,

Why? What's the benefit? The fetchAssoc method gives you an array of
values, while the fetchObject method gives you a container for an array of
values. You still still have to work with an array of values.

> with also puts your tutorial far away from my capacities. Because of
> this, I'm trying to follow what I can get on the web, using PDO and
> general
> CRUD operations:

Why don't you learn how to use the mysqli functions before you handle the
switch to PDO? What do you have to lose?

> BUT:
>
> Here:
> 1) http://oopgarden.richardknop.com/index/view/1
>
> or Here:
> 2) http://phpro.org/tutorials/Easy-Access-With-PDO-CRUD.html
>
> when we have to create complex querys by using limits, order, etc...
> either
> they are inexistent possibilities (like on the link 2),

If you read my tutorial you should see that building a SELECT statement is
nothing more than combining several small strings into a larger single
string. String manipulation is simple in PHP. Using this technique I can
create very complex SQL statements, so don't tell me that it can't be done.

> or, like on link 1
> they are so close to the equivalent sql sintax that I'm questioning the
> advantage of having a general DAO CRUD class at all (supposing that the
> only
> advantage is that we write less words on the code).

Having less code to maintain is *precisely* the advantage of having a single
DAO. If you design it correctly then you can switch from one DAO class to
another in order to switch from one DBMS engine to aother.

> Please advice, besides the fact that we "never have to code any of the SQL
> SELECT, INSERT, UPDATE or DELETE statements for any table as they will be
> generated at runtime.", is there any other advantage on using a general
> DAO
> class instead of one DAO class for each table?

Because you have less code to maintain. If you look carefully you should see
that the only difference between the DAO for TableA and the DAO for TableB
is the table name and the table structure. If you could pass these as
arguments into a generic DAO then you would not need a separate DAO for each
table.

OOP is about creating reusable code to reduce the maintenance burden, so if
you insist that a separate DAO for each individual table is the way to go
then you don't understand how to apply the principles of OOP correctly.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Re: Newbie: Composition by Association - Pagination Class general question.

> Why not? Why can't you replace a call to a mysqli function with a call
> to a
> PDO function?

It's not just a simple replacement - I need to add bindparam, prepare,
execute, placeholders and fetchObject. But I will give it a try...
=20
> > Also, I also intend to use fetchObject method instead of fetchAssoc
> quite
> > often,
>=20
> Why? What's the benefit? The fetchAssoc method gives you an array of
> values, while the fetchObject method gives you a container for an =
array
> of
> values. You still still have to work with an array of values.

FetchObject maps the field names from the database as object properties =
with
the values stored in the database. Seems quite nice.

Then, to access a specific column data I just needed to:
$myhandler->my_database_column_name (it seems quite nice to me) :)=20

=20
> Why don't you learn how to use the mysqli functions before you handle
> the
> switch to PDO? What do you have to lose?

I already work with PDO so, no need to switch. :-)


> If you read my tutorial you should see that building a SELECT =
statement
> is
> nothing more than combining several small strings into a larger single
> string. String manipulation is simple in PHP. Using this technique I
> can
> create very complex SQL statements, so don't tell me that it can't be
> done.

I was not talking about your tutorial. I was talking about those two =
links,
mainly the first one where, unfortunately, the difference between the =
code
and the sql sintax is that we don't have the word SELECT and WHERE. :s
However, as a positive point, this class uses BindParam and ? =
placeholders.
But I get your point, we can cut it into smaller strings.


> Because you have less code to maintain. If you look carefully you
> should see
> that the only difference between the DAO for TableA and the DAO for
> TableB
> is the table name and the table structure. If you could pass these as
> arguments into a generic DAO then you would not need a separate DAO =
for
> each
> table.

Yes. But you still need, for each table, to fill one or several =
(depending
on what mysql connection method we use) arrays with values.
So that "less code" maybe isn't that much in a way where you =
*significantly*
reduce your maintenance burden, if you take into consideration that we =
take
the queries for each table, but a) we add arrays and b) use a less =
intuitive
way to add/remove/delete values to the database. As an example I have =
give
link 1, where the difference was more or less two or three words - and =
the
way to use the arrays where far more complicated to understand then a =
simple
Select Sintax - hence, not that relevant.

=20
> OOP is about creating reusable code to reduce the maintenance burden,
> so if
> you insist that a separate DAO for each individual table is the way to
> go
> then you don't understand how to apply the principles of OOP =
correctly.

I will never insist just because some silly reason comes to my mind. I =
will
however not follow a method without knowing the reasons and be convinced =
of
them.


I'm not 100% convinced of the reducing benefits for the reasons a) and =
b)
stated above, still, maybe I get more benefits the more I add methods to =
the
DAOs.


In the next few days I will try to, based on your code, create a general =
DAO
class that deals with PDO. And post back my frustrations back here. :D


Please have patience. :D


Regards,
M=E1rcio





--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Newbie: Composition by Association - Pagination

On Sun, Jul 19, 2009 at 03:56:43PM +0100, Tony Marston wrote:

> Two things strike me as wrong with your thinking:
>
> (1) The idea that you have a separate DAO for each entity instead of a
> single generic DAO which can act for any entity in the system.
> (2) The idea that pagination requires its own class, and therefore needs
> this "is-a" and "has-a" nonsense.
>
> As for (1) even in my pre-OO days I was used to using a single generic DAO
> for all database access. The only time that more than one DAO existed was
> for a different DBMS engine. This is why I have one DAO class for MySQL, one
> for PostgreSQL and another for Oracle. If you are incapable of writing a
> single generic DAO then it just shows that you still have a lot to learn.
> For an idea on how this works take a look at
> http://www.tonymarston.net/php-mysql/databaseobjects.html

This brings up a question. Most of the tutorials I've read on your site
deal with classes tailored to specific tables. However, in much of my
software, I have to deal with queries which access multiple tables. For
example, my invoice table contains the customer number, but not their
name. For that, I have to go to the customer table. Thus, my queries
often access multiple tables with where clauses which ensure I get the
proper data from secondary tables. I've never used "views" in SQL, but
it appears that this is what would be called a "view".

So in your constellation of software, would you create a subclass of
genericTable which essentially is a "view"? Otherwise, how would you
handle this?

Paul

--
Paul M. Foster

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Newbie: Composition by Association - PaginationClass general question.

"Paul M Foster" wrote in message
news:20090719220923.GV14822@quillandmouse.com...
> On Sun, Jul 19, 2009 at 03:56:43PM +0100, Tony Marston wrote:
>
>> Two things strike me as wrong with your thinking:
>>
>> (1) The idea that you have a separate DAO for each entity instead of a
>> single generic DAO which can act for any entity in the system.
>> (2) The idea that pagination requires its own class, and therefore needs
>> this "is-a" and "has-a" nonsense.
>>
>> As for (1) even in my pre-OO days I was used to using a single generic
>> DAO
>> for all database access. The only time that more than one DAO existed was
>> for a different DBMS engine. This is why I have one DAO class for MySQL,
>> one
>> for PostgreSQL and another for Oracle. If you are incapable of writing a
>> single generic DAO then it just shows that you still have a lot to learn.
>> For an idea on how this works take a look at
>> http://www.tonymarston.net/php-mysql/databaseobjects.html
>
> This brings up a question. Most of the tutorials I've read on your site
> deal with classes tailored to specific tables. However, in much of my
> software, I have to deal with queries which access multiple tables. For
> example, my invoice table contains the customer number, but not their
> name. For that, I have to go to the customer table. Thus, my queries
> often access multiple tables with where clauses which ensure I get the
> proper data from secondary tables. I've never used "views" in SQL, but
> it appears that this is what would be called a "view".
>
> So in your constellation of software, would you create a subclass of
> genericTable which essentially is a "view"? Otherwise, how would you
> handle this?
>
> Paul

Such things can be handled automatically by my generic DAO. Amongst the
details which are exported from my data dictionary into each table structure
file (which is accessed by the database table class) is a list of all the
parent/foreign tables, the foreign key field(s), and which fields to
retrieve from the parent table. So when the sql SELECT statement is being
constructed it can use this information to add a JOIN to the parent table in
order to retrieve the specified field(s). This is documented in
http://www.tonymarston.net/php-mysql/data-dictionary.html#sq l.joins

Any number of parent relations can be defined for a table, and any number of
fields can be retrieved from those tables and added to the SELECT list. All
the developer has to do is define the relationship in the data dictionary
and the framework will handle the boring stuff of generating the necessary
SQL.

So, using your example, I would define my customer table as a parent to my
invoice table, identify which foreign key field relates to which primary key
field in the parent table, define customer_name as the field to be retrieved
from the customer table, then sit back and watch the framework do its stuff.
Each time I read from the invoice table the result would automatically
include the customer name.

Easy peasy lemon squeezy. It's not rocket science, but it is neat.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Re: Newbie: Composition by Association - Pagination Class general question.

> > > As for (1) even in my pre-OO days I was used to using a single
> > > generic DAO for all database access. The only time that more
> > > than one DAO existed was for a different DBMS engine. This
> > > is why I have one DAO class for MySQL, one for PostgreSQL
> > > and another for Oracle. If you are incapable of writing a
> > > single generic DAO then it just shows that you still have a lot to
> > > learn. For an idea on how this works take a look at
> > > http://www.tonymarston.net/php-mysql/databaseobjects.html


Before I dig in on this DAO, I'm wondering, where should I, and how =
could I,
properly place a JOIN on this kind of pattern? Is it easy done or, on a =
JOIN
scenario (and I will have a lot of them) I choose probably choose =
another
pattern?


Regards,
M=E1rcio



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Newbie: Composition by Association - Pagination Class general question.

""MEM"" wrote in message
news:000201ca0a9f$ca3fb110$5ebf1330$@com...
> > > As for (1) even in my pre-OO days I was used to using a single
> > > generic DAO for all database access. The only time that more
> > > than one DAO existed was for a different DBMS engine. This
> > > is why I have one DAO class for MySQL, one for PostgreSQL
> > > and another for Oracle. If you are incapable of writing a
> > > single generic DAO then it just shows that you still have a lot to
> > > learn. For an idea on how this works take a look at
> > > http://www.tonymarston.net/php-mysql/databaseobjects.html


> Before I dig in on this DAO, I'm wondering, where should I, and how could
> I,
> properly place a JOIN on this kind of pattern? Is it easy done or, on a
> JOIN
> scenario (and I will have a lot of them) I choose probably choose another
> pattern?
>
> Regards,
> Márcio

Adding a JOIN to the SQL statement which is generated by the framework is
very easy, as shown in my FAQ at
http://www.tonymarston.net/php-mysql/infrastructure-faq.html #faq08. You have
two choices where you can place the code:
(1) In the component script.
(2) In the table class, as shown in
http://www.tonymarston.net/php-mysql/infrastructure-faq.html #faq84

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Re: Newbie: Composition by Association - Pagination Class general question.

Thanks a lot Tony. Unfortunately for me, I'm seeing myself in no =
conditions
for properly learning a framework. I want to learn PHP and a framework =
bring
so many concepts at once, that I found extremely complex and time =
consuming
do dig in, at once, right now. Since I have no more than a few months on
PHP, I really need to keep it, as simple as possible, even if not =
perfectly
structured, but, the understanding of all the steps involved should be
included.

Thanks a lot for your help, and sorry for, in some way, having wasting =
your
time on this.=20

Regards,
M=E1rcio=20
=20
> Adding a JOIN to the SQL statement which is generated by the framework
> is
> very easy, as shown in my FAQ at
> http://www.tonymarston.net/php-mysql/infrastructure-faq.html #faq08. =
You
> have
> two choices where you can place the code:
> (1) In the component script.
> (2) In the table class, as shown in
> http://www.tonymarston.net/php-mysql/infrastructure-faq.html #faq84
>=20
> --
> Tony Marston
> http://www.tonymarston.net
> http://www.radicore.org
>=20
>=20
>=20
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php