Re: [jsr-314-open] Archives ?
by Matthias Wessendorf
On Tue, Jan 12, 2010 at 8:35 PM, Ed Burns <Ed.Burns(a)sun.com> wrote:
>>>>>> On Tue, 12 Jan 2010 08:02:18 +0100, Matthias Wessendorf <matzew(a)apache.org> said:
>
> MW> sure, I like to be annoying when it comes to true openness :-)
>
> You don't say?
pardon? Not sure I get that.
>
> Also, I wonder what will happen to Oracle's continued advocacy of
> MyFaces once they own the Mojarra codebase.
I think the WLS ships both, MyFaces and RI/Mojarra
> Do you have any idea of
> what will happen there?
Nope. Currently we run on RI/Mojarra 2.0;
before we (ADF Faces) were running on RI/Mojarra 1.2
Once I get some time, I try to be executable on myfaces2 as well
(would be odd if the library only runs on Mojarra ;-) )
Other than that, I don't really care for ADF Faces point-of-view,
but that is my personal opinion; I am not able to speak for Oracle
on that.
Greetings,
Matthias
>
> Ed
>
> --
> | ed.burns(a)sun.com | office: 408 884 9519 OR x31640
> | homepage: | http://ridingthecrest.com/
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
14 years, 9 months
[jsr-314-open] PortletFaces Bridge
by Neil Griffin
Hi guys,
Just wanted to let you know that I'm working on a new open source project called the PortletFaces Bridge.
It's an implementation of the JSR 329 (Portlet 2.0 + JSF 1.2) Portlet Bridge API, except that it targets JSF 2.0 instead of JSF 1.2.
The code should be available in Alpha in a couple of weeks. When done, it will be downloadable from http://www.portletfaces.org
Best regards to all,
Neil
14 years, 9 months
Re: [jsr-314-open] [Behavior] Why is HtmlOutputText not a ClientBehaviorHolder ?
by Lincoln Baxter, III
Got it. I had guessed panelgroup would fill that role, but I didn't want to
influence the answer ;)
I don't see this as a gap if panelgroup implements clientbehaviorholder, but
for convenience, and consistency, I'd argue we should add this to
h:outputtext.
If performance is a concern (say, because of inline text being wrapped into
output text components on view construction), then the jsf impl should be
free to use a lightweight impl-specific component instead.
What are your performance concerns, if I have not inferred correctly?
Lincoln Baxter III
http://ocpsoft.com
http://scrumshark.com
Keep it simple.
On Jan 12, 2010 10:21 AM, "Matthias Wessendorf" <matzew(a)apache.org> wrote:
On Tue, Jan 12, 2010 at 4:02 PM, Andy Schwartz <andy.schwartz(a)oracle.com>
wrote: > Hey Lincoln - > >...
I think that using h:panelGrid is not perfect, but it is better than
abusing <label>.
-Matthias
> > Andy > >> >> The next question is: Do we need such a mechanism? That's,
for the most >> part, t...
-- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/sessions:
http://www.slidesh...
14 years, 9 months
Re: [jsr-314-open] [jsf2.next] <h:head> vs. <head>
by Neil Griffin
Once again, I'm reviving an older thread. So glad to be able to post again! :-)
When running in a portlet environment, it is forbidden for a JSF portlet to render tags like <head> and <body>. Tags like that are controlled by the portlet container, when aggregating portlet fragments into a complete HTML document.
So I think it would be better to have the page author to explicitly specify h:head and h:body. If they specify plain old <head> and <body> then the portlet container will likely strip them out. Currently, we can override the renderers for h:head and h:body in a portlet bridge in order to have them not render those tags.
Neil
On Dec 15, 2009, at 3:04 PM, Lincoln Baxter, III wrote:
> I'd even like to see it add <head> if not provided. Would that be too overreaching?
>
> Lincoln Baxter III
> http://ocpsoft.com
> http://scrumshark.com
> Keep it simple.
>
>
>> On Dec 15, 2009 1:02 PM, "David Geary" <clarity.training(a)gmail.com> wrote:
>>
>> 2009/12/15 Lincoln Baxter, III <lincolnbaxter(a)gmail.com>
>> > > It would be nice if it "just worked", and jsf would automatically add/detect he right place to l...
>>
>> +1. I always pitch h:head and h:body as necessary to coordinate with resource relocation from h:outputScript and h:outputStylesheet, but it would be great if you could just use <head> and <body> instead, and have everything work.
>>
>>
>> david
>> > > Lincoln Baxter III > http://ocpsoft.com > http://scrumshark.com > Keep it simple. >> >> On Dec 1...
>>
>>
>
14 years, 9 months
Re: [jsr-314-open] h:inputFile
by Neil Griffin
Hi Guys,
I'm reviving an older thread here, now that my ability to post is working again. :-)
While working on testing JSF 2.0 and the JSR 329 portlet bridge within Liferay Portal, I came up with a simple way to support file upload in JSF -- not only in a servlet environment, but in a portlet environment as well. It also handles the problem in which the FaceletViewHandler restoreView(FacesContext context, String viewId) method is unable to retrieve the javax.faces.ViewState request parameter for HTML forms with enctype="multipart/form-data"
For more info, see:
http://www.edorasframework.org/doc/1.3.0-SNAPSHOT/docbook/en-US/html/pf-f...
Here is the proposal I was going to send to the EG just before 2.0 was released -- BTW it does not depend on Servlet 3.0.
PROPOSAL:
Support the following use case:
<h:form enctype="multipart/form-data">
...
</h:form>
===== BEGIN SPEC ADDITION TO: javadocs/javax/faces/context/ExternalContext.html#getRequestParameterMap()
If the postback of the form is of enctype="multipart/form-data" then this method is responsible for saving any file(s) that may be present in the request. The files are saved on the server beneath a directory specified by the "javax.faces.UPLOADED_FILES_DIR" context initialization parameter. If the parameter is not present, then the "java.io.tmpdir" system property is consulted. After all of the files are saved, this method sets a request attribute named "javax.faces.UPLOADED_FILES" whose value is an immutable java.util.Map<String, java.io.File>. The map key is the request parameter name (clientId) and the map value shall be the uploaded java.io.File. It is the responsibility of the application developer to delete the files from the filesystem when they are no longer needed.
Servlet: In order to guarantee that multiple users can upload files with the same filename, the files shall be saved in a sub-folder whose name is the value of HttpSession.getId().
Portlet: In order to guarantee that multiple users can upload files with the same filename, the files shall be saved in a sub-folder whose name is the value of PortletSession.getId()
===== END SPEC ADDITION =====
Neil
On Dec 8, 2009, at 6:35 PM, Dan Allen wrote:
> On Tue, Dec 8, 2009 at 6:23 PM, Jim Driscoll <Jim.Driscoll(a)sun.com> wrote:
> I've filed:
>
> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=690
>
> Add h:inputFile component
>
> Yeah! It's almost like a rite of passage for JSF at this point ;)
>
> -Dan
>
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://www.google.com/profiles/dan.j.allen
14 years, 9 months
Re: [jsr-314-open] [Fwd: CDI and JSF Phase Listeners]
by Ed Burns
>>>>> On Fri, 08 Jan 2010 12:38:28 -0500, Dan Allen <dan.j.allen(a)gmail.com> said:
DA> In a way, this complements the EL resolver, which is already a nice
DA> mechanism for hooking into different component models.
PM> Is this too big for a mainatainance release?
I'm afraid so. It's new API so we cannot have it in 2.0 Rev a.
PM> Is this something we can prototype in MyFaces or Mojarra sooner?
I'm happy to point out that Mojarra has had this mechanism since May of
2006. Take a look at
<MOJARRA>/jsf-ri/src/com/sun/faces/spi/InjectionProvider.java.
>>>>> On Mon, 11 Jan 2010 13:41:48 -0500, Dan Allen <dan.j.allen(a)gmail.com> said:
DA> Should I file a spec issue?
If you'd be so kind, yes please.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 9 months
Re: [jsr-314-open] [Fwd: CDI and JSF Phase Listeners]
by Matthias Wessendorf
On Sun, Jan 10, 2010 at 3:39 PM, Pete Muir <pmuir(a)redhat.com> wrote:
>
> On 8 Jan 2010, at 17:38, Dan Allen wrote:
>
>> On Fri, Jan 8, 2010 at 11:30 AM, Roger Kitain <Roger.Kitain(a)sun.com> wrote:
>> It would be a nice feature to be able to have CDI injection in Phase
>> Listeners also, as any Servlet/JSF/CDI integration is always welcome
>> where applicable
>>
>>
>> This is actually a more general requirement (which we may have discussing in passing). Any user-defined class instance that JSF creates should be classified as a components in Java EE. But, to accommodate that without tying JSF directly to the platform (a separation we have always maintained), there should be a pluggable class instance resolver which could be satisfied with a CDI implementation, a Spring bean implementation, etc.
>
> I had initially thought we should just specify that JSF is required to support this injection, but I can see that specifying an SPI to support instantiation/lifecycle management of these objects would fit well with the pluggability goal that JSF has.
>
> Is this too big for a mainatainance release?
>
> Is this something we can prototype in MyFaces or Mojarra sooner?
sure thing! Do you mind to forward this to the dev(a)myfaces.apache.org list ?
-Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
14 years, 9 months
