> > This is not to trivialize your Metastorage project (or, to be more > > accurate, I know nothing about it, so it's not my place to trivialize > > it or otherwise), but to point out that 'out-of-the-box' solutions to > > fundamental coding development problems probably ultimately makes for > > a poorer programmer. I could well be wrong, but it seems this is a > > case of "give a man a fish" as opposed to "teach a man to fish". > > I see your point, but I'm not so sure I agree fully. Manuel suggested > Metastorage (which makes sense, it's his project and he's most > familiar/comfortable with it), I suggested Propel because that is what > I've > used. I think we both suggested existing ORM's for the same reason... > namely that properly implementing a full featured ORM is an extremely > difficult thing to get right. I don't know anything about Chris's skill > as > a programmer, but he's bound to reinvent the wheel several times over, and > poorly to boot. I believe that implementing an ORM is one of those things > that you cannot fully understand and appreciate until you've tried to do > it > and failed. IMHO it's only after you've built one that you realize what > you > really need, and by then it needs to be rebuilt. It's kind of like Fred > Brook's "plan to throw one away; you will, anyhow", or at least it was for > me. Hi Michael, You've hit on a point that I implied in my original post, but should have been more explicit about. If I can add some emphasis: * IMHO it's only after you've built one that you realize what you really need * I couldn't agree more. As I read and understand the original poster's question, he is still in the 'building one' phase of his development as an OO PHP coder. If this wasn't the case, I doubt he'd be asking the question he asked. My post was not aimed at saying 'using packaged approaches to solve coding problems is bad', but to say 'the original poster is asking a fundamental learning question, so a packaged approach will possibly, maybe even probably, hamper his development as a programmer at this point.' Put another way, working out how to implement a class to handle the question he asked would not be incredibly challenging, particularly with the help and advice of people on this list, and would add to his understanding of how OO works generically and in PHP. Both very good things. I use several package solutions in my own projects. Notably, MDB2 and HTML_QuickForm. I use MDB2 because it means my projects can be more flexible to any decisions made to change the backend storage technology. I use HTML_QuickForm because it provides convenient methods to building forms, and it minimizes the mixture of HTML and PHP code in my pages, something I personally prefer. Having said which, before adopting either of these packages I was satisfied that I understood how to achieve the same results using nothing more than my own coding skills. In other words, as a programmer I am comfortable working directly with a variety of data storage backends, employing classes to abstract different collections of data objects. I am comfortable building, validating, and processing forms. The packages I use are for convenience, rather than placing me at arm's length to understanding the programming concepts and needs they address. Also, I don't disagree that there are some brilliant packages out there, written by people who've taken time to learn more about a specific problem or set of problems than the average programmer would have to spend, particularly across the broad range of coding demands an application may touch upon. Again I reiterate: using packages to address application needs is not a bad thing, while avoiding learning the basics of programming by using such packages almost certainly is, particularly if you're taking your development as a programmer seriously, and consider yourself to be aiming at becoming a 'professional' programmer. [here there be snippage] > My point is, I had implemented my own home grown ORM about 3-4 times, and > while each one was much better than the one that preceded it, I still > wasn't > quite all the way towards a 100% general implementation. That's when I > found Propel. It got so many things right that I hadn't figured out how > to > solve, as well as implementing things that I hadn't even considered yet. > > Now, you could argue that going through all those iterations and > refactoring > my own ORM helped me to improve my skills as a programmer, and you would > be > right. That's where I agree with you, somewhat. :) However, I was many > many iterations away from improving my ORM to the point where it would be > as > useful as Propel (and that's assuming it would ever be that useful). The > guys who developed it (and I'm sure the same goes for Manuel and > Metastorage) concentrated on making the best general purpose ORM they > could > make. IOW their whole goal was to build an ORM, while my goal each time > was > to develop one for the purposes of finishing whatever real project I > happened to be working on. That meant they were closer to the problem, > had > more experience with it, and were willing to do more to solve it more > fully > and generally than I was. Again we go back to my original point. You were at a different stage of your development as a PHP OO programmer when you began using Propel than the original poster. You understood (or at least, I infer from what you write above that you understood) the fundamentals of classes and how to abstract objects with them. Let's tackle the situation from a different perspective. Remove from the scenario the specific question the poster was asking: how do I get at / use / manipulate my data? Look at the general problem he is facing: I have an object that represents a thing, but I also need to be able to deal with collections of that object, because I have a need to deal with multiples of that thing, and I don't know how to do that. Suggesting implementing a package such as Metastorage (again, don't know anything about it) or Propel (still don't know anything about it) probably addresses the surface issue. But it ignores a fundamental step a programmer should take in learning OO programming. And it's also worth mentioning at this point that it might present more of a challenge to the original poster to implement and make use of a complex data abstraction package [1] than to learn a solution that not only addresses his specific question but also helps in his learning as a programmer. > So > let me amend my recommendation by saying "check out Propel/Metastorage if > you're willing to actually study the approach it takes as opposed to > simply > plugging it in". :) Not a bad compromise at all. I'd amend it further by saying, "Here's how to understand the concept you're having difficulty with, and *then*..." Much warmth, Murray --- "Lost in thought..." http://www.planetthoughtful.org [1] Particularly since I *assume* both examples mentioned make heavy use of classes and class methods, which is exactly what the original poster is currently seeking help to understand at a fairly basic level -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
