I think people will expect to be able to send fully-rendered content to the container from their portlets. However, there could be special portlets that generate XML, populate a context or whatever that allows a transform /rendering phase to happen at the container as opposed to at the portlet. I think this "late rendering" approach could be implemented within Jetspeed 2's valve architecture. These portlets would have to implement a special interface or send a signal to the container that they require rendering support at that level.
However, this would be a non-spec enhancement, so portlets that used this rendering approach would only be useable in containers/portals that supported late rendering. That being said, I think this is a good idea but not something we need to implement immediately. *===================================* * Scott T Weaver������������������� * * Jakarta Jetspeed Portal Project�� * * [EMAIL PROTECTED] * *===================================* � > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Friday, July 25, 2003 11:46 AM > To: [EMAIL PROTECTED] > Subject: JSR-168 Questions > > I spent part of the week reading the JSR-168 spec. (Yes, the WHOLE thing. > The HD in my PC crashed so I had some time to kill waiting for a > replacement. Anyway...) > > The spec continually mentions that the portlet generates "markup". > Examples > given are HTML, XHTML, and WML. Jetspeed currently seems to favor > Velocity > for portlet creation. In Jetspeed's current model, the portlet Java class > populates the context and then Velocity is used to integrate the context > variables with markup (HTML). > > I see a few ways Velocity could continue to be used in JSR-168's new > paradigm: > 1. The portlet generates no markup and continues to just populate the > context and other variables. The portlet container then runs the Velocity > macro generating the final markup. In this case, the portal receives the > expected final markup and displays it. This may violate the > portlet->container interface outlined in the spec; I believe portlets are > expected to return markup to the container. > > 2. Almost like the above, except in this case the Portal applies the final > Velocity macro. i.e. the portlets actually generate no markup, but the > container passes all the context info to the portal. This seems to be a > violation of the portlet spec contract. > > 3. A special JSR-168 Velocity Portlet is used which runs the Velocity > code. > One of the parameters for the portlet is the Velocity macro to run. The > portlet populates the context, then applies the Velocity, then returns the > markup to the container and on up to the Portal. > > Another thing I noticed in the spec. It never says the markup returned by > the portlet is what is finally to be delivered to the client. So, I could > see portlets designed to return some form of XML which the Container or > Portal then applies a final transformation on before delivering to the > client. I think this would be very analogous to calling a SOAP service or > servlet and then applying XSLT to generate HTML. Seems a bit round-a- > bout, > I think the whole idea behind the portlet spec is to have the portlets > generate what will be displayed on the client. > > Am I saying anything interesting here? Having just plowed through the > spec > I'm trying to let thoughts swirl around and gel into understanding. > > Is there a good public place where JSR-168 is being discussed? I didn't > find any discussion in the Usenet newsgroups via Google. The jsr-168 > comments email address is nice, but the comments just go into a black hole > for the the committee to discuss, not those of us on the outside. > > - Jasen. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
