A quick survey: PHP portlet and portal
November 5th, 2007I wonder, is it a good idea to create a PHP implementation of the JSR 286 - Portlet 2.0 specification?
The questions I want to ask:
1. Do you know about portal/portlet technology?
2. Do you like it?
3. Is it a cool idea to create a PHP analog of javax.portlet?
4. Do you want to participate in such project?
5. Will you use it in your projects?
Tags: 
PHP Portlet API
Hi!
Liberic(tm) http://www.liberic.com/ it's an spanish company that has started the development of the PHP Portlet API: This project aims to define a portlet standard for the PHP language. It's inspired by the Java JSR-168 specification
You can visit the project web site at http://sourceforge.net/projects/phpportlet
Liberic(tm) it's open to join to any PHP standarization and specification initiative.
JSR 168/286
It's not clear if you mean that you want a solution that performs aggregation of multiple web outputs that are backed by different code, or you want something that accomplishes this using an architecture similar to the Java portlet spec.
It's likely that in the PHP market, solutions will be designed specifically for each respective framework. You might want to look at the Zend Framework Layout component currently under development:
http://framework.zend.com/wiki/display/ZFPROP/Zend_Layout
I have used Apache Jetspeed and Liferay portal servers. I did not like them -- they were complicated to use, and tend to be unstable and hard to manage. My conclusion is that they have overhead that far outweighs their benefits. Though I admit I haven't touched them in about 2 years, so perhaps they have matured by now. Sun also seems to have a reference Portal Server now, but I haven't tried it.
The Java portlets architecture works with Java application servers, with the assumption that both the container (portal) and the portlet code are persistent and initialization is done once as the portal container starts, and portlets are deployed. Subsequently, portlets can communicate with the container and with other portlets, change their state according to requests, and render their output.
However, PHP has its "share nothing" architecture which has its own advantages, but it means code does not persist between requests. PHP developers are very sensitive to the impact of initialization overhead, so the code to set up the portal/portlet environment on each request may be a burden.
We may also assume that the concept of portlets has to accommodate the way AJAX has changed the modern web interaction model.
My thoughts
Bill,
Thank you for your comment! Here are my comments and thoughts:
> It's not clear if you mean that you want a solution that
> performs aggregation of multiple web outputs that are
> backed by different code, or you want something that
> accomplishes this using an architecture similar to
> the Java portlet spec.
I want to write a system (with PHP) which will be able to host
micro-apps (or portlets, or something like Drupal blocks)
and these apps can be shared between other systems which
implement the same set of interfaces (similar to javax.portlet).
The concept behind it grown from my work with Zend Framework
MVC. Zend MVC just great for creating applications, but it
provides very low-level API. So I want to bring it on some higher
level and work on decompose a whole application on reusable blocks.
> It's likely that in the PHP market, solutions will be designed
> specifically for each respective framework. You might want to
> look at the Zend Framework Layout component currently under
> development:
> http://framework.zend.com/wiki/display/ZFPROP/Zend_Layout
Yes. I plan to use Zend_Layout as well as other Zend Framework
components (Db, Controller, Acl, Auth) and so on. I think that
the portal (portlet container) can be built on the top of Zend
Framework and it can wrap Zend_Controller Request/Response
classes to provide the particular portlet with only its
parameters.
> I have used Apache Jetspeed and Liferay portal servers. I
> did not like them -- they were complicated to use, and
> tend to be unstable and hard to manage.
Unfortunately, I have not a lot of expirience with portals.
Honestly, I'm a quite new in the subject but I like and
understand (I hope) the general concepts on how to host
portlets in one portal and reuse them in other portals.
> The Java portlets architecture works with Java application
> servers, with the assumption that both the container
> (portal) and the portlet code are persistent and
> initialization is done once as the portal container
> starts, and portlets are deployed. Subsequently, portlets
> can communicate with the container and with other
> portlets, change their state according to requests,
> and render their output.
This is exactly how I understand it.
> However, PHP has its "share nothing" architecture
> which has its own advantages, but it means code does
> not persist between requests. PHP developers are
> very sensitive to the impact of initialization
> overhead, so the code to set up the portal/portlet
> environment on each request may be a burden.
Yes, but my tests shows that the setting up the
environment for one portlet adds the same
ammount of time (or comparable with) the Zend
Framework Controller adds.
It is similar to WidgetHelperPlugin (or something so)
I've seen in Zend Framework mailing list a few months
ago. It calls another Controller/Action and inserts its
output into the current view. I consider that portlet
rendering may be similar but even lighet because does not
require routing. May I suggest you to look at portlet as
like it some specific guideline for creating application
Controllers assuming that one controller represents the
portlet.
> We may also assume that the concept of portlets has
> to accommodate the way AJAX has changed the modern
> web interaction model.
Yes, this is a good challenge and I've thought about it.
I have some expirience with netvibes and iGoogle Ajax
widgets and hope it will help me with that.
Huh... Anyway, nice topic to discuss, isn't it? :-)
It is a great idea
I have been thinking on this long time ago (even before ZF). I'm working in a CMS.. like you said, a high level framework to create Vendor_Modules that would load Vendor_Modules_Controllers and so on (learned a lot form Paul M Jones - Solar Framework)
I love the idea of the portlets, that define an interface to work just like .Net webparts. The CMS should be able to create n pages that use the "Nested Set Model" for the website content tree (see http://dev.mysql.com/tech-resources/articles/hierarchical-data.html). Each page could add this "boxes". The very first one is FckEditor box, and so on...
I think this is the way to make a CMS very extensible and very flexible for vendors and for end users.
Tell me what you think about it.
i like the idea
As a Java Developer, I think having Something like Portlet for PHP is a great idea. I have created an mvc framework "bubuface" ( http://mvc.bubuface.com ) for PHP.
Portlets have more features like View/Edit/Help modes, window states and so on that would make life easier for people who want to write PHP portal webpages.
I am implementing an API in PHP mirroring Java Portlets.