Welcome Guest, Not a member yet? Register   Sign In
Resuable models
#1

[eluser]Treeda[/eluser]
Hi all,

i've stumbled over a little problem and just eager to know how you would solve this issue.

i have a modelclass, lets call it BookComments. This model handles with a table which stores comments for books. Also this class is dervied from MyBaseModel.

then i found out that i need exactly the same for magazins. (please ignore that i could use the same table).

so i just found out that the CommentsBook and CommentsMagazin is exactly the same due to the same tablescheme and so. The only difference are 2 lines in the headers.
2 small constants defining the field_id of the parent record and the table itself.

you know a comment has to be assigned to an item id so lets say commentsBook has this easy fields (id, book_id, comment) and magazin would have (id, mag_id, comment).

I don't want to have an copy of this thing, so what about having only one model called Comments and giving the table name to the constructor? ops ok this is not possible in codeigniter...

So how would you solve that? i really want to reuse the code and keep it as a model?

also a possible way would be creating a CommentsBook and CommentsMagazin deriving from Comments, but then i stumbled into problems about including the files, it seems that i can't easily nest includes with codeigniter.

Many Thanks for your help and insights.
Andi
#2

[eluser]jedd[/eluser]
[quote author="Treeda" date="1249407944"]
(please ignore that i could use the same table).
[/quote]

Actually .. I don't think I will. Wink

At the moment you're asking for help to resolve a problem of your own creation, and you made the mistake of revealing that you not only know you're making a mistake, but you know how to fix it.

So .. go and fix your schema.

Having two mostly-the-same models, and two mostly-the-same tables containing book/magazine information, and two mostly-the-same tables containing book-comments/magazine-comments - is just plain silly.

And if you reckon the problems will be all over once you work out how to re-use a model .. well, allow me to disabuse you of this notion. A bad design sticks around like forever.
#3

[eluser]Treeda[/eluser]
[quote author="jedd" date="1249410227"][quote author="Treeda" date="1249407944"]
(please ignore that i could use the same table).
[/quote]

Actually .. I don't think I will. Wink

At the moment you're asking for help to resolve a problem of your own creation, and you made the mistake of revealing that you not only know you're making a mistake, but you know how to fix it.

So .. go and fix your schema.

Having two mostly-the-same models, and two mostly-the-same tables containing book/magazine information, and two mostly-the-same tables containing book-comments/magazine-comments - is just plain silly.

And if you reckon the problems will be all over once you work out how to re-use a model .. well, allow me to disabuse you of this notion. A bad design sticks around like forever.[/quote]

Unfortunatly you didn't got the problem. the question is plain simple and clear. How to reuse a model.

i don't want to have all the stuff in ONE table due to performance and size issues, it is absolut intended to have 2 tables to store that stuff. So don't take it rude but your answer sounds a bit arrogant and shows me you don't even see the neccessarity to keep models flexible to maybe share them between projects?
#4

[eluser]Maglok[/eluser]
Can't you just give the type of comment to the function?

Code:
post_comment($typeofcomment) {
// Stuff that uses $typeofcomment in the query
// Something
}
#5

[eluser]Treeda[/eluser]
this would be a possible solution. hm...

intentionally i liked to keep the model fitting a simple defined table so it is reusable, except simply giving the table and a foreign key name, so i don't need to touch functions or give them something.

a simple constructor would make it so easy, why models can't take arguments like libs?
#6

[eluser]jedd[/eluser]
Quote:Unfortunatly you didn't got the problem.

Oh, rest assured I got the problem okay.

You ring a doctor and say 'I keep slamming my fingers in my drawer' -- rather than take your fingers out of the drawer, you suggest the best solution is a prescription for painkillers.

Quote:the question is plain simple and clear. How to reuse a model.

It's not simple - for the genuinely simple reason that no one else around here is going to think like this, and consequently your question makes as much sense as a nonsensical thing.

If you insist on going down the path of silliness, then here's how you might do it. I say might, as there's no 'best practice' for dumb.

Extend Model using MY_Model.

Within MY_Model have a method that takes the relevant details for your book or magazine, and also a parameter for whether it's a book or a magazine. Then in your actual book and magazine models, which extend MY_Model, you call $this->functionwhatever(...)


One final note:
Quote:i don't want to have all the stuff in ONE table due to performance and size issues

Having your data duplicated / split across multiple tables will make the size larger.

Your performance will decrease as you continue to write bad code to wrap around your bad design.


And I'm flattered that you thought I sounded merely a bit arrogant. I've tried harder in this message. Wink
#7

[eluser]Treeda[/eluser]
jedd, even you just did it again :-)

about the size and usage of a mysql its another discussion and i don't want to do it here, so can you please take the requeirements of the request as i did it and look over a bad example? becuase it was nothing more than an example i used to wrap around my original request, sorry that you and your way of thinking tapped into it.

about Your suggestion, that might be a solution, was thinking about it earlier to but i don't like the idea because it is somehow globally. i think the main problem here comes from that a model is mostly used as some kind of singelton, but what i would like to use is my own instance of it.

btw i used the search function before i wrote this post and there are a fe other posts around the net people truggeling with models. again, i'm just looking for suggestions for solutions... not for a teacher boy :-)

anyways thanks for you effort. maybe your issue might be correct in some or even the most circumstances.
#8

[eluser]elvix[/eluser]
Sorry Treeda, but I think jedd's right. If you fix your table schema, you won't have any problems, you can simplify your model and even reuse it in multiple content types and projects, which is, i think, your issue.

If you simply replace mag_id in your comments table with parent_id and parent_type, you should be able to use your comments model pretty much anywhere.

What I think jedd is trying to say is that you're never going to be able build a generic model if you're not applying it to a generic DB schema.
#9

[eluser]Chad Fulton[/eluser]
I think that Treeda has an interesting question here, and it is Jedd etc. who are attempting to fit a square peg in a round hole.

In my view, the idea that there ought to be a "generic" database table to hold both sorts of comments is a bad practice, since there is no semantic reason why comments regarding magazines and comments regarding books ought to be the same, or stored in the same table.

For one thing, it needlessly complicates growth down the road. What if there are comment fields specific to books that don't apply to magazines, or vice versa?

For me, the clear answer in this situation would be creating a Comment model, and extending it with BookComment and MagazineComment (as the original comment suggested). The whole point of extensions is just for this sort of problem: how to deal with two things that share common basic elements but differ in their specific implementations.

The idea, I assume, is that there are both common functionality as well as specific functionality. Although if they truly are exactly the same, and there is no chance they will deviate, then I agree that it might just be easier to combine them into a single one.

Here's some example code (I dunno what your actual plan is, but this should shed some light, I hope):

models/Comment.php
Code:
<?php  if ( ! defined('BASEPATH')) exit('No direct script access allowed');

class Comment extends Model {

    public $id;
    public $comment;

    public function get($id, $table) {
        $this->db->where('id', $id)
                 ->limit(1)
                 ->get($table);
        foreach($this->db->row_array() as $key=>$value) {
            $this->$key = $value;
        }
    }

    // Common functionality here

}

models/BookComment.php
Code:
<?php  if ( ! defined('BASEPATH')) exit('No direct script access allowed');

require_once('Comment.php');

class BookComment extends Comment {
    public $book_id;

    public function get($id) {
         parent::get($id, 'bookComment');
    }

    // BookComment specific functionality here
}

models/MagazineComment.php
Code:
<?php  if ( ! defined('BASEPATH')) exit('No direct script access allowed');

require_once('Comment.php');

class MagazineComment extends Comment {
    public $mag_id;

    public function get($id) {
         parent::get($id, 'magazineComment');
    }

    // Magazine Comment functionality here
}
#10

[eluser]jedd[/eluser]
Reading back, I was perhaps a tad (but just a tad, mind) harsh. In my defence, I was frustrated by the OP's intimation that they knew they were doing something silly (as per the comment of theirs that I quoted). I would have been far more diplomatic had it not been obvious they were wantonly being obtuse.

Chad - thanks for your comments.

[quote author="Chad Fulton" date="1249427116"]
In my view, the idea that there ought to be a "generic" database table to hold both sorts of comments is a bad practice, since there is no semantic reason why comments regarding magazines and comments regarding books ought to be the same, or stored in the same table.[/quote]

I'm not sure what semantic reason means in this context. But more tellingly, can you describe the difference between '... both sorts of comments' as you see it? From my reading of the original post - and I think the words 'exactly the same' cropped up there - there's no algorithmic way of differentiating between the two comment types. Or, if you prefer, they are semantically aligned.

If that's the case, we have a square peg / square hole arrangement.

If, OTOH, there is a discernible difference between magazine comments and book comments, then bring on the extra table.


Quote:For one thing, it needlessly complicates growth down the road. What if there are comment fields specific to books that don't apply to magazines, or vice versa?

I'm confused by this. In my (imagined) schema, there would be one table for the publication (id , type char(1), title char(x)) and one that described comments (id, publication_id, comment char(x)) - so multiple comments can be tied to a single book or magazine, and there is no problem about comments that might be specific to a book.

Quote:For me, the clear answer in this situation would be creating a Comment model, and extending it with BookComment and MagazineComment (as the original comment suggested). The whole point of extensions is just for this sort of problem: how to deal with two things that share common basic elements but differ in their specific implementations.

Yes, I wholeheartedly concur - this is the idea behind OO, though perhaps not OO in the sense that PHP, or more importantly in this case, CI implements it.

In this particular instance there appears to be no discernible difference between the attributes of a book and the attributes of a magazine. Arbitrarily pretending there are differences - especially given the only reasons given so far were for 'performance and size' considerations - is, at best, an inelegant approach. To me it would be like having a separate table again for any books written by a philosopher with an S in their name.


Quote:Although if they truly are exactly the same, and there is no chance they will deviate, then I agree that it might just be easier to combine them into a single one.

If only you'd mentioned that earlier ... Wink




Theme © iAndrew 2016 - Forum software by © MyBB