On Sep 22, 2006, at 4:23 AM, Georg von der Howen wrote:
Zend_Portlet would then consist of a portlet container and a portlet class, that is extended by 'real' portlets, right?
I'm envisioning more of a direct port of the API only. That is to say, Zend_Portlet would define a common set of interfaces that a portlet container (the host application) must implement in order to construct the helper objects that are passed to and from the individual portlets. It is up to the host application to figure out the implementation details of URL construction, authentication and authorization, preference storage, etc., which will vary widely based on individual needs.
There is an abstract base class that could be used for portlets themselves, but even this wouldn't be strictly required. A portlet is ultimately defined as an object which implements a small set of interfaces. This would mean that you could even turn existing classes into portlets without the need to completely re-implement the business logic.
On Sep 22, 2006, at 7:09 AM, Gregory Szorc wrote:
Portlets can be customized in so many different ways and there is so much one can do with a portlet... 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.
Your point is well taken. In fact, this is one reason why JSR-168 appealed to me over others that I looked at: it consists primarily of interfaces, not a bunch of overly-generic base classes. This affords both the portal and portlet developer great freedom with the actual implementation.
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.
I don't think you can have it both ways. :-) As you said, there really isn't a unified portlet API for PHP--this is what started my search in the first place. However, like everything else in the ZF, you could take Zend_Portlet or leave it.
On Sep 22, 2006, at 7:39 AM, Stefan Koopmanschap wrote:
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.
Isn't that what a framework is though: a collection of specific implementations? Your concern over whether this particular API is the right one for ZF is valid though. As Gregory pointed out, there aren't any standard portlet APIs for PHP (at least none that I could find). Do you know of any? Are there other portlet APIs for other languages that you'd recommend we look at?
On Sep 24, 2006, at 3:46 AM, Philippe Le Van wrote:
JSR-168 is very complex and very "java minded".
JSR: "Java" Specification Request ;-)
I believe a portlet framework in PHP should not be a copy of JSR-168. But JSR-168 includes a standard called WSRP for remote portlets calls. I believe a portlet framework in PHP should be much simpler than JSR-168 but should be compatible with WSRP.
After spending a few days with the API, I'm not sure I agree that it is complex--I would characterize it as "complete." There's an inherent complexity with portal/portlet development, which you alluded to in your message. If someone is going to take the plunge and develop a portal application they're going to have to deal with that complexity at some level. Better that it be documented in a standardized API than discovered as-you-go, IMHO. Which portions of JSR-168 do you feel should be pared down?
-- Willie Alberty, Owner Spenlen Media [EMAIL PROTECTED] http://www.spenlen.com/
