Stephan Ebelt wrote:
> On Mon, Oct 05, 2009 at 05:48:32PM -0700, Jim Lucas wrote:
>> Here is a problem that I have had for years now.  I have been trying to come 
>> up
>> with the perfect solution for this problem.  But, I have come down to two
>> different methods for solving it.
>>
>> Here is the problem...
> 
> [...]
> 
>> Now, we all have a function or method like this floating around somewhere.
>>
>> My question is, how do YOU go about setting the required entries of the 
>> $headers
>> array() ?
>>
> 
> [...]
> 
>> END of examples...
>>
>> Now, IMO, the last one is the simplest one and for me, I think it will be the
>> new way that I solve this type of problem.
>>
>> But, my question that I put out to all of you is...
>>
>>      How would you solve this problem?
> 
> I have use this array_merge() approach mentioned in other posts for
> quite some time but found that it introduced many bugs when fieldnames 
> changed.
> Ie. if the defaults come from a database table and I changed the schema it
> caused undefined values during the merging and - worse - sometimes messed up 
> the
> inner workings of functions...
> 
> Then I heard of the "value object" approach somewhere and found that much more
> solid. One would basically define a class where default values are represented
> by its properties. Ie:
> 
> class vo_email extends vo {
>       public $to = '';
>       public $from = '';
>       public $subject = '(no subject)';
>       public $body = '';
>       ...
> }
> 
> the constructor can make sure that absolutly necessary values are required and
> set properly - and could complain if something is not right. There could be
> methods that add() or set() or change() things. These could also be inherited
> from a very generic class "vo" so that this stuff is written once and applies
> to all sorts of defaults in the program.
> In my app the inherited constructor accepts arrays as parameter and assigns
> their elements to the object properties and - by that - overwrites the default
> settings. If elements do not match with the defined properties it will trigger
> a very visible call trace.
> 
> A function like sendEmail() would then require a object of type vo_email as
> parameter and would work with its properties internally and can rely on it as
> the vo's constructor should have catched anything bad.
> 
> If additional logic for the input values is required, it can be added easily:
> 
> class dao_email extends vo_email {
>       ...
>       public function encode_body() {
>               ...
>       }
> 
>       public function sanitize_mail_address() {
> 
>       }
>       ...
> }
> 

This is a very interesting approach.  How would you initialize the class?  Using
a Singleton Method, or a Globally available class variable?


> sendEmail() would then require a dao_email object (dao=data access object) as
> input.
> 
> stephan
> 
>> TIA
>>
>> Jim Lucas
>>
>> -- 
>> 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

Reply via email to