myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Marinschek (JIRA)" <...@myfaces.apache.org>
Subject [jira] Commented: (MYFACES-434) MyFaces's Portlet enhancement
Date Wed, 12 Mar 2008 00:04:47 GMT

    [ https://issues.apache.org/jira/browse/MYFACES-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577655#action_12577655
] 

Martin Marinschek commented on MYFACES-434:
-------------------------------------------

Hi Shinsuke, others,

excuse my long silence - it was mostly due to the fact that I found it hard to fully understand
what happened in your bridge, Shinsuke - the code is not very easy comprehensible, especially
the javascript-rendering-part. I should have discussed more with you guys, but here I am with
a different solution which replaces the DefaultAddResource-implementation of MyFaces with
one that does not do buffering. 

Additionally, the extensions-filter is not necessary anymore in a servlet-world - instead,
a FacesContextFactory-wrapper and a phase-listener take over. In the portlet-world, the extensions-filter
should still be configured in the main web.xml of the portal, it will then serve out resources
(use the filter-mapping from before).

With this, a few things won't work in the portlet world, but most things will do.

However, there is still two issues with my proposed solution:

- I can only get it to work with JSF 1.1 _or_ JSF 1.2, but not in both. This is as I need
to wrap the FacesContext, and I cannot use the interface of the JSF 1.2 FacesContext in the
Tomahawk-1.1 version. However, in a 1.2 environment, the method getELContext() will be called
on the FacesContext; and this method is only available in the 1.2 interface. This really means
there should have been a FacesContextWrapper fro the beginning in the javax.api.*-classes,
then this wouldn't be a problem at all. Does anyone have a suggestion?
- I haven't so far taken care of file-upload - should be easy, however. The question is where
the init-parameters should come frome now that the filter can safely be removed. Should we
maybe read the init-parameters from the filter still, so that the users can keep their configuration?

regards,

Martin

> MyFaces's Portlet enhancement
> -----------------------------
>
>                 Key: MYFACES-434
>                 URL: https://issues.apache.org/jira/browse/MYFACES-434
>             Project: MyFaces Core
>          Issue Type: Improvement
>          Components: Portlet_Support
>    Affects Versions: 1.1.0
>         Environment: LInux, J2SE 1.4.2
>            Reporter: Shinsuke SUGAYA
>            Assignee: Martin Marinschek
>         Attachments: PortletEnableTomahawk.patch, Tomahawk_FileUpload_IBMPortal.zip
>
>
> MyFacesGenericPortlet does not fully support the feature of tomahawk component, such
as inputHtml and fileUpload. So, I request the following feature to run it on portlet:
> - support tags in <head> (ex. inputHtml component)
> - support upload (fileUpload component)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message