SitePoint Sponsor

User Tag List

Page 1 of 13 1234511 ... LastLast
Results 1 to 25 of 325
  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
    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 17:51.

  7. #7
    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

  8. #8
    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?

  9. #9
    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

  10. #10
    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?

  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 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.

  15. #15
    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

  16. #16
    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.

  17. #17
    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

  18. #18
    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'); 

  19. #19
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    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'); 
    Mine based on the Skeleton DataSource supports both but calls it:
    PHP Code:
    $template->set($tag$value);
    $template->import($data); 
    But Selkirk's is a more expressive name. Yeah, let's use that one. Ready to change all your code to this style Travis?
    Christopher

  20. #20
    SitePoint Zealot Overunner's Avatar
    Join Date
    Mar 2004
    Location
    Sweden
    Posts
    180
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    But Selkirk's is a more expressive name.
    I think the name "registerDataSource" is too long. How about setMultiple/setVars/setArray?

    Should the template be able to include sub-templates btw?

  21. #21
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Kansas City, MO
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    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'); 
    At which point we would also need to define what a datasource can be.

    Quote Originally Posted by arborint
    But Selkirk's is a more expressive name. Yeah, let's use that one. Ready to change all your code to this style Travis?
    If that were to become an agreed upon standard, yes. Of course, I would write an adapter to make sure I didn't break any existing code, but I would start a migration.

    My first Template code missed on key thing - that was just an idea. As we've demonstrated here, there are many different ways to do the same thing.

    Maybe there are just too many ways to do things in PHP to come up with a set of standard interfaces...?

  22. #22
    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 Travis S
    Maybe there are just too many ways to do things in PHP to come up with a set of standard interfaces...?
    Just as many as in Java. Why can they agree on standards where we can't?
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  23. #23
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Kansas City, MO
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Overrunner
    Should the template be able to include sub-templates btw?
    I would say that a Template should be able register anything. Something along these lines would not be an uncommon bit of code:
    PHP Code:
    $header = new EchoableTemplate();
    $header->setFile('header.html.php');
    $page = new Template();
    $page->set/assign/etc('header', $header);
    $page->display('page.html.php');

    // inside page.html.php
    <?php echo $header?>

  24. #24
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    Oklahoma
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    Just as many as in Java. Why can they agree on standards where we can't?
    Because theirs are pushed down from above for starters. The SPL is an attempt, in my opinion, for "the powers that be" in the PHP world to attempt to push some semblence of standards upon everyone. The problem being is they lost most of their credibility due to the PEAR debacle. I also think a big reason it won't work is that the vast majority of PHP programmers, didn't start as programmers, and aren't really interested in standards, just "making it work".

    But most importantly, unlike Java PHP doesn't have a real central community of any sort. You've got the internals folks, you've got sitepoint, you've got PHPBuilder, and dozens of other smaller community sites. There's just no reasonable way at this point, without a mandate from zend/internals folks, to get standards introduced, agreed upon, and more importantly implemented.

  25. #25
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Kansas City, MO
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    Just as many as in Java. Why can they agree on standards where we can't?
    Possibly because of PHP's lower barrier to entry...?


    Based on what I'm seeing here, I think there's a lot of FUD about interfaces. Again, just because you have to call set(), or assign(), or registerData(), it doesn't mean you have to adhere to anything more than that API. It's no different than saying you implement a particular pattern - the only difference is with an interface you can prove you've implemented the pattern in an expected manner and others can rely on a particular API to be made available and based on how much they trust your coding style a particular result


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
  •