arborint wrote:Hockey wrote:1) HTML does not belong inside a class...thats the worst example of OOP...
If I want to use your class, who says I want the header your class outputs? HTML is better left for template engines...
I don't see the problem with classes that generate HTML or XML or whatever. I regularly use a form field generator class for example.
Hockey wrote:I know the performance hit for using OOP is dismal, but I need more reason that encapsulation/data hiding...
I wouldn't say "dismal" -- some constructs are a little slower.
Hockey wrote:If you have CPerson class which maps to your very own database structure, it's very likely both the schema and your object properties, methods, etc will change in your next project...if you add an age field to your schema, you need to update your class...which is NOT reusable in the pure OOP sense of the word.
Again, I don't see the problem with coding application specific model objects. I will sacrafice reusablity for clean design.
1) It's not reusable like a class should be. I use a Smarty style template engine and like all my forms done by a designer who makes them look awesome.
Ideally (Although current frameworks, template engines, etc don't offer 100% satisfaction) you should always strive for HTML/CONTENT seperation as well as PHP/HTML seperation. Not sure what Forms generator you use, but the one in PEAR I'm pretty sure generates the HTML for you:
Code: Select all
$frm->addFieldText('First Name');
$frm->addFieldType(TEXT_BOX, 'fname', 'Default text');
Or something to the above affect anyways right?
Which would output something like:
Code: Select all
<table>
<tr>
<td>First Name</td>
<td><input type="text" name="fname" value="Default Text" /></td>
</tr>
</table>
Which I suppose could be injected into a Smarty template as in:
Code: Select all
<?
$frm->addFieldText('First Name');
$frm->addFieldType(TEXT_BOX, 'fname', 'Default text');
$tmp_buff = $frm->getFormHtml(); // Or something like this
// Assign form generator output to smarty template
$smarty->assign('form_area', $tmp_buff);
?>
Problem is, what if I want more control over the output of my FORM html? Even if FORM generators had an API for manipulating every last visiual aspect of a FORM output, the amount of code it would require in PHP would be more than what it's worth - it would be easier to use plain HTML.
Besides HTML does what it does and PHP does what it does...hence the introduction of template engines.
2) I didn't mean dismal in the sense that there is no performance hit, but just wrapping a couple functions into a classes namespace doesn't cause "much" of a performance hit...when you start deriving classes, etc and using composition like mad which are also objects, then classes become a potetial performance problem. But I dought that just simple wrappers - which I imagine MOST database classes are incur much of a performance hit.
3) Nothing wrong with it, just not really needed, especially in a performance-centric or should I say performance-concerned environment like a shared host or web server of any kind. I disagree with procedural programming making for a "less clean design". Thats not the purpose of OOP IMHO anyways. OOP helps prevent namespace collisions, so in that sense it's cleaner I guess - if thats what you meant. But it's just as easy to prefix a codename or namespace to a global function and likely avoid namespace collisions as well.
As for multiple globals variables messing up a design...ok I can agree with that, but how many globals are there when dealing with a database?
Code: Select all
class CPerson{
function insert(){}
function update(){}
function remove(){}
function removeExpired(){}
function isMale(){}
}
Depending on how you implement your classes I guess...if you pull all your data from a record and store it in a object then serialize that changed data back to the database...yes there could potentially multiple variables...
Personally I'd rather have each function execute SQL directly:
Code: Select all
function getAge(){ return mysql_query('SELECT age FROM persons WHERE pkid = 2'); }
Not syntactically correct, but you get my drift
This way you can optimize SQL queries individually as required, as opposed to having a generic
Load() or Save() method serialize your entire object. If you did use this approach however, I suppose classes would make more sense in the cleaner design sense, yes I agree
Cheers
