> -----Original Message-----
> From: Peter Lind [mailto:peter.e.l...@gmail.com]
> Sent: Sunday, December 12, 2010 5:27 AM
> To: Lester Caine
> Cc: php-general@lists.php.net
> Subject: Re: [PHP] ORM doctrine


> >
> > The reason for 'caching' needs to be understood before it is applied in
> order to avoid the black holes that random caching is causing nowadays
> already. How often do you hear "wipe the xxx browser cache"? And I know
> if I am changing theme elements in bitweaver or phpgedview then I HAVE
> to wipe the cache to ensure that smarty rebuilds the relevant pages.
> Which underlines my point: caching is not icing on the cake but should be
> thought of sooner in the process, contrary to Tommys point.
> Regards
> Peter
> --
> <hype>
> WWW: plphp.dk / plind.dk
> LinkedIn: plind
> BeWelcome/Couchsurfing: Fake51
> Twitter: kafe15
> </hype>

If the app is well designed, then you still could implement it later w/o major 
rewrite.  Example, suppose your new client currently doesn't see the need for 
auth/acl nor do they have the budget for it ATM.  However, being experienced, 
you foresee their needs based their business, model & industry, how would you 
design the app so as to include that foreseeable future?  Isn't that where 
knowledge and experience comes in?

Request > acl/auth > process request > cache/db > return results.  Isn't that 
how the core basic flow should be?  Thus, if you removed acl/auth & cache, the 
app would still work.  That's one of the things I've mentioned in Adam's thread 
of choosing framework or not, is the flexibility to pick and choose.  Another 
example, would you use an array or a class object to represent the value of a 
row in a particular DB table?  Some folks may make those decisions lightly.  
IMO, such important decisions would make all the difference in having "workable 
(learning, understanding, maintaining, etc.), reliable, and flexible (modular, 
3rd party add-ins, etc.) code while retaining good performance."


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

Reply via email to