[jsr-314-open] Pre-JCP filed draft of JSF 2.2 JSR

Mon Feb 28 16:55:10 EST 2011

I also prefer to keep these specs separately, but they definitely have 
to be designed together. Currently, portlet spec followes a moving 
target and tries to resolve problems on their own.
I've started version 3.0 for jboss portlet bridge as well ( 
https://svn.jboss.org/repos/portletbridge/branches/3.0.X ), and there 
are some problems faced to date:
- JSF resources. Bridge spec requires ExternalContext#encodeResourceURL 
call to convert url's from the Servlet to Portlet format. Unfortunately, 
JSF renders resource URL's without call to that method, so they don't 
converted to the portal form. I tried to wrap all resources and encode 
url in modified getResourcePath method. To make things worse, resources 
passed as el-expression ( ${resource:...} ) sometime went to the 
encodeResourceUrl method, that makes harder to avoid double encoding there.
- ResponseStateManager.VIEW_STATE_PARAM should be namespaced, or, at 
least, converted to the configurable value similar to the clientId 
delimiter. Otherwise, client-side part updates state field for all JSF 
portlets on the page.
- JavaScript namespacing. To do that, javascript files should be 
processed for el-expressions substitution, same way as it done for 
stylesheets. standard jsf.js should use 
#{externalContext.encodeNamespace('jsf')} instead of direct names 
jsf.ajax and jsf.util.
- Portlet 2.0 ( JSR-286 ) introduces 2 types of render request. The 
first one going to render elements that included in the <head> element 
for the portal page, the second is for portlet page itself. I already 
suggested to implement similar functionality for JSF encode phase ( 
encodeHead and encodeBody ), to allow components add their dependencies 
to head 'on the fly'. The simplest way to aim that would be 'EncodeHead' 
system event fired by the <h:head> component.
- occational use for servlet classes. That's more for the implementation 
developers, but using '*Servlet*' classes in the framework should be 
PROHIBITED by spec. period. Any time, when direct access for servlet 
classes required, it should be considered as missing ExternalContext 
functionality.
 From the portlet bridge side, the new spec has to define how to 
implement new methods from the ExternslContext, how to process page 
parameters, what's Flash scope means for portlets, how to render portlet 
page, PartialViewContext requirements and so on.

On 02/28/2011 09:00 AM, Neil Griffin wrote:
> Hi Guys,
>
> I think keeping the JSF and Portlet Bridge JSRs separate is fine.
> Historically we've had good communication between the two, but for JSF
> 2.2 I think we need to combine that with tight coordination and scheduling.
>
> Best Regards to all,
>
> Neil
>
> On Feb 27, 2011, at 2:27 PM, Stephen Kenna wrote:
>
>> Thanks for the explanation Mike. I believe that 'remote components' is
>> a worthwhile goal to put into 2.2. I will inform our Portal/Portlet
>> Container team so we can get as many eyes looking at this new section
>> as possible.
>>
>> Kito,
>> Thanks for pulling in Neil and Wesley.
>>
>> I think it still makes sense to keep the JSF spec and the Portlet
>> bridge spec separate. I just think that we should make sure we
>> produce, at the very least, a MR for the bridge for any new content in
>> JSF that affects it. I also think a future bridge spec should have its
>> own version instead of using the current version of JSF and Portlet in
>> its title. Ed's inclusion of a JSF 1.2 bridge spec could be seen as
>> confusing.
>>
>>
>> Regards,
>> Stephen
>>
>> <Mail Attachment.gif>*
>> stephen kenna ibm websphere architecture & development*
>> websphere platform web tier lead architect and jsf eg member |
>> _address:_ 4205 s miami blvd, durham, nc 27703 | _office:_ m215/503_
>> email:_ kenna at us.ibm.com <mailto:kenna at us.ibm.com> | _phone:_ (919)
>> 543-5593 | _t/l:_ 441-5593 | _mobile:_ (919) 454-1231 | _fax:_ (919)
>> 254-5250
>>
>>
>> From: 	Kito Mann <kito.mann at virtua.com <mailto:kito.mann at virtua.com>>
>> To: 	jsr-314-open at jcp.org <mailto:jsr-314-open at jcp.org>
>> Cc: 	Neil Griffin <neil.griffin at tritonsvc.com
>> <mailto:neil.griffin at tritonsvc.com>>, Wesley Hales <whales at redhat.com
>> <mailto:whales at redhat.com>>
>> Date: 	02/25/2011 12:21 PM
>> Subject: 	Re: [jsr-314-open] Pre-JCP filed draft of JSF 2.2 JSR
>> Sent by: 	jsr-314-open-bounces at jcp.org
>> <mailto:jsr-314-open-bounces at jcp.org>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>>
>> SK> Also, do we need to open a new JSR for a JSF 2.x Portlet Bridge? I see
>> SK> you have referred to the existing JSR 329 which was written for
>> JSF 1.2.
>>
>> Personally, I think we do need to open up such a JSR, and having IBM's
>> support for such a JSR would be very helpful. However, what *I'm*
>> trying to establish is support for a new JSR for JSF. A portlet JSR is
>> another matter entirely.
>>
>> Opening a JSR for the Portlet 2.0 Bridge for JSF 2.0 is currently
>> being looked at. However, as JSF 2.0 has already been out for some
>> time, its currently felt we would better support the community by
>> publishing a stable, working implementation of such a bridge based on
>> logical extensions/migration of JSR 329 before getting into the thick
>> of the JSR process which tends to be more methodical. To that end
>> there is now a 3.0.x Trunk in svn of the Apache MyFaces PortletBridge
>> project (where the JSR RI work is):
>> _https://svn.apache.org/repos/asf/myfaces/portlet-bridge/core/trunk_3.0.x_.
>> This code is stable enough for an alpha release in that it passes the
>> upgraded version of the 329 TCK and runs the various Ajax and
>> CompositeComponent samples I could find on the web/in Mojarra. I will
>> be doing an official (alpha) release shortly once I have clearance.
>> But in the meantime, interested parties can build/use it directly from
>> this repository. FYI ... anyone wanting to do so may want to contact
>> me as I have found bugs in both Mojarra and MyFaces that prevent
>> proper execution in a portlet environment. I can suggest/provide
>> various patches to get around these problems.
>>
>> It's probably worthwhile bringing Wesley Hales (JBoss Portlet Bridge)
>> and Neil Griffin (portletfaces bridge) about this; I believe they both
>> support JSF 2 currently, but I'm not sure if they're using standard
>> extension points or not.
>>
>> Finally, since the question was asked here -- when proposed the Bridge
>> JSR a few years ago there was a discussion on whether it needed to be
>> separated from JSF or not. At the time we argued that it should be
>> because the nuances of the portlet environment needed the focus of
>> that community more than the JSF community. Now that the core of the
>> bridge have been defined, standardized, and proven to work in
>> practice, its useful to revisit this question. Given that the
>> underlying portlet spec is both stable and unlikely to change in the
>> near or medium future, it seems that the bridge is now pretty much
>> only tied to future JSF enhancements. Is it time to tie this work
>> closer to the JSF standards work? If so, what form do you think this
>> should take?
>>
>> Given how slowly this process moves, I think it probably makes sense
>> to keep them separate, personally. We never get through all of the
>> things we'd like to for JSF all by itself..
>>
>> -- Kito
>>
>> -Mike-
>>
>> Ed
>>
>>
>>
>