On 9/22/06, Gregory Szorc <[EMAIL PROTECTED]> wrote:
It is hard again to get on one line with this, I think. Obviously, it is not good for the framework if there are base classes there that only contain getters and setters. It is a shame that PHP does not yet really have the API standards system such as Java has, else it would be easy: ZF would, or would not, implement such standard APIs.
Note that I have not looked at the mentioned standard, but I do think that implementing such an API inside the ZF would be a good thing. Especially when following a standard. It may not be used by everyone, but it's there. That's the same as with all components of the framework.
On the other hand, it's very hard to take up one specific implementation into a framework when there are so many others out there to be considered. I do think, for that reason, that it would be wise to take a long period of consideration, and research as much standards/APIs as possible before deciding which to implement. Or maybe end up concluding not to implement it for exactly the reasons given by you, and above in my response. Concluding: I do like the idea of a Portlet API in the framework, but I think we need a lot of research and maybe one or two proposals before finally discarding the idea. Of course, that's just my 2 cents.
But you're not restricting ZF users at all. They can always make the decision to write their own module for this functionality. It's not my position to decide on this, but I can voice my opinion, and my opinion is that (good) support for at least one standard is better than no support at all.
-- Portlets can be customized in so many different ways and there is so much one can do with a portlet. I don't see how anybody can abstract portlets to a level desirable for a framework. Of course, JSR-168 is a standard, so it carries some credibility. Yet, to implement it properly, you still need a base portlet class with JSR-168 extending it. After examing all the portlet API's out there, you'll probably end up with a base portlet class that simply consists of set and get content methods.
It is hard again to get on one line with this, I think. Obviously, it is not good for the framework if there are base classes there that only contain getters and setters. It is a shame that PHP does not yet really have the API standards system such as Java has, else it would be easy: ZF would, or would not, implement such standard APIs.
Note that I have not looked at the mentioned standard, but I do think that implementing such an API inside the ZF would be a good thing. Especially when following a standard. It may not be used by everyone, but it's there. That's the same as with all components of the framework.
On the other hand, it's very hard to take up one specific implementation into a framework when there are so many others out there to be considered. I do think, for that reason, that it would be wise to take a long period of consideration, and research as much standards/APIs as possible before deciding which to implement. Or maybe end up concluding not to implement it for exactly the reasons given by you, and above in my response. Concluding: I do like the idea of a Portlet API in the framework, but I think we need a lot of research and maybe one or two proposals before finally discarding the idea. Of course, that's just my 2 cents.
On one side, by implementing support for JSR-168, you create a unified portlet API for PHP developers everywhere (something I don't believe exists or at least isn't mainstream). On the other, you may be unfairly restricting ZF users to conform to this particular standard when there are others widely used in practice. Is it ZF's role to push one over the other? I don't know if I am in a position to answer that.
But you're not restricting ZF users at all. They can always make the decision to write their own module for this functionality. It's not my position to decide on this, but I can voice my opinion, and my opinion is that (good) support for at least one standard is better than no support at all.
Stefan Koopmanschap
http://www.stefankoopmanschap.nl/
http://www.leftontheweb.com/
