SitePoint Sponsor |
|
User Tag List
Results 1 to 25 of 325
-
Sep 11, 2005, 14:38 #1
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Sep 11, 2005, 14:46 #2
- Join Date
- Jul 2004
- Location
- Budapest, Hungary
- Posts
- 24
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Did you see http://www.php.net/~helly/php/ext/spl/ ?
-
Sep 11, 2005, 15:39 #3
- 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 ?
Originally Posted by Travis S
-
Sep 11, 2005, 16:35 #4
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by norbort_m
Originally Posted by kyberfabrikken
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);
}
Originally Posted by kyberfabrikken
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.
-
Sep 11, 2005, 16:35 #5
- 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.
Originally Posted by Travis S
Originally Posted by Travis S
Garcia
-
Sep 11, 2005, 17:13 #6
- 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 oneNot 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.
-
Sep 11, 2005, 17:30 #7
- 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
-
Sep 11, 2005, 20:05 #8
- 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
Originally Posted by ghurtado
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.
Originally Posted by ghurtado
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.
Originally Posted by jayboots
Originally Posted by jayboots
Originally Posted by arborint
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?
-
Sep 11, 2005, 20:44 #9
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
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
-
Sep 12, 2005, 00:17 #10
- 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?
-
Sep 12, 2005, 00:21 #11
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
Sep 12, 2005, 03:41 #12
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
-
Sep 12, 2005, 07:24 #13
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by kyberfabrikken
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);
}
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).
-
Sep 12, 2005, 07:47 #14
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by paulyG
Originally Posted by arborint
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.
-
Sep 12, 2005, 08:31 #15
- 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
-
Sep 12, 2005, 08:44 #16
- 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.
-
Sep 12, 2005, 10:48 #17
- 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
-
Sep 12, 2005, 12:04 #18
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
PHP Code:Class Template {
function registerDataSource(&$DataSource);
}
$data->variable = 'value';
$template->registerDataSource($data);
instead of
$template->assign('variable', 'value');
-
Sep 12, 2005, 12:51 #19
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Selkirk
PHP Code:$template->set($tag, $value);
$template->import($data);
Christopher
-
Sep 12, 2005, 14:14 #20
- Join Date
- Mar 2004
- Location
- Sweden
- Posts
- 180
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
Should the template be able to include sub-templates btw?
-
Sep 12, 2005, 14:19 #21
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Selkirk
Originally Posted by arborint
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...?
-
Sep 12, 2005, 14:21 #22
- Join Date
- Jun 2003
- Location
- Iowa, USA
- Posts
- 3,749
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
Jason Sweat ZCE - jsweat_php@yahoo.com
Book: PHP Patterns
Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
Detestable (adjective): software that isn't testable.
-
Sep 12, 2005, 14:26 #23
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Overrunner
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; ?>
-
Sep 12, 2005, 14:29 #24
- Join Date
- Jul 2004
- Location
- Oklahoma
- Posts
- 119
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by sweatje
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.
-
Sep 12, 2005, 14:36 #25
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by sweatje
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