SitePoint Sponsor

User Tag List

Page 1 of 12 1234511 ... LastLast
Results 1 to 25 of 325

Hybrid View

  1. #1
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Kansas City, MO
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Question Proposal for Standards & Interface Repository

    Howdy all,

    I'm a relative newcomer to SitePoint, but I've been working with PHP in some capacity for over half a decade now. The most recent discussions on patterns and the new object model in PHP 5 lend themselves greatly to libraries and classes being stitched together to make application development that much smoother. The problem has always been that once you rely on one library or classes API, you've coupled yourself to that class or a specific implementation. With pseudo-interfaces in PHP 4, and the real thing in PHP 5, there's no need for this.

    My proposal is for the Open Standards & Interface Repository (will be housed at opensir.org if this takes off and people want to do it). The idea will be to create a repository of standard "libraries" such as phpCR which define an behavior of set of interfaces as well as standard interfaces for various patterns. With this, applications that then begin to rely on a Registry interface and know that whatever class they download that implements Registry will work the way they are intending it to be used.

    My thought would be that all interface proposals would start out as PHP, as they progressed and became stable they would move to PECL as part of an OpenSIR extension, with the possibility that a select group of stable ones could become part of the the regular PHP distribution.

    Of course, I would be willing to submit phpCR as the first "library" for review. It's already in 0.2 status as a direct port from the Java Content Repository but has areas that could probably be improved for PHP specific implementations. Also, I would be happy to put together a list of interfaces for basic patterns that could be discussed.

    We would need some sort of distribution channel (a pear channel possibly?). I would need some help mirroring an effort like this. For the website, does anyone have any recommendations for software? Something more user friendly than the PEAR/PECL sites would be preferable, but a straight wiki would be hard to manage (unless someone wants to volunteer). Also, are there any designers out there that would like to lend a hand? We'd need a logo and design.

    Well, before I go on too much more... Does anyone have any thoughts? I've seen several comments about people wanting a standard approach to development in PHP using a framework of some sort or another. Personally, I think we would be better off as a community to come up with standard interfaces and see what implementations come out of them. If we can agree on the API, then switching between the various implementations will be easy as they'll all be hot-swappable. Then you can really try them all out if you want before you figure out which one works for you.

    Quick note on the name: I thought about doing something with PHP in the name, but decided against it. One obvious thing is the PHP's group request that projects outside of PHP not use the name. Additionally, while right now I would see the focus on PHP, I don't see anything stopping contributors at a future time from wanting to expand to include other languages as well. Common APIs across languages wouldn't be a bad idea at all and by going with OpenSIR, we keep that possibility available.

  2. #2
    SitePoint Member
    Join Date
    Jul 2004
    Location
    Budapest, Hungary
    Posts
    24
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

  3. #3
    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)
    While interfaces are more open-ended than implementations, they still express a concrete idea. It would therefore not be uncommon to have competing interfaces as is the case with concrete classes too. It's a good idea initially, but it has an emminent danger of becoming PEAR the sequal.

    Perhaps an approach could be to rejuvenate PEAR by defining interfaces for the classes which already exists ?

    Quote Originally Posted by Travis S
    but a straight wiki would be hard to manage
    Some wikis have user-profiles like regular forums. This could be useful against spam.

  4. #4
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Kansas City, MO
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by norbort_m
    Yes, I am familiar with SPL, but I believe it's goal has been more to allow you to plug into the internals of PHP (i.e., Iterator allowing you to utilize foreach() and the various Array interfaces allowing you to overwrite array handling). It does provide many useful interfaces. I also haven't seen a means for proposing new interfaces, but I may have just overlooked it.

    Quote Originally Posted by kyberfabrikken
    While interfaces are more open-ended than implementations, they still express a concrete idea. It would therefore not be uncommon to have competing interfaces as is the case with concrete classes too. It's a good idea initially, but it has an emminent danger of becoming PEAR the sequal.
    Very true. I believe a lot of common demoninators can be reached at the interface level to keep them generic enough to fill the majority of common roles. JCR provides an interface generic enough to work in just about any environment, while still providing enough optional interfaces to allow for versioned nodes, locking, observation, etc.

    Take the template for example. There are probably hundreds of various "template engines". They could all be broken down into one simple interface with several more added on top of it:

    PHP Code:
    interface Template {
      public function 
    assign($key$value);
      public function 
    display($file);

    This could be extended to offer the ability to have fetch(), setFile(), addPath(), etc. Then the user of the various template engines could know whether they can switch by relying on the interface they need.

    Quote Originally Posted by kyberfabrikken
    Perhaps an approach could be to rejuvenate PEAR by defining interfaces for the classes which already exists ?
    The thought did cross my mind. PEAR's goal is to be a code repository though. What I'm looking for is something that would provide best practice guidence for developers. I also have some personal differences with assumptions made by PEAR (the biggest being the assumption of being in the include_path). Ideally, I could see this gaining steam and PEAR becoming a repository of implementations of the various common interfaces.

    That's what I'm proposing this for though, if I'm the only one that thinks that it would be better independent then maybe PEAR is the way to go.

  5. #5
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This seems like a very good idea in principle. As kyber points out though, it might be just as hard to get the developers to agree on a particular interface as it is to get them to agree on an implementation. After all, the interface already defines a lot of things, like a coding style, a design roadmap and some other specifics that the implementation would have to follow.

    Nevertheless, I would be glad to design a logo and a visual template for the website if this takes off; for now this is probably the perfect place to start to put forth ideas and consider the finer points.
    Quote Originally Posted by Travis S
    I've seen several comments about people wanting a standard approach to development in PHP using a framework of some sort or another.
    Absolutely. Almost any PHP developer of a certain caliber has been longing for this for quite a while now. PEAR was supposed to fill that gap, but it failed miserably, and quite honestly I don't hold much of a hope for it to change directions in the near future.

    Quote Originally Posted by Travis S
    It's already in 0.2 status as a direct port from the Java Content Repository
    IMHO, this has the potential of becoming a big hurdle as well. There are two mainstream movements in "Advanced PHP" nowadays. The one seems to be looking up to Java as its older brother, and thinking "that's what I want to be when I grow up". The other wants PHP to evolve in it's own right, taking advantage of what it does best and designing its own custom idioms that will advance the language as an independent entity. Neither group is 100% right, and both are probably neccesary to keep the language balanced, but I tend to caution against the dangers of mimicking Java too much without considering alternative approaches that may work much better in PHP. To provide an extreme example as an illustration (I am sure you have run accross this in the past), some PHP developers out there are creating classes for "String", "Array" and "Hashmap". I stand clear of that path, and I am sure you do too.
    Garcia

  6. #6
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ghurtado
    This seems like a very good idea in principle. As kyber points out though, it might be just as hard to get the developers to agree on a particular interface as it is to get them to agree on an implementation. After all, the interface already defines a lot of things, like a coding style, a design roadmap and some other specifics that the implementation would have to follow.

    Nevertheless, I would be glad to design a logo and a visual template for the website if this takes off; for now this is probably the perfect place to start to put forth ideas and consider the finer points.

    Absolutely. Almost any PHP developer of a certain caliber has been longing for this for quite a while now. PEAR was supposed to fill that gap, but it failed miserably, and quite honestly I don't hold much of a hope for it to change directions in the near future.


    IMHO, this has the potential of becoming a big hurdle as well. There are two mainstream movements in "Advanced PHP" nowadays. The one seems to be looking up to Java as its older brother, and thinking "that's what I want to be when I grow up". The other wants PHP to evolve in it's own right, taking advantage of what it does best and designing its own custom idioms that will advance the language as an independent entity. Neither group is 100% right, and both are probably neccesary to keep the language balanced, but I tend to caution against the dangers of mimicking Java too much without considering alternative approaches that may work much better in PHP. To provide an extreme example as an illustration (I am sure you have run accross this in the past), some PHP developers out there are creating classes for "String", "Array" and "Hashmap". I stand clear of that path, and I am sure you do too.

    I actually saw code a few weeks ago with this implementation (replaced the prefix with "x" so as to not identify the guilty party).

    PHP Code:
    class xString{

         function 
    __toString() 
         {
             ... 
         }

    Just think about that one for a minute. I never quite understood the logic of developing this way; if you want to program with Java...just program with Java. PHP has some very unique strengths, as it borrows from both perl's powerful string manipulation and C/C++/Java's facilities for application development (borring OO features from C++ & Java, and low-level functions from C). This is why it's such a popular, powerful language -- it truly offers you flexibility that few languages can claim to be able to truly deliver.

  7. #7
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think this is a great idea to foster interop. A problem I see is that interface design is actually much more difficult than implementation simply because it is more abstract and has to meet needs greater than a given particular implementation might. To me that implies a well defined review process that is both critical and rigorous and involves lots of consultation.

    Another problem is that all the interfaces in the world won't help anyone unless they are easy to implement in a particular system. As there is no set standard for a framework design in PHP, perhaps this is best place to start. Good luck though trying to get a consensus on that one Not that you need 100% buy-in, of course. I just think it would be a good starting point because it would help give a better picture of the types of things that you might want to see standardized.

    One thing about using Pear as a basis: even though its early roots have left it with a design that is not particularly beautiful -- because the Pear folks tend to stick to their guns to save compatability, it means that following their lead could help interop as there would already be at least one implementation of the interfaces. I'm actually somewhat of a purist at heart but I can't see much point in generalization unless there are multiple and concrete contact points out it the wild. In other words, if this only lead to one more implementation (say a "better" Pear) then it may not really be any more useful than Pear -- perhaps just prettier.

    Lots of work, definately. Do you plan on setting up some sort of public working area to get this fleshed out or at least to help give an idea of what its scope would be?
    Last edited by jayboots; Sep 11, 2005 at 18:51.

  8. #8
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    While I agree with the problem (maybe) I really don't with this proposed solution. You will have the same problem that other already baked designs have, how do you get a lot of programmers to both grok your ideas and get excited about them. Your phpCR reminds me of WACT (because we have recently been discussing it). Both have lots of good ideas, good execution and a smart guy behind them with great ideas. But there is little uptake because both have solidified a group of interrelated classes and by doing so have made thousands of design decisions that shape the thing. Unfortunately there is too much done to interest other designers to get on board and take the design to the next level, and not enough done for programmers to be interested in using it for projects .

    kyberfabrikken and I went through the design process on the skeleton threads and we know how difficult it is to have aligned goals, trust and good communication. Two or three people are not enough. You really need the informed input of 5-10 good programmers to make something as big a standard framework or library get to the necessary quality level. You need to start small and get a large group to have ownership in the design.
    Christopher

  9. #9
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Kansas City, MO
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Howdy all...

    Well, I'm pleased that this is getting some discussion. That's what I hoped for

    Quote Originally Posted by ghurtado
    IMHO, this has the potential of becoming a big hurdle as well. There are two mainstream movements in "Advanced PHP" nowadays. The one seems to be looking up to Java as its older brother, and thinking "that's what I want to be when I grow up". The other wants PHP to evolve in it's own right, taking advantage of what it does best and designing its own custom idioms that will advance the language as an independent entity. Neither group is 100% right, and both are probably neccesary to keep the language balanced...
    I agree completely. phpCR was a straight port because that's what I had to work with. Since there wasn't an OpenSIR to help formulate ideas and come up with the right solutions in the scope of PHP. There are areas right now that I'm sure aren't good. I've already deviated from JSR-170 in the exporting of XML. To me, it didn't make sense to use the out parameter to put the returned results in. PHP'ers are used to methods returning, so I'm returning a valid DOM. Makes more sense to me than making a user include an initialized dom as part of the exportXML() call.

    These are the kinds of things I would think would be better worked out as a group, however. I might hazard an occassion streak of luck and get something right, but the odds of that happening go up exponentially with others involved.

    Quote Originally Posted by ghurtado
    To provide an extreme example as an illustration (I am sure you have run accross this in the past), some PHP developers out there are creating classes for "String", "Array" and "Hashmap". I stand clear of that path, and I am sure you do too.
    Actually, I saw something like this proposed on PECL awhile back. The idea was to create native objects for each of the types - and I'm all for it. One of the values of PHP is diversity of ideas. Each of us have our own way of doing things and enabling all of those ideas is generally a good thing. Now I would be against doing it in PHP code just because the extra overhead wouldn't be worth it. But, if there was an internal String object that would give me a clear interface for changing type and such it would definitely give me something to consider...

    The one value of having the raw values though is that the rest of the implementation for all the various conversion functions and whatnot are not automatically loaded into memory. It might be that StringObj wouldn't be worthwhile except in the rarest of cases. Possibly like the extra functionality that ADOdb provides. If you need that functionality, then its a god-send, but if I'll you're doing is querying a database and displaying the results it can be overkill. It's all a matter of the right tool for the job.

    Quote Originally Posted by jayboots
    I think this is a great idea to foster interop. A problem I see is that interface design is actually much more difficult than implementation simply because it is more abstract and has to meet needs greater than a given particular implementation might. To me that implies a well defined review process that is both critical and rigorous and involves lots of consultation.
    Agreed. Interface design is a much longer process. Take JSR-170 for example. It took over three years to go from initial ballot that they wanted to do it to actually releasing the final code. I'm not saying that everything will take that much time, but some of the larger projects will definitely be long haul endeavors. For something like this to work it will definitely take several people to come together and make commitments to hash out the ideas to make this happen. The coding will be a small part of what's done. Creating the entire phpCR interface as it stands now took me a few weeks working an hour or so a day - the real time had been spent by the people who created the spec for it.

    Quote Originally Posted by jayboots
    Lots of work, definately. Do you plan on setting up some sort of public working area to get this fleshed out or at least to help give an idea of what its scope would be?
    Yes... I can set a site up. I'm using this as a basis for determining if anyones interested, which it looks like there is some interest. We can continue to use it to hash out ideas and where to go from here. I can setup a mailing list (if people would prefer that route) and get a site online. Right now, I would be leaning toward MediaWiki as I know it, but if anyone else has any ideas shoot them my way.

    Quote Originally Posted by arborint
    While I agree with the problem (maybe) I really don't with this proposed solution. You will have the same problem that other already baked designs have, how do you get a lot of programmers to both grok your ideas and get excited about them. Your phpCR reminds me of WACT (because we have recently been discussing it).
    I think you might misunderstand what phpCR is - there are only a handful of concrete classes there and they are generally inconsequential. It's composed 95% or more of interfaces. Each developer is left up to their own devices to figure out how they can best work it into their system. You might have this confused with my d51CR which is an implementation of phpCR - it's still in its infancy though and is a completely moving target as to exactly how I'm going to implement the storage behind it.


    To bring this back to OpenSIR (I'm just throwing that out as a working name for the time being)... There are a few things that need to be done to move forward from here.

    • Create a mission statement
    • Determine the scope
    • Determine a means for creating/submitting packages.
    • Determine how packages are adopted


    Creating a mission statement
    As a rough draft...

    To foster the creation and adoption of standards with the help of the international PHP community.

    Or...

    To foster the creation and adopts of standards identified by the international PHP community.

    Thoughts, additions, deletions?

    Determine the scope
    I would say this is an evolving thing. At first, I think the focus could be codifying standard interfaces to patterns within PHP. My Template interface would be one example. Another is Registry. It will always need a getInstance() (or maybe instance()?) and a get() and set() method.

    Eventually, I would like to see this evolve into something like JCP where full fledge specifications are being created for PHP coders.

    Determine a means for creating/submitting packages.
    Should individuals create the ideas and have others comment on them (a la PEAR)? Should ideas be identified/submitted and then solicit people to work on creating them?

    Determine how packages are adopted
    I imagine we'll need some sort of voting for this. What should the process be? Do we want voting on the final package, or should that be handled up front (i.e., yes or no we want to do this package). Is this open to everybody that wants to vote or should this be opened to members/developers only? If so, what's the requirements for membership?


    Ok... This is long enough now. Your turn. Thoughts, comments?

  10. #10
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Travis S
    I think you might misunderstand what phpCR is - there are only a handful of concrete classes there and they are generally inconsequential. It's composed 95% or more of interfaces. Each developer is left up to their own devices to figure out how they can best work it into their system. You might have this confused with my d51CR which is an implementation of phpCR - it's still in its infancy though and is a completely moving target as to exactly how I'm going to implement the storage behind it.
    No, I see that it is mostly interfaces. But interfaces are the design. Given how most of the programmers here code, once the interfaces shake out there is no more than a dozen lines behind each call.

    So what you have is a massive Java based design that I have only the slightest inkling of whether it is either good in PHP or the kind of code I want to use. So why should I go with those interfaces rather than the many other sets of them lying around the Internet (many battle tested)?
    Christopher

  11. #11
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Travis S
    Actually, I saw something like this proposed on PECL awhile back. The idea was to create native objects for each of the types - and I'm all for it.
    I suppose this is slightly OT for this topic, but it seems logical. Assuming you want type hinting at all, not having it for primitive types is just artificial and half-baked.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  12. #12
    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 Travis S
    Determine the scope
    Perhaps this is the important point. I think such an effort could easy strand because of the mere magnitude of it. Better to start out with a limited subject. For example, it could be interesting to see an interface formulated, which meet the featureset of all the templateengines in PEAR.

  13. #13
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Kansas City, MO
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Perhaps this is the important point. I think such an effort could easy strand because of the mere magnitude of it. Better to start out with a limited subject. For example, it could be interesting to see an interface formulated, which meet the featureset of all the templateengines in PEAR.
    Ok... Let's go with the Template pattern. I haven't looked at any of the templates in PEAR, though I have participated in Savant and used Savant, Smarty, and my own home grown.

    There are three main interfaces:
    PHP Code:
    interface Template {
        public function 
    assign($key$value);
        public function 
    display($file null);
    }

    interface 
    PluginTemplate extends Template {
        public function 
    registerPlugin($name);
    }

    interface 
    FilterTemplateDecorator {
        
    // how do we tell it about Template?  
        
    public function setPreFilter($callback);
        public function 
    setPostFilter($callback);
    }

    // with two additional classes...

    interface FileBasedTemplate extends Template {
        public function 
    addPath($path);
        public function 
    setFile($file);
    }

    interface 
    FetchTemplateDecorator {
        
    // Again, ideas on making the decorator aware of the the decorated?
        
    public function fetch($file null);

    Have I missed anything? I believe that covers all of the main uses of template engines.

    The two I'm not sure on are the decorators and how to make them aware of a Template object. Should they be responsible for instantiating their own Template object, should they be given one, or should that matter?

    Another question: should plugins and filters be explicit as above, or should they be part of an ObserverableTemplate? You could specify blank interfaces to signify that the ObserverableTemplate does notify for certain events (prefilter, postfilter, unknownMethod for plugin attempts).

  14. #14
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Travis S
    PHP Code:
    interface Template {
        public function 
    assign($key$value);

    The WACT template class does not do the same thing:

    PHP Code:
    Class Template {
        function 
    registerDataSource(&$DataSource);
    }

    $data->variable 'value';
    $template->registerDataSource($data);

    instead of

    $template
    ->assign('variable''value'); 

  15. #15
    SitePoint Wizard
    Join Date
    Jan 2004
    Location
    3rd rock from the sun
    Posts
    1,005
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Will it be true that through openSIR the php community will have another combined voice that the PHP maintainers will be able to see trends in PHP thinking and solutions?

    Maybe less formalised than PEAR or PECL - but nevertheless "what some users are doing with PHP".

    If so, it could make PHP nimbler and more reactive to the changing nature of the internet, than say Java. And that is one if its strengths, right?

  16. #16
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Kansas City, MO
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by paulyG
    Will it be true that through openSIR the php community will have another combined voice that the PHP maintainers will be able to see trends in PHP thinking and solutions?

    Maybe less formalised than PEAR or PECL - but nevertheless "what some users are doing with PHP".

    If so, it could make PHP nimbler and more reactive to the changing nature of the internet, than say Java. And that is one if its strengths, right?
    I agree to some extent... PHP doesn't need to become mired in standards or zealously followed best practices. However, it does need to start reaching some common ground so developers can quit re-implementing the wheel when it comes to their APIs.

    Quote Originally Posted by arborint
    No, I see that it is mostly interfaces. But interfaces are the design. Given how most of the programmers here code, once the interfaces shake out there is no more than a dozen lines behind each call.
    In some cases... In phpCR there's multiple paths to strike out on once you determine which type of repository you want to setup (flat ID based or heirarchical). After that, are you going to go read-only or read-write? After that, do you implement Observation, Versioning, and Locking, or none of the above? Do you tie to one particular database storage system, XML files, or some other home-grown storage solution?

    You are correct that the bird's eye design is done, but there's still a hundred different ways to implement it if you have a hundred different programmers.

  17. #17
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OK, let's decide on what the interface should be, maybe:
    PHP Code:
    interface Template {
        public function 
    set($key$value);
        public function 
    render($file null);
    }
    // or
    interface Template {
        public function 
    assoc($key$value);
        public function 
    output($file null);
    }
    // or
    interface Template {
        public function 
    __construct($file null);
        public function 
    set($key$value);
        public function 
    display();
    }
    // or
    interface Template {
        public function 
    __construct($file null);
        public function 
    setTag($key$value);
        public function 
    toString($file null);
    }
    // or
    interface Template {
        public function 
    loadFile($file null);
        public function 
    setTemplate($template_str null);
        public function 
    assignValue($key$value);
        public function 
    display();
    }
    // or
    interface Template {
        public function 
    __construct($file null);
        public function 
    set($key$value);
        public function 
    process($template_str null);
    }
    // or
    interface Template {
        public function 
    __construct($template_path null);
        public function 
    setTemplateFile($file null);
        public function 
    setVariable($key$value);
        public function 
    toHTML($filename null);
    }
    // or
    interface Template {
        public function 
    setFile($file null);
        public function 
    assoc($key$value);
        public function 
    render($template_str null);
    }
    // or 
    Christopher

  18. #18
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Kansas City, MO
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)


    Your post does make my point exactly - nearly every one of those does the same thing. What I've done is adopted the two largest APIs of Smarty/Savant (in their smallest form) which I believe are the ones that people will be the most familiar with.

    I don't know, maybe one of PHP's strengths is its "rugged individualism". Trying to create a collection of standards might not work in its context. Although, it would be nice to be able to swap out code without having to worry about all your custom code that's tied to properitary APIs.

  19. #19
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It makes your point, which I agree with, that they do nearly the same thing and we would be better off with a standard.

    But you didn't go through the process of finding what the best interface is. You simply picked the one that you use and claim "that people will be the most familiar with" but I don't use that interface and I will bet that few others in this forum do either. So you have an interface that maybe a few people use, you have provided no rational that it is any good or how it is consistent with other interfaces you will implement, but you want us to change our code to your style. Why should we switch? Now multiply that times 100 interfaces.
    Christopher

  20. #20
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    FWIW, I think that the template patterns are deceptively simple but in fact are rather complicated to generalize mainly because there are so many ways to approach them. Perhaps it might be more productive in terms of this thread to start with a smaller, more narrowly defined concept. For example, cache access, resources/libraries, parsers, etc.

    There seems also to be some issue in the thread about implementations following the interface (ie. needing to be re-written to the "standard"). This ought not be strictly so: emulation through adaptors should be sufficient.

  21. #21
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I agree with you, jayboots. I think the idea of adaptors is a key one here. Maybe the best chance this has of becoming the standard it needs to be is by being more of a repository of adaptors rather than interfaces only. That way if someone wants to submit a class for "compliance" they wouldnt need to rewrite their interface (fat chance this would happen in the majority of cases), but rather simply just provide an adaptor that couples with the standard interface, and the same level of interoperability could be achieved.
    Garcia

  22. #22
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ghurtado, I like your thinking. I wonder if it would be equally suitable to have a related secondary project that strictly dealt with adaptors. Adaptors can be rather tricky in their own right since they are so dependant on implementation. As such, I see them as having a lower "standardization" quotient (to make up new terms) than interfaces. Separating the two, the interfaces project could stay more on goal but would have some impetus to consider the needs of adaptor classes. At any-rate, I suspect that without adaptors for popular libraries, buy-in will be much harder to foster.

  23. #23
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Maybe the standards project could provide two different "levels" of approval? One for compliant interfaces and another one for libraries with compliant adaptors. But at the same time, it wouldn't be a good idea to "downgrade" those that achieve compliance via adaptors instead of interfaces. I think they could be the majority anyway. So the first step is defining the interfaces anyway, and then it is the developers choice to provide interface compliance or adaptor compliance.

    If the whole adaptor idea takes off, I see a lot of potential for this project. May we want to start with some coding guidelines / best practices, perhaps?
    Garcia

  24. #24
    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)
    It's probably a good idea to accompany each interface with appropriate adapters to known (and popular) implementations. I have the feeling that this would by far exceed the interfaces themselves in size, but that's not bad. In fact it could result in a general integration/compatibility toolkit for all the disparate libraries around. That would definately be useful.

  25. #25
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Game On!
    First thing, each object needs to have a means of saying what it contains. We could use the line that ItemForSale->getAmount() will always get that item's "amount" value, or it could be ItemForSale->get('amount'). The latter leads to easier swaping between objects because there's no need to tie to a specific method.
    I'm assuming we're talking PHP 5.0. Instead of requiring accessor methods for each property, why not start with the standard PHP property access mechanism?
    PHP Code:
    Interface DataSource {
        function 
    __get($property);
        function 
    __set($property$value);
        function 
    __isset($property);
        function 
    __unset($property);

    Let me defined a usecase that I think needs to be supported:

    PHP Code:
    class MyDatabaseConfiguration extends DataSourceSupport implements DataSource {
        public 
    $host 'localhost';
        public 
    $database 'myapp';
        public 
    $user 'jeff';
        public 
    $password 'secret';

    It should be possible to define a trivial data object such as this without having to declare accessor methods for each property. Thus, I will defer discussion accessor methods until a later post. Remember that the interface is about how others see the object, not about how its implemented internally. With the proper adapters, it should be possible to adapt almost any object to the DataSource interface.

    With either, there needs to be a means of introspection so outside code knows what is available (I'm thinking particularly the Mapper part of DataMapper in this case). Something along the lines of getAvailableProperties() or getDeclaredProperties()?
    Excellent. Lets have some meta data description classes. I think it will help make the discussion easier to follow:
    PHP Code:
    interface PropertyInfo {
        function 
    getName();
    }

    interface 
    DataSourceInfo {
        function 
    getClass();
        function 
    getPropertyInfo($property);

    Note that I'm not saying how one would get a DataSourceInfo instance. I'm not sure that adding a getAvailableProperties() or getDataSourceInfo() method to the DataSource interface is necessarily a good idea because of the extra dependency. (The JavaBeans spec avoids doings this.)

    Now, there are three kinds of properties: standard, read only and write only. So
    PHP Code:
    interface PropertyInfo {
        function 
    getName();
        function 
    isReadable();
        function 
    isWritable();

    Since a property might not be defined, an we need an exception:
    PHP Code:
    class PropertyNotFoundException extends Exception {} 
    Either __get or __set could raise this exception. Its not unusual for a __set style method in PHP to add a property that does not exist. I don't think its possible to pick only one behavior for __set (add if not found or exception if not found), so I would suggest adding the ability to find out which behavior one might expect:
    PHP Code:
    interface DataSourceInfo {
        function 
    getClass();
        function 
    getPropertyInfo($property);
        function 
    canAddProperties();

    __unset presents a problem. With some kinds of DataSources, it will not be possible to actually remove a property, instead one would probably set it to NULL. Thus, I think that __unset should do just that. Remove if it can, set to NULL if it can't. That means we need more meta-data to figure out which behavior to expect:
    PHP Code:
    interface DataSourceInfo {
        function 
    getClass();
        function 
    getPropertyInfo($property);
        function 
    canAddProperties();
        function 
    canRemoveProperties();

    or alternatively, we need an exception for __unset to raise:
    PHP Code:
    class CannotRemovePropertyException extends Exception {} 
    Since __isset should match the isset function and return FALSE if the property exists but has a value of NULL, we should probably have a hasProperty method on the DataSource interface. I would also put an addProperty() on, just to be more explicit. Lets throw on a removeAllProperties, a setMany, and an import, too:

    PHP Code:
    Interface DataSource {
        function 
    __get($property);
        function 
    __set($property$value);
        function 
    __isset($property);
        function 
    __unset($property);
        function 
    hasProperty($property);
        function 
    addProperty($property$value);
        function 
    removeAllProperties();
        function 
    setMany($propertyValueList);
        function 
    import($propertyValueList);

    setMany and import both take an array of the form array('property'=>'value'). The difference between setMany and import is that import does the equivalent of __unset on every pre-existing property that is not in the propertyValueList. In other words, import starts over from a blank slate.

    I would favor hard tabs to soft - even though PEAR does it the other way - simply from a storage perspective. "\t" is faster to load and smaller to storage than " ".
    At the risk of starting an bad tangental discusssion, Who cares about a few bytes these days? Spaces are the only technique that can preserve formatting regardless of the program displaying the text. (Think about things like cat blah.php on the command line and browsing source code via an html based CVS browser).


    (I don't use php 5 oo on an everyday basis please correct and forgive any transgressions I may make )


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
  •