2010年8月30日星期一

Re: [fw-db] Zend_Db_Table sequences and MySql problem


On Aug 30, 2010, at 6:39 AM, Tantius, Richard wrote:

The only problem, now I need to use ZendX_Db_Table instead of Zend_Db_Table in my whole application. My question is, is there maybe a more efficient way instead of introducing a whole new class level to my application, just to make Zend ignore sequences when working with MySql?

It is natural and intended usage of most object-oriented frameworks to extend classes when you need to add custom functionality.  Yes, you need to use your custom class by editing your concrete table class declarations.  It shouldn't take you more than a few minutes to make these edits.

Here's how I'd do it in vim:

:cd application/models
:n `grep -r -l --include=*.php extends.Zend_Db_Table_Abstract .`
/extends Zend
c$extends MyProject_AbstractTable
:n
n
.

Repeat the last three steps until you've reached the last of your table classes.

Here's how I'd write the custom Table class, simply overriding a protected function from the base class:

abstract class MyProject_AbstractTable extends Zend_Db_Table_Abstract
{
  protected function _setSequence($sequence)
  {
    if ($this->_db instanceof Zend_Db_Adapter_Pdo_Mysql || $this->_db instanceof Zend_Db_Adapter_Mysqli)
    {
      $sequence = (bool) $sequence;
    }
    $this->_sequence = $sequence;
    return $this;
  }
}

Regards,
Bill Karwin

[fw-db] Zend_Db_Table sequences and MySql problem

Hi,

I have a problem with Zend_Db_Table / Zend_Db_Table_Abstract and would like to ask for some advice.
In my current project I am trying to support both MySql and Oracle Databases.
I am using subtypes of Zend_Db_Table defining objects representing my database tables on the php side, a simple example:

[code]

class Model_MailWorklist extends Zend_Db_Table

{

protected $_schema = 'ONLINEMARKETING';

protected $_name = 'BACKGROUND_MAIL_WORKLIST';

protected $_primary = 'ID';

protected $_sequence = 'ONLINEMARKETING.COUNTER_BG_WORK';

}

[/code]

As one may have noticed I am using sequences with my Oracle database, so something like this just works fine:

[code]

...

$_mailWorkList = new Model_MailWorklist();

$_nextPrimaryKey = $_mailWorkList

->insert

(

array

(

'SUBSCRIBER_ID' => $_singleTransferRecipientId,

'NEWSLETTER_ID' => $_newsletterDispatchNewsletterId,

'DISPATCH_DATE' => $newsletterDispatchDateTime,

'DISPATCHED' => 0,

'DISPATCH_TYPE' => 'main'

)

);

...

[/code]

Now I am tying to use the same code with my MySql Database, which rather uses [i] auto_increment [/i], instead of sequences.
Sine I need to define [i] protected $_sequence [/i] for handling my Oracle database, I hoped that for the MySql case Zend_Db_Table will just ignore the specified sequence and the [i]insert()[/i] function returns the next inserted primary key. But as long as [i] protected $_sequence [/i] is set to some string value in my Model_MailWorklist-Class, Zend will try to use it and the [i]insert()[/i] function just returns [i]FALSE[/i]. The responsible Framework code:

[code]

abstract class Zend_Db_Table_Abstract

{

...

protected $_sequence = true;

public function insert(array $data)

{

...

if (is_string($this->_sequence) && !isset($data[$pkIdentity])) {

$data[$pkIdentity] = $this->_db->nextSequenceId($this->_sequence);

}

...

[/code]

:\ ... Now I dislike the solution of adding a check for the database type currently active to every init method of subtypes of Zend_Db_Table and set [i]$this->_sequence [/i] if running on Oracle.
My current "brute force solution" is extending Zend_Db_Table, lests say ZendX_Db_Table:

[code]

class ZendX_Db_Table extends Zend_Db_Table

{

public function __construct($config = array(), $definition = null)

{

parent::__construct($config, $definition);

$this->set_transparent_sequence();

}

private function set_transparent_sequence()

{

if( $this->_db instanceof Zend_Db_Adapter_Pdo_Mysql )

{

$this->_sequence = true;

}

}

}

[/code]

The only problem, now I need to use ZendX_Db_Table instead of Zend_Db_Table in my whole application. My question is, is there maybe a more efficient way instead of introducing a whole new class level to my application, just to make Zend ignore sequences when working with MySql?
Is this even a Zend-Bug or does this behaviour make sense and there is a reason supporting sequences in MySql?

Regards,

Richard Tantius
Software Engineer

Gotenstr. 7-9
53175 Bonn
Tel.: +49 (0)228 / 4 22 86 - 32
Fax.: +49 (0)228 / 4 22 86 - 66
E-Mail: r.tantius@binserv.de
Web: www.binserv.de
www.binforcepro.de

Geschäftsführer: Rüdiger Jakob
Registergericht: Siegburg HRB 6765
Hauptsitz der Gesellschaft.: Pfarrer-Wichert-Str. 35, 53639 Königswinter
Diese E-Mail einschließlich eventuell angehängter Dateien enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind und diese E-Mail irrtümlich erhalten haben, dürfen Sie weder den Inhalt dieser E-Mail nutzen noch dürfen Sie die eventuell angehängten Dateien öffnen und auch nichts kopieren oder weitergeben/verbreiten. Bitte verständigen Sie den Absender und löschen Sie diese E-Mail und eventuell angehängte Dateien umgehend. Vielen Dank!

[fw-db] Zend_Db_Table sequences and MySql problem

Hi,

 

I have a problem with Zend_Db_Table / Zend_Db_Table_Abstract and would like to ask for some advice.

In my current project I am trying to support both MySql and Oracle Databases.

I am using subtypes of Zend_Db_Table defining objects representing my database tables on the php side, a simple example:

 

 

 

[code]

 

class  Model_MailWorklist extends Zend_Db_Table

 

{

 

 

 

    protected $_schema   = 'ONLINEMARKETING';

 

    protected $_name     = 'BACKGROUND_MAIL_WORKLIST';

 

    protected $_primary  = 'ID';

 

    protected $_sequence = 'ONLINEMARKETING.COUNTER_BG_WORK';

 

}

 

[/code]

 

 

 

As one may have noticed I am using sequences with my Oracle database, so something like this just works fine:

 

 

 

[code]

 

 

 

...

 

 

 

$_mailWorkList = new Model_MailWorklist();

 

 

 

$_nextPrimaryKey = $_mailWorkList

 

     ->insert

 

       (

 

           array

 

           (

 

               'SUBSCRIBER_ID' => $_singleTransferRecipientId,

 

               'NEWSLETTER_ID' => $_newsletterDispatchNewsletterId,

 

               'DISPATCH_DATE' => $newsletterDispatchDateTime,

 

               'DISPATCHED'    => 0,

 

               'DISPATCH_TYPE' => 'main'

 

           )

 

       );

 

...

 

 

 

[/code]

 

 

 

Now I am tying to use the same code with my MySql Database, which rather uses [i] auto_increment [/i], instead of sequences.

Sine I need to define [i] protected $_sequence [/i] for handling my Oracle database, I hoped that for the MySql case Zend_Db_Table will just ignore the specified sequence and the [i]insert()[/i] function returns the next inserted primary key. But as long as [i] protected $_sequence [/i] is set to some string value in my Model_MailWorklist-Class, Zend will try to use it and the [i]insert()[/i] function just returns [i]FALSE[/i]. The responsible Framework code:

 

 

 

[code]

 

 

 

abstract class Zend_Db_Table_Abstract

 

{

 

...

 

  protected $_sequence = true;

 

 

 

  public function insert(array $data)

 

    {

 

    ...

 

 

 

        if (is_string($this->_sequence) && !isset($data[$pkIdentity])) {

 

            $data[$pkIdentity] = $this->_db->nextSequenceId($this->_sequence);

 

        }

 

  ...

 

[/code]

 

 

 

:\ ... Now I dislike the solution of adding a check for the database type currently active to every init method of subtypes of Zend_Db_Table and set [i]$this->_sequence [/i] if running on Oracle.

My current “brute force solution” is extending Zend_Db_Table, lests say ZendX_Db_Table:

 

 

 

[code]

 

 

 

class ZendX_Db_Table extends Zend_Db_Table

 

{

 

 

 

    public function __construct($config = array(), $definition = null)

 

    {

 

        parent::__construct($config, $definition);

 

 

 

        $this->set_transparent_sequence();

 

    }

 

 

 

    private function set_transparent_sequence()

 

    {

 

        if( $this->_db instanceof Zend_Db_Adapter_Pdo_Mysql )

 

        {

 

            $this->_sequence = true;

 

        }

 

    }

 

 

 

}

 

 

 

[/code]

 

 

The only problem, now I need to use ZendX_Db_Table instead of Zend_Db_Table in my whole application. My question is, is there maybe a more efficient way instead of introducing a whole new class level to my application, just to make Zend ignore sequences when working with MySql?

Is this even a Zend-Bug or does this behaviour make sense and there is a reason supporting sequences in MySql?

 

 

 

Regards,

 

Richard Tantius

Software Engineer

 

 

 

Gotenstr. 7-9

53175 Bonn

Tel.:        +49 (0)228 / 4 22 86 - 32

Fax.:       +49 (0)228 / 4 22 86 - 66

E-Mail:   r.tantius@binserv.de

Web:      www.binserv.de

              www.binforcepro.de

 

Geschäftsführer: Rüdiger Jakob

Registergericht: Siegburg HRB 6765

Hauptsitz der Gesellschaft.: Pfarrer-Wichert-Str. 35, 53639 Königswinter

Diese E-Mail einschließlich eventuell angehängter Dateien enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind und diese E-Mail irrtümlich erhalten haben, dürfen Sie weder den Inhalt dieser E-Mail nutzen noch dürfen Sie die eventuell angehängten Dateien öffnen und auch nichts kopieren oder weitergeben/verbreiten. Bitte verständigen Sie den Absender und löschen Sie diese E-Mail und eventuell angehängte Dateien umgehend. Vielen Dank!

[fw-db] Zend_Db_Table sequences and MySql problem

Hi,

I have a problem with Zend_Db_Table / Zend_Db_Table_Abstract and would like to ask for some advice.

In my current project I am trying to support both MySql and Oracle Databases.

I am using subtypes of Zend_Db_Table defining objects representing my database tables on the php side, a simple example:

 

[code]

class  Model_MailWorklist extends Zend_Db_Table

{

 

    protected $_schema   = 'ONLINEMARKETING';

    protected $_name     = 'BACKGROUND_MAIL_WORKLIST';

    protected $_primary  = 'ID';

    protected $_sequence = 'ONLINEMARKETING.COUNTER_BG_WORK';

 

}

[/code]

 

As one may have noticed I am using sequences with my Oracle database, so something like this just works fine:

 

[code]

 

 

$_mailWorkList = new Model_MailWorklist();

 

$_nextPrimaryKey = $_mailWorkList

     ->insert

       (

           array

           (

               'SUBSCRIBER_ID' => $_singleTransferRecipientId,

               'NEWSLETTER_ID' => $_newsletterDispatchNewsletterId,

               'DISPATCH_DATE' => $newsletterDispatchDateTime,

               'DISPATCHED'    => 0,

               'DISPATCH_TYPE' => 'main'

           )

       );

 

[/code]

 

Now I am tying to use the same code with my MySql Database, which rather uses [i] auto_increment [/i], instead of sequences.

Sine I need to define [i] protected $_sequence [/i] for handling my Oracle database, I hoped that for the MySql case Zend_Db_Table will just ignore the specified sequence and the [i]insert()[/i] function returns the next inserted primary key. But as long as [i] protected $_sequence [/i] is set to some string value in my Model_MailWorklist-Class, Zend will try to use it and the [i]insert()[/i] function just returns [i]FALSE[/i]. The responsible Framework code:

 

[code]

 

abstract class Zend_Db_Table_Abstract

{

  protected $_sequence = true;

 

  public function insert(array $data)

    {

    …

 

        if (is_string($this->_sequence) && !isset($data[$pkIdentity])) {

            $data[$pkIdentity] = $this->_db->nextSequenceId($this->_sequence);

        }

  …

[/code]

 

:\ … Now I dislike the solution of adding a check for the database type currently active to every init method of subtypes of Zend_Db_Table and set [i]$this->_sequence [/i] if running on Oracle.

My current “brute force solution” is extending Zend_Db_Table, lests say ZendX_Db_Table:

 

[code]

 

class ZendX_Db_Table extends Zend_Db_Table

{

 

    public function __construct($config = array(), $definition = null)

    {

        parent::__construct($config, $definition);

 

        $this->set_transparent_sequence();

    }

 

    private function set_transparent_sequence()

    {

        if( $this->_db instanceof Zend_Db_Adapter_Pdo_Mysql )

        {

            $this->_sequence = true;

        }

    }

 

}

 

[/code]

 

The only problem, now I need to use ZendX_Db_Table instead of Zend_Db_Table in my whole application. My question is, is there maybe a more efficient way instead of introducing a whole new class level to my application, just to make Zend ignore sequences when working with MySql?

Is this even a Zend-Bug or does this behaviour make sense and there is a reason supporting sequences in MySql?

 

Regards,

Richard Tantius
Software Engineer



Gotenstr. 7-9
53175 Bonn
Tel.:        +49 (0)228 / 4 22 86 - 32
Fax.:       +49 (0)228 / 4 22 86 - 66

E-Mail:   r.tantius@binserv.de
Web:      www.binserv.de
               www.binforcepro.de

Geschäftsführer: Rüdiger Jakob
Registergericht: Siegburg HRB 6765
Hauptsitz der Gesellschaft.: Pfarrer-Wichert-Str. 35, 53639 Königswinter
Diese E-Mail einschließlich eventuell angehängter Dateien enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind und diese E-Mail irrtümlich erhalten haben, dürfen Sie weder den Inhalt dieser E-Mail nutzen noch dürfen Sie die eventuell angehängten Dateien öffnen und auch nichts kopieren oder weitergeben/verbreiten. Bitte verständigen Sie den Absender und löschen Sie diese E-Mail und eventuell angehängte Dateien umgehend. Vielen Dank!

 

 

 

2010年8月26日星期四

Re: [fw-db] Difference between JOIN and findDependentRowset

On Aug 26, 2010, at 1:38 PM, milesap wrote:
> So if I need to get the address of a family member, do I use
> findDependentRowset or use the JOIN statement? Could someone briefly
> explain
> when I should use either of them, it would help so much!

Use findDependentRowset() if you have *already* fetched the Account
row and your code subsequently decides it needs to fetch the
FamilyMembers that reference that Account.

$account = $accountTable->find(1234);
//
// ... some time later ...
//
$familyMembers = $account->findDependentRowset();
foreach ($familyMember as $member)
{
// ... do something with each member ...
}

Use an SQL query with a JOIN if you need data for multiple Accounts,
or if you know you'll need the data for an Account and its associated
FamilyMembers at the same time.

$sql = "SELECT * FROM Accounts a JOIN FamilyMembers f ON a.ID =
f.Account_ID";
$stmt = $db->query($sql);
while ($row = $stmt->fetch())
{
// ... do something with joined data ...
}

Regards,
Bill Karwin

[fw-db] Difference between JOIN and findDependentRowset

Hello,

I'm just trying to wrap my head around when to use findDependentRowset and
the JOIN statement. My database looks like:

ACCOUNT
- ID
- ADDRESS
- EMAIL
- PHONE

FAMILYMEMBERS
- ID
- ACCOUNT_ID
- NAME
- AGE

So if I need to get the address of a family member, do I use
findDependentRowset or use the JOIN statement? Could someone briefly explain
when I should use either of them, it would help so much!

Regards,
Miles
--
View this message in context: http://zend-framework-community.634137.n4.nabble.com/Difference-between-JOIN-and-findDependentRowset-tp2340343p2340343.html
Sent from the Zend DB mailing list archive at Nabble.com.

2010年8月24日星期二

Re: [fw-mvc] Re: Centralized Stack/Broker or something for Models

Yea, it would have the methods markDirty($obj), markNew($obj), markClean($obj), and markDelete($obj). MarkClean is a misnomer since it merely removes the object from Dirty, Delete, and New. Also, the model objects delegate these methods back to the Identity Map/UoW object so for example you can have a model object, $obj, and say $obj->markDirty(). The Identity Map/UoW is singleton and I have each of the "mark" methods called statically so a model object would have the method:

public function markDirty(){
    UoW::markDirty( $this );
}//markDirty

David Kanenwisher

On Tue, Aug 24, 2010 at 11:47 AM, Hector Virgen <djvirgen@gmail.com> wrote:
Cool, so you probably also have a method in the UoW like markDirty($obj), right?


--
Hector Virgen
Sr. Web Developer
Walt Disney Parks and Resorts Online



On Tue, Aug 24, 2010 at 9:27 AM, David Kanenwisher <david.kanenwisher@bolderthinking.com> wrote:
I put the Unit of Work and the Identity Map in the same object. Then each model implements an interface that allows it look up it's mapper when the Unit of Work/Identity Map object asks it to interact with the data sources. The method in the Unit of Work/Identity Map object looks something like this:

public function performOperations(){
    foreach($this->objList as $obj){
        if( $this->isDirty( $obj ) ) {
            $obj->mapper()->update( $obj );
        }
        //check for new
        //check for delete
    }
}//performOperations

$this->dirty holds a list of all objects that have modified the data they took from their data source. $obj's mapper() function returns an object from a factory that handles all of the data source interactions.

David Kanenwisher

On Tue, Aug 24, 2010 at 10:40 AM, Hector Virgen <djvirgen@gmail.com> wrote:
I agree, an Identity Map is definitely the way to go and compliments caching. But I haven't had any luck implementing the Unit of Work pattern. Do you place the Unit of Work in its own class or does each model implement it? 

--
Hector Virgen
Sr. Web Developer
Walt Disney Parks and Resorts Online



On Tue, Aug 24, 2010 at 6:46 AM, David Kanenwisher <david.kanenwisher@bolderthinking.com> wrote:
We've managed to avoid dependency issues by creating an object that uses the Identity Map and Unit of Work patterns. The Identity Map keeps track of all the objects as we pull them from the database so we don't have to worry about duplicating objects. The Unit of Work functions as intermediary between the model and the functions used to retrieve and store data from our data sources. When we call the Unit of Work to do it's thing it goes through the list of objects in the Identity Map and performs any operations which need to be done on the objects. This allows us to create unit tests which test how our model functions and then separately test the methods they are taken from and stored to our data source. Of course, all of this is also completely separate from the controller ensuring we have a thin controller and a fat model.

David Kanenwisher


On Mon, Aug 23, 2010 at 8:59 AM, Hector Virgen <djvirgen@gmail.com> wrote:

It seems a lot of the solutions out there rely in static classes/methods/properties. How does this affect unit testing? And how do you encourage dependency injection with your fellow developers?

--
Hector Virgen
Sent from my Droid X

On Aug 23, 2010 6:52 AM, "Christoph" <christopher@emergencyinhaler.com> wrote:
>
> I set up my model class with a static factory method and a static registry.
> So when I want to grab a user object, I call User::factory($username). The
> factory method will check if this object exists in the registry. If it does,
> return it. If not, instantiate it and store it in the registry. This way
> each user only gets instantiated once. It also keeps the logic in the model
> class itself, and out of the bootstrap and controllers.
>
>
> Marko78 wrote:
>>
>> So I was thinking, am I wasting resources? Declaring the same class over
>> and over again in the same request. Should I have somekind of centralized
>> stack where to register my Models when needed and the next time the Model
>> is needed it could be get from this centralized stack?
>>
>
> --
> View this message in context: http://zend-framework-community.634137.n4.nabble.com/Centralized-Stack-Broker-or-something-for-Models-tp2333975p2335141.html
> Sent from the Zend MVC mailing list archive at Nabble.com.
>






Re: [fw-mvc] Re: Centralized Stack/Broker or something for Models

Cool, so you probably also have a method in the UoW like markDirty($obj), right?

--
Hector Virgen
Sr. Web Developer
Walt Disney Parks and Resorts Online



On Tue, Aug 24, 2010 at 9:27 AM, David Kanenwisher <david.kanenwisher@bolderthinking.com> wrote:
I put the Unit of Work and the Identity Map in the same object. Then each model implements an interface that allows it look up it's mapper when the Unit of Work/Identity Map object asks it to interact with the data sources. The method in the Unit of Work/Identity Map object looks something like this:

public function performOperations(){
    foreach($this->objList as $obj){
        if( $this->isDirty( $obj ) ) {
            $obj->mapper()->update( $obj );
        }
        //check for new
        //check for delete
    }
}//performOperations

$this->dirty holds a list of all objects that have modified the data they took from their data source. $obj's mapper() function returns an object from a factory that handles all of the data source interactions.

David Kanenwisher

On Tue, Aug 24, 2010 at 10:40 AM, Hector Virgen <djvirgen@gmail.com> wrote:
I agree, an Identity Map is definitely the way to go and compliments caching. But I haven't had any luck implementing the Unit of Work pattern. Do you place the Unit of Work in its own class or does each model implement it? 

--
Hector Virgen
Sr. Web Developer
Walt Disney Parks and Resorts Online



On Tue, Aug 24, 2010 at 6:46 AM, David Kanenwisher <david.kanenwisher@bolderthinking.com> wrote:
We've managed to avoid dependency issues by creating an object that uses the Identity Map and Unit of Work patterns. The Identity Map keeps track of all the objects as we pull them from the database so we don't have to worry about duplicating objects. The Unit of Work functions as intermediary between the model and the functions used to retrieve and store data from our data sources. When we call the Unit of Work to do it's thing it goes through the list of objects in the Identity Map and performs any operations which need to be done on the objects. This allows us to create unit tests which test how our model functions and then separately test the methods they are taken from and stored to our data source. Of course, all of this is also completely separate from the controller ensuring we have a thin controller and a fat model.

David Kanenwisher


On Mon, Aug 23, 2010 at 8:59 AM, Hector Virgen <djvirgen@gmail.com> wrote:

It seems a lot of the solutions out there rely in static classes/methods/properties. How does this affect unit testing? And how do you encourage dependency injection with your fellow developers?

--
Hector Virgen
Sent from my Droid X

On Aug 23, 2010 6:52 AM, "Christoph" <christopher@emergencyinhaler.com> wrote:
>
> I set up my model class with a static factory method and a static registry.
> So when I want to grab a user object, I call User::factory($username). The
> factory method will check if this object exists in the registry. If it does,
> return it. If not, instantiate it and store it in the registry. This way
> each user only gets instantiated once. It also keeps the logic in the model
> class itself, and out of the bootstrap and controllers.
>
>
> Marko78 wrote:
>>
>> So I was thinking, am I wasting resources? Declaring the same class over
>> and over again in the same request. Should I have somekind of centralized
>> stack where to register my Models when needed and the next time the Model
>> is needed it could be get from this centralized stack?
>>
>
> --
> View this message in context: http://zend-framework-community.634137.n4.nabble.com/Centralized-Stack-Broker-or-something-for-Models-tp2333975p2335141.html
> Sent from the Zend MVC mailing list archive at Nabble.com.
>





Re: [fw-mvc] Re: Centralized Stack/Broker or something for Models

I put the Unit of Work and the Identity Map in the same object. Then each model implements an interface that allows it look up it's mapper when the Unit of Work/Identity Map object asks it to interact with the data sources. The method in the Unit of Work/Identity Map object looks something like this:

public function performOperations(){
    foreach($this->objList as $obj){
        if( $this->isDirty( $obj ) ) {
            $obj->mapper()->update( $obj );
        }
        //check for new
        //check for delete
    }
}//performOperations

$this->dirty holds a list of all objects that have modified the data they took from their data source. $obj's mapper() function returns an object from a factory that handles all of the data source interactions.

David Kanenwisher

On Tue, Aug 24, 2010 at 10:40 AM, Hector Virgen <djvirgen@gmail.com> wrote:
I agree, an Identity Map is definitely the way to go and compliments caching. But I haven't had any luck implementing the Unit of Work pattern. Do you place the Unit of Work in its own class or does each model implement it? 

--
Hector Virgen
Sr. Web Developer
Walt Disney Parks and Resorts Online



On Tue, Aug 24, 2010 at 6:46 AM, David Kanenwisher <david.kanenwisher@bolderthinking.com> wrote:
We've managed to avoid dependency issues by creating an object that uses the Identity Map and Unit of Work patterns. The Identity Map keeps track of all the objects as we pull them from the database so we don't have to worry about duplicating objects. The Unit of Work functions as intermediary between the model and the functions used to retrieve and store data from our data sources. When we call the Unit of Work to do it's thing it goes through the list of objects in the Identity Map and performs any operations which need to be done on the objects. This allows us to create unit tests which test how our model functions and then separately test the methods they are taken from and stored to our data source. Of course, all of this is also completely separate from the controller ensuring we have a thin controller and a fat model.

David Kanenwisher


On Mon, Aug 23, 2010 at 8:59 AM, Hector Virgen <djvirgen@gmail.com> wrote:

It seems a lot of the solutions out there rely in static classes/methods/properties. How does this affect unit testing? And how do you encourage dependency injection with your fellow developers?

--
Hector Virgen
Sent from my Droid X

On Aug 23, 2010 6:52 AM, "Christoph" <christopher@emergencyinhaler.com> wrote:
>
> I set up my model class with a static factory method and a static registry.
> So when I want to grab a user object, I call User::factory($username). The
> factory method will check if this object exists in the registry. If it does,
> return it. If not, instantiate it and store it in the registry. This way
> each user only gets instantiated once. It also keeps the logic in the model
> class itself, and out of the bootstrap and controllers.
>
>
> Marko78 wrote:
>>
>> So I was thinking, am I wasting resources? Declaring the same class over
>> and over again in the same request. Should I have somekind of centralized
>> stack where to register my Models when needed and the next time the Model
>> is needed it could be get from this centralized stack?
>>
>
> --
> View this message in context: http://zend-framework-community.634137.n4.nabble.com/Centralized-Stack-Broker-or-something-for-Models-tp2333975p2335141.html
> Sent from the Zend MVC mailing list archive at Nabble.com.
>




Re: [fw-mvc] Re: Centralized Stack/Broker or something for Models

I agree, an Identity Map is definitely the way to go and compliments caching. But I haven't had any luck implementing the Unit of Work pattern. Do you place the Unit of Work in its own class or does each model implement it? 

--
Hector Virgen
Sr. Web Developer
Walt Disney Parks and Resorts Online



On Tue, Aug 24, 2010 at 6:46 AM, David Kanenwisher <david.kanenwisher@bolderthinking.com> wrote:
We've managed to avoid dependency issues by creating an object that uses the Identity Map and Unit of Work patterns. The Identity Map keeps track of all the objects as we pull them from the database so we don't have to worry about duplicating objects. The Unit of Work functions as intermediary between the model and the functions used to retrieve and store data from our data sources. When we call the Unit of Work to do it's thing it goes through the list of objects in the Identity Map and performs any operations which need to be done on the objects. This allows us to create unit tests which test how our model functions and then separately test the methods they are taken from and stored to our data source. Of course, all of this is also completely separate from the controller ensuring we have a thin controller and a fat model.

David Kanenwisher


On Mon, Aug 23, 2010 at 8:59 AM, Hector Virgen <djvirgen@gmail.com> wrote:

It seems a lot of the solutions out there rely in static classes/methods/properties. How does this affect unit testing? And how do you encourage dependency injection with your fellow developers?

--
Hector Virgen
Sent from my Droid X

On Aug 23, 2010 6:52 AM, "Christoph" <christopher@emergencyinhaler.com> wrote:
>
> I set up my model class with a static factory method and a static registry.
> So when I want to grab a user object, I call User::factory($username). The
> factory method will check if this object exists in the registry. If it does,
> return it. If not, instantiate it and store it in the registry. This way
> each user only gets instantiated once. It also keeps the logic in the model
> class itself, and out of the bootstrap and controllers.
>
>
> Marko78 wrote:
>>
>> So I was thinking, am I wasting resources? Declaring the same class over
>> and over again in the same request. Should I have somekind of centralized
>> stack where to register my Models when needed and the next time the Model
>> is needed it could be get from this centralized stack?
>>
>
> --
> View this message in context: http://zend-framework-community.634137.n4.nabble.com/Centralized-Stack-Broker-or-something-for-Models-tp2333975p2335141.html
> Sent from the Zend MVC mailing list archive at Nabble.com.
>



Re: [fw-mvc] Zend captcha image

Gary Hockin wrote:
> Might I suggest a set of x pre-generated images that are refreshed
> periodically, adding considerable overhead to a single request (or run
> on a cron job or equivalent), but overall reducing overhead considerably?
>
> Just a thought.
> G

can I suggest to extend as suggested in the docs ?
IMHO the funciotn _generateImage() is Too long and a method like
$this->_outputImage($img, $file = null) could be used (and overwritten)
to change the output type

class Your_Captcha_Image extends Zend_Captcha_Image
{
protected $_imageBinary;
/**
* Generate image captcha
*
* Override this function if you want different image generator
* Wave transform from http://www.captcha.ru/captchas/multiwave/
*
* @param string $id Captcha ID
* @param string $word Captcha word
*/
protected function _generateImage($id, $word)
{

// .... same code here except for the the output ... html
embedded instead of write a file

ob_start();
imagepng($img2);
$this->_imageBinary = ob_get_contents();
ob_end_clean();
imagedestroy($img);
imagedestroy($img2);
}

/**
* Display the captcha
*
* @param Zend_View_Interface $view
* @param mixed $element
* @return string
*/
public function render(Zend_View_Interface $view = null, $element =
null)
{
// return '<img width="'.$this->getWidth().'"
height="'.$this->getHeight().'" alt="'.$this->getImgAlt().'" src="' .
$this->getImgUrl() . $this->getId() . $this->getSuffix() . '"/><br/>';
return '<img src="data:image/png;base64,' .
base64_encode($this->_imageBinary) . '" /><br />';
}
}

--
________________________________________
Simone Cosci - NextIdea
Software engineering
Planet S.r.l. Sistemi informatici
Via Giorgio Ambrosoli, 39
50018, Scandicci, Firenze, Italy
WEB http://www.planetweb.it
E-Mail s.cosci@nextidea.it
Tel. +39 055 7350271 / 4630416
Fax. +39 055 7351109
Cell. +39 339 8672146
Voip. +39 055 5357896
________________________________________

Re: [fw-mvc] Re: Centralized Stack/Broker or something for Models

We've managed to avoid dependency issues by creating an object that uses the Identity Map and Unit of Work patterns. The Identity Map keeps track of all the objects as we pull them from the database so we don't have to worry about duplicating objects. The Unit of Work functions as intermediary between the model and the functions used to retrieve and store data from our data sources. When we call the Unit of Work to do it's thing it goes through the list of objects in the Identity Map and performs any operations which need to be done on the objects. This allows us to create unit tests which test how our model functions and then separately test the methods they are taken from and stored to our data source. Of course, all of this is also completely separate from the controller ensuring we have a thin controller and a fat model.

David Kanenwisher

On Mon, Aug 23, 2010 at 8:59 AM, Hector Virgen <djvirgen@gmail.com> wrote:

It seems a lot of the solutions out there rely in static classes/methods/properties. How does this affect unit testing? And how do you encourage dependency injection with your fellow developers?

--
Hector Virgen
Sent from my Droid X

On Aug 23, 2010 6:52 AM, "Christoph" <christopher@emergencyinhaler.com> wrote:
>
> I set up my model class with a static factory method and a static registry.
> So when I want to grab a user object, I call User::factory($username). The
> factory method will check if this object exists in the registry. If it does,
> return it. If not, instantiate it and store it in the registry. This way
> each user only gets instantiated once. It also keeps the logic in the model
> class itself, and out of the bootstrap and controllers.
>
>
> Marko78 wrote:
>>
>> So I was thinking, am I wasting resources? Declaring the same class over
>> and over again in the same request. Should I have somekind of centralized
>> stack where to register my Models when needed and the next time the Model
>> is needed it could be get from this centralized stack?
>>
>
> --
> View this message in context: http://zend-framework-community.634137.n4.nabble.com/Centralized-Stack-Broker-or-something-for-Models-tp2333975p2335141.html
> Sent from the Zend MVC mailing list archive at Nabble.com.
>


2010年8月23日星期一

Re: [fw-mvc] Re: Centralized Stack/Broker or something for Models

It seems a lot of the solutions out there rely in static classes/methods/properties. How does this affect unit testing? And how do you encourage dependency injection with your fellow developers?

--
Hector Virgen
Sent from my Droid X

On Aug 23, 2010 6:52 AM, "Christoph" <christopher@emergencyinhaler.com> wrote:
>
> I set up my model class with a static factory method and a static registry.
> So when I want to grab a user object, I call User::factory($username). The
> factory method will check if this object exists in the registry. If it does,
> return it. If not, instantiate it and store it in the registry. This way
> each user only gets instantiated once. It also keeps the logic in the model
> class itself, and out of the bootstrap and controllers.
>
>
> Marko78 wrote:
>>
>> So I was thinking, am I wasting resources? Declaring the same class over
>> and over again in the same request. Should I have somekind of centralized
>> stack where to register my Models when needed and the next time the Model
>> is needed it could be get from this centralized stack?
>>
>
> --
> View this message in context: http://zend-framework-community.634137.n4.nabble.com/Centralized-Stack-Broker-or-something-for-Models-tp2333975p2335141.html
> Sent from the Zend MVC mailing list archive at Nabble.com.
>

[fw-mvc] Re: Centralized Stack/Broker or something for Models

I set up my model class with a static factory method and a static registry.
So when I want to grab a user object, I call User::factory($username). The
factory method will check if this object exists in the registry. If it does,
return it. If not, instantiate it and store it in the registry. This way
each user only gets instantiated once. It also keeps the logic in the model
class itself, and out of the bootstrap and controllers.


Marko78 wrote:
>
> So I was thinking, am I wasting resources? Declaring the same class over
> and over again in the same request. Should I have somekind of centralized
> stack where to register my Models when needed and the next time the Model
> is needed it could be get from this centralized stack?
>

--
View this message in context: http://zend-framework-community.634137.n4.nabble.com/Centralized-Stack-Broker-or-something-for-Models-tp2333975p2335141.html
Sent from the Zend MVC mailing list archive at Nabble.com.

Re: [fw-mvc] Centralized Stack/Broker or something for Models

On Monday 23 Aug 2010 05:00:13 Michael Depetrillo wrote:
> I would think there is better performance by storing the data as a
> class property. Otherwise, you open/close the same cache file every
> time you access the cache from the front controller, controller,
> model, etc...

Most of the time you lookup the authenticated user. The user model acts with
Zend_Auth so in controllers only the api of the model is exposed:

- Application_Model_User::getAuthenticated()
- Application_Model_User::authenticate($username, $password)
- Application_Model_User::isAuthenticated()

And getAuthenticated() is obviously called my times during a request. The call
to the db is once made and then stored as static property. Look for a snippet
of my code at http://pastebin.com/iK1mfDmq.

Regards, Jurian
--
Jurian Sluiman
CTO Soflomo V.O.F.
http://soflomo.com

2010年8月22日星期日

Re: [fw-mvc] Centralized Stack/Broker or something for Models

I would think there is better performance by storing the data as a
class property. Otherwise, you open/close the same cache file every
time you access the cache from the front controller, controller,
model, etc...

On Sunday, August 22, 2010, Andreas Möller <localheinz@l8m.de> wrote:
>
>> I'm starting to run into this problem
>> quite frequently.
>>
>> 1. Fetch `user` row in a front controller
>> plugin.
>  > 2. Fetch the same `user` row in the
>> controller.
>>  3. Fetch the same `user` row during a Model call.
>
> Cache it.
>
>
> Best regards,
>
> Andreas
>
>

--
Michael DePetrillo
theman@michaeldepetrillo.com
Mobile: (858) 761-1605
www.michaeldepetrillo.com

Re: [fw-mvc] Centralized Stack/Broker or something for Models

> I'm starting to run into this problem
> quite frequently.
>
> 1. Fetch `user` row in a front controller
> plugin.
> 2. Fetch the same `user` row in the
> controller.
> 3. Fetch the same `user` row during a Model call.

Cache it.


Best regards,

Andreas

Re: [fw-mvc] Centralized Stack/Broker or something for Models

I'm starting to run into this problem quite frequently.  
  1. Fetch `user` row in a front controller plugin.
  2. Fetch the same `user` row in the controller.
  3. Fetch the same `user` row during a Model call. 
I have a couple different hacks to this problem.
  1. Store Zend_Db_Row in registry when you need to use it later.  
  2. Store Zend_Db_Row as a static property in the Zend_Db_Table class. 
  3. Write Row to cache.
I've created fetchRowRegistry() and fetchRowStatic() which use fetchRow() and fetchAll(). 

This works OK but it's difficult for other developers to remember and use these special methods.  I would also prefer a simpler approach.  

Michael DePetrillo
theman@michaeldepetrillo.com
Mobile: (858) 761-1605
www.michaeldepetrillo.com


On Sat, Aug 21, 2010 at 9:24 PM, Marko78 <marko.korhonen@gmail.com> wrote:
models here and there all over again during the request.
$contentModel = new Content_Model_Content; is been called in many places
during some request on my application. Only "design pattern" I use for
models is "fat models, thin controllers", so I try to write all operations
to my model instead of writing them to my controllers.

So I was thinking, am I wasting resources? Declaring the same class over and
over again in the same request. Should I have somekind of centralized stack
where to register my Models when needed and the next time the Model is
needed it could be get from this centralized stack?

RE: [fw-mvc] Re: Centralized Stack/Broker or something for Models

> At once I had my models as singletons.

Well, how much sense does that make?

> But then the wise men said that
singleton is evil. =)

It's not - it depends on whether you want to apply a design pattern for the mere application or whether you actually want to accomplish something - like, solve a problem. For example, your log and your mvc instance are singletons. Can't be that evil, then. Doesn't make much sense, though, to have singleton models, because in most cases you don't want something to happen just once, so should be able to juggle around with as many instances of a model class as you like, or some implemented logic allows for, but not just one.

> So I try not to use singletons though
> my current goal is basicly working
> similar as singeletons.

But what for? And why?

> But now I can any time make a new
> instance of my model if needed...

And what's up with that?

> Butbasicly I'm using
> my stack of models (array) in my
> application bootstrap.

And what for?


Best regards,

Andreas

RE: [fw-mvc] Re: Centralized Stack/Broker or something for Models

> And my models are NOT DbTable objects.
> So Model > DbTable -> Row and so
on...
> or some other datasource e.g. Model
> ACL or Model > Twitter account or
> Model > XML-file...

I'm just curious what you need a centralized broker for when your aim is to handle scarce resources wisely, and would like to know what the broker should do, then.


Best regards,

Andreas

Re: [fw-mvc] Re: Centralized Stack/Broker or something for Models

You should try implementing a service layer.

What I do in my ZF web apps, is have at least one application service
for each module. If you want to use a model, or really interact with
the domain layer, then you must go through this application service.
This service serves as the API for your module. Also, it is a great
place for caching, logging, etc.

On 8/22/2010 7:28 AM, Marko78 wrote:
> Hi Dolf,
>
> At once I had my models as singletons. But then the wise men said that
> singleton is evil. =)
> So I try not to use singletons though my current goal is basicly working
> similar as singeletons.
>
> But now I can any time make a new instance of my model if needed... But
> basicly I'm using
> my stack of models (array) in my application bootstrap.
>
> br, Marko
>
>
> -----
> br,
> --------------------------
> Marko Korhonen
> Technical Consultant