De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > 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. >
Yes, the spec expects portlets to generate 'user markup' to send to the client (your portlets are supposed to be portable between containers...) > 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. > This is technically possible since the spec mandates that the portlet render request and HTTP requests share attributes, so you can imagine a portle that only sets attribute and does not generate markup by itself but your portlet would be strongly tied to a specific container implementation. This goes against best practices IMO. > 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. > That's the more likely way to port current JS 1 Velocity based portlets to a JSR compliant one: have a JSR VelocityPortlet wrapper (or a JSR Jetspeed1Portlet wrapper for that matter) that generates the markup the way JS 1 would and return it to JS 2. > 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. > I would say the general idea is to send by default "user markup" but you could easily support the above model by defining container specific modes that can be supported by portlets... > 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. > This place is as good as any other, especially since you have people here that have been working with this spec for a few months now... -- Rapha�l Luta - [EMAIL PROTECTED] Jakarta Jetspeed - Enterprise Portal in Java http://jakarta.apache.org/jetspeed/ ********************************************** Vivendi Universal - HTTP://www.vivendiUniversal.com: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Vivendi Universal which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
