SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 55

Thread: which framework

  1. #26
    SitePoint Member
    Join Date
    Sep 2003
    Location
    Brazil
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP Code:
    $select $db->select();
    $select->from('round_table''*')
           ->
    where('noble_title = ?''Sir')
           ->
    order('first_name')
           ->
    limit(10,20);
    $result $db->fetchAll($select); 
    See? There is some OO code also.
    Zend Framework seems very nice to me, but I'm just a patterns newbie trying to learn... It's good to read these critics.

    And please remember, guys... the framework version is still 0.1.3...

  2. #27
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    689
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by moraes
    PHP Code:
    $select $db->select();
    $select->from('round_table''*')
           ->
    where('noble_title = ?''Sir')
           ->
    order('first_name')
           ->
    limit(10,20);
    $result $db->fetchAll($select); 
    See? There is some OO code also.
    Zend Framework seems very nice to me, but I'm just a patterns newbie trying to learn... It's good to read these critics.

    And please remember, guys... the framework version is still 0.1.3...
    Yep. It does have some good stuff which is why I haven't dumped it yet.

    I admit that I don't really care for the select syntax above mainly because it means that each of the select methods have to return $this. And somehow that just seems wrong.

    But the Select object itself works well. They do need some sort of Where object to reduce the amount of manual escaping needed but I can live with what they have for now.

    But if you look at their Db_Table object then you notice some final methods some of which would be nice to be able to override.

    As far as it still being 0.1.3, yes there is hope for improvement and redesign. On the other hand the project manager has announced several times that he is shooting for an official release by the end of summer. And that's just way too soon.

  3. #28
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > Almost like they really don't want you extending their classes.

    All things being equal that is proberly the case but if the framework is well designed and developed anyways, then there is no need to extend; I use final in a lot of my library and it's used appropraitely where there wouldn't be any need to extend anyway.

    But on the other hand, if there ever is a case to extend and you can't... Then you need to apply adapters instead to get around the problem I suppose?

    > Write you are Ezku.


  4. #29
    SitePoint Addict Clenard's Avatar
    Join Date
    Sep 2004
    Location
    USA
    Posts
    337
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    cakePHP

  5. #30
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    I'm not saying that you can't mix OO and procedural - PHP works fine that way. I'm saying that when you're using procedural design, you should express it with procedural syntax - not with classes. Or did you mean that some of the static classes can also be instantiated and used as objects, if that's what I want ?

    I can see the need for namespaces in procedural code (in particular, but also in OO code for that matter), but using classes as namespaces is just plain out wrong.
    I don't agree with this at all; Although I avoid using procedural in the first place, I would rather have related functionality bundled into static classes than not, unless it's something that is used everywhere.

    In any case, I don't consider a static class to be a procedural design, as you do get some of the benefits of OOP; it's somewhere between the two.

  6. #31
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    Why? It doesn't seem wrong to me, perhaps because I used to do Perl.
    It seems that with classes, Zend use the poor-mans-namespaces as we know them from PEAR. It's awkward, but it works. The part that confuses me is that they use one technique for namespacing classes (eg. Namespace_Class) and another one for namespacing functions (eg. Namespace::Function). That doesn't make sense to me. Especially since the latter technique doesn't allow you to nest namespaces.

    Quote Originally Posted by 33degrees
    In any case, I don't consider a static class to be a procedural design, as you do get some of the benefits of OOP; it's somewhere between the two.
    We can argue from now and to eternity about what constitutes object oriented programming, but I believe that the most important and defining aspect is that objects methods are dynamically bound, in opposition to the static binding of functions. This reduces dependencies and decouples the code, which is unquestionably a quality.

  7. #32
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    We can argue from now and to eternity about what constitutes object oriented programming, but I believe that the most important and defining aspect is that objects methods are dynamically bound, in opposition to the static binding of functions. This reduces dependencies and decouples the code, which is unquestionably a quality.
    I would argue that abstraction and encapsulation are very important aspects as well, and static classes can benefit from both. If you look at Zend_Log for example, the design uses private and protected properties and methods; it's clearly not a procedural design.

  8. #33
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    I would argue that abstraction and encapsulation are very important aspects as well, and static classes can benefit from both. If you look at Zend_Log for example, the design uses private and protected properties and methods; it's clearly not a procedural design.
    Functions are abstractions too, so I don't think that makes any difference.

    I hadn't thought about the access modifiers, and you have a good point, although I wonder if it's that important at all. If one strives to avoid static classes as much as possible, and only resolve to static functions (in classes or as "procedural" functions) when absolutely needed, the private behaviour could be delegated to objects. Zend_Log is a good candidate for this type of design.

  9. #34
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    689
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    I would argue that abstraction and encapsulation are very important aspects as well, and static classes can benefit from both. If you look at Zend_Log for example, the design uses private and protected properties and methods; it's clearly not a procedural design.
    I disagree about Zend_Log.

    http://framework.zend.com/manual/en/zend.log.html

    The log adapters are indeed objects and thats a good thing. However, the main Log class that your code interacts with is static.

    Basically, instead of:
    Zend_Log::log('A serious error has occurred.', Zend_Log::LEVEL_SEVERE);
    I would rather do:
    $log->log('A serious error has occurred.', Zend_Log::LEVEL_SEVERE);

  10. #35
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ahundiak
    I disagree about Zend_Log.

    http://framework.zend.com/manual/en/zend.log.html

    The log adapters are indeed objects and thats a good thing. However, the main Log class that your code interacts with is static.

    Basically, instead of:
    Zend_Log::log('A serious error has occurred.', Zend_Log::LEVEL_SEVERE);
    I would rather do:
    $log->log('A serious error has occurred.', Zend_Log::LEVEL_SEVERE);
    I'm not sure what you're disagreeing with... the only point I was trying to make was that static classes != procedural design, that they are in fact a step in between procedural and full blown oop, sharing some qualities of each. That doesn't mean I think it's a good idea for Zend to have gone this route.

  11. #36
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    689
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    I'm hard pressed to see any oop aspects to the Zend_Log class itself. Really just looks like a couple of procedural functions with :: in their names. But we can perhaps agree to disagree on that point.

    The adapter classes illustrate my complaint about using private variables to in effect remove the oop nature of those classes. The File adapter constructor stores the file name as a private variable. So if I wanted to extend the class and tweak the manner in which the log file is opened then I run into a road block. I have no clean oop way to get the file name. So the adapters are objects but I would still call them mostly procedural objects if such a thing exists.

    But I think we have probably beaten this thread to death.

  12. #37
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The Zend_Log class is an object by virtue of the fact that it has it's own, private data, and therefore has state. So it's more than a bunch of procedural functions with :: in their names. Again, it may be a bad design, but it's still OOP.

  13. #38
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    The Zend_Log class is an object by virtue of the fact that it has it's own, private data, and therefore has state. So it's more than a bunch of procedural functions with :: in their names. Again, it may be a bad design, but it's still OOP.
    Is any function with a static variable an object then?
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  14. #39
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > Really just looks like a couple of procedural functions with :: in their names.

    Well, no they're not but in saying that I too would go as far as saying that statically calling a class method has limitations but then it's limitations that we can reasonably live with for the most part.

    The problem is just learning how to live with those limitations, or maybe more to the point how best to address those limitations within the context of your script in question?

    > So if I wanted to extend the class and tweak the manner in which the log file is opened then I run
    > into a road block.

    But hasn't that got more to do with the visibility of the class property, rather than how the class is constituted?

  15. #40
    Put your best practices away. The New Guy's Avatar
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    2,087
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by moraes
    PHP Code:
    $select $db->select();
     
    $select->from('round_table''*')
            ->
    where('noble_title = ?''Sir')
            ->
    order('first_name')
            ->
    limit(10,20);
     
    $result $db->fetchAll($select); 
    See? There is some OO code also.
    Zend Framework seems very nice to me, but I'm just a patterns newbie trying to learn... It's good to read these critics.

    And please remember, guys... the framework version is still 0.1.3...
    Is it me or is this pointless abstraction? Unless it is then again abstacted to something more expressive.
    "A nerd who gets contacts
    and a trendy hair cut is still a nerd"

    - Stephen Colbert on Apple Users

  16. #41
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    Is any function with a static variable an object then?
    Disregarding other languages where functions are indeed objects, the difference here is the scope of the variable.

  17. #42
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    Is any function with a static variable an object then?
    Quote Originally Posted by 33degrees
    Disregarding other languages where functions are indeed objects, the difference here is the scope of the variable.
    I suppose that you could think of that as an object - atleast from an abstract/design perspective. The keyword here is scope though as you say yourself - A static object is per definition global in scope.
    I reckon you're refering to javascript with the other languages part? JS is a bit different because there really is no global scope. You can always wrap whatever code executing in a new scope, and thereby redefine the "global" symbols, without affecting the rest of the code. No such thing is possible in PHP. (Discounting runkit ofcourse)

  18. #43
    SitePoint Member
    Join Date
    Sep 2003
    Location
    Brazil
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi. I'm following this discussion with a lot of interest (I'm following the Zend Framework development as well). Do you think there is already a well designed *and* ready for production PHP5 framework? Symfony, perhaps?

    Quote Originally Posted by The New Guy
    Is it me or is this pointless abstraction? Unless it is then again abstacted to something more expressive.
    Zend_Db is a wrapper to PDO.

  19. #44
    Put your best practices away. The New Guy's Avatar
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    2,087
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Is PDO just a data mapper?
    "A nerd who gets contacts
    and a trendy hair cut is still a nerd"

    - Stephen Colbert on Apple Users

  20. #45
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PDO is a database access layer. It makes calling various PHP supported databases have a uniform API. It does not perform database abstraction (e.g. rewriting queries to allow for database specific code).

    I think some of this discussion is bouncing around because of terminilogy. I will put forward some definitions and people can discuss how they see them differently:

    Active Record - a business object which combines business rules (active code enforcing business logic) and persistance (how the object is stored permanatly) in a single class.

    Table Data Gateway - a class with knowledge of how a particular table is defined in the database, and the capability to return an array of either row hashes or simple row based data objects.

    Data Mapper - a class with knowledge of a) a business object class and b) the database which this object should be persisted in. It is used to persist a business object which has no knowledge of how to persist itself. As defined by Fowler, this includes the business object having no knowledge of the Data Mapper itself. The purpose of the Data Mapper is to allow for the business object and the database schema to evolve independently. The price you pay for this independance is the added complexity of the Data Mapper itself.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  21. #46
    Put your best practices away. The New Guy's Avatar
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    2,087
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by sweatje
    PDO is a database access layer. It makes calling various PHP supported databases have a uniform API. It does not perform database abstraction (e.g. rewriting queries to allow for database specific code).
    Ok. Then why would Zend want to wrap it further? If it already has an API aren't you just obscuring it by adding another layer?
    "A nerd who gets contacts
    and a trendy hair cut is still a nerd"

    - Stephen Colbert on Apple Users

  22. #47
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    I suppose that you could think of that as an object - atleast from an abstract/design perspective. The keyword here is scope though as you say yourself - A static object is per definition global in scope.
    I should've made my self clearer. When I mentioned scope, I was refering to the static private properties; although the class itself is global in scope, the data it contains isn't, it is only accessible by the static methods, and is therefore encapsulated by the class. This is what, in my mind, makes a static class an object.

    Quote Originally Posted by kyberfabrikken
    I reckon you're refering to javascript with the other languages part? JS is a bit different because there really is no global scope. You can always wrap whatever code executing in a new scope, and thereby redefine the "global" symbols, without affecting the rest of the code. No such thing is possible in PHP. (Discounting runkit ofcourse)
    Actually I was thinking of Ruby and Python, but it applies to JS as well. The odd thing I've found about JS is how, if you use a variable without declaring it, it automatically belongs to the global scope. Seems like an odd design decision to me, although there's probably a good reason I'm not thinking of.

  23. #48
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    although the class itself is global in scope, the data it contains isn't, it is only accessible by the static methods, and is therefore encapsulated by the class. This is what, in my mind, makes a static class an object.
    It retains the same meaning whereever you refer to it in your code, and thus you can't change the "object" without affecting every part of your entire application, that depends on it. The access modifiers doesn't change that.

    That pretty much constitutes a global in my taxonomy.

    Quote Originally Posted by 33degrees
    The odd thing I've found about JS is how, if you use a variable without declaring it, it automatically belongs to the global scope. Seems like an odd design decision to me, although there's probably a good reason I'm not thinking of.
    I'm afraid there is no subtle reason other than JS was rushed out of the labs, and initially meant for very small scripts, where globals doesn't hurt much. (Now where have I heard that before?)

  24. #49
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by The New Guy
    Ok. Then why would Zend want to wrap it further? If it already has an API aren't you just obscuring it by adding another layer?
    There are plenty of good reasons for wanting to wrap an existing API; to simplify a complex one, to harmonize it with the rest of your library, or to extend its functionality. In this case it was a desire to further abstract the differences between various database engines, for things like LIMIT clauses and retrieving the last inserted id. There's also a mysqli adapter and an oracle adapter that doesn't use PDO.

  25. #50
    Put your best practices away. The New Guy's Avatar
    Join Date
    Sep 2002
    Location
    Canada
    Posts
    2,087
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by 33degrees
    There are plenty of good reasons for wanting to wrap an existing API; to simplify a complex one, to harmonize it with the rest of your library, or to extend its functionality. In this case it was a desire to further abstract the differences between various database engines, for things like LIMIT clauses and retrieving the last inserted id. There's also a mysqli adapter and an oracle adapter that doesn't use PDO.
    So its just glue basically?
    "A nerd who gets contacts
    and a trendy hair cut is still a nerd"

    - Stephen Colbert on Apple Users


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •