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
