[jsr-314-open] Extended EG request
by Andy Schwartz
Gang -
I would like to request that we provide my colleague Blake Sullivan with
write access to the jsr-314-open list. Blake is the lead architect for
ADF Faces, has been involved in user interface technologies for roughly
20 years, and has been closely following JSF spec development/discussion
(on our internal mirror lists) since the earliest days of JSF 1. I
don't think that there has been an issue that I have been involved in on
314 that I haven't discussed with Blake. I am certain that he would
provide positive contributions to our discussions.
Thoughts?
Andy
14 years, 9 months
Re: [jsr-314-open] [jsf2next] PROJECT_STAGE system property configuration
by Ed Burns
>>>>> On Tue, 05 Jan 2010 21:15:53 -0800, Cay Horstmann <cay(a)horstmann.com> said:
CH> Still, this points to the fact that the default for the project stage is
CH> probably wrong.
Let's take a step back and look at my motivation for wanting to have the
default be "Development". One of the biggest classes of gripes about
JSF is the "JSF's error messages suck, if you get them at all" kind of
gripe. We need to make the out of the box experience address those
kinds of gripes directly.
I continue to feel the same way, so I do not support changing the
default value.
Also, yes, I'm fine with a system property to set the ProjectStage, but
am against making it runtime mutable.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 9 months
Re: [jsr-314-open] Problem with Resource.getRequestPath() in a portlet environment
by Lincoln Baxter, III
Sorry. Hard to type on the phone. I was speaking specifically about
externalcontext.getrequestpath()
The resource.getrequestpath() method states no such requirement. It may be
an oversight.
Lincoln Baxter III
http://ocpsoft.com
http://scrumshark.com
Keep it simple.
On Jan 13, 2010 12:51 PM, "Neil Griffin" <neil.griffin(a)portletfaces.org>
wrote:
Thanks Lincoln. Well if that's indeed the case, then I guess that means
there are some bugs in Mojarra. For
example, StyleSheetRenderer.encodeEnd(FacesContext, UIComponent) should call
ExternalContext.encodeResourceURL() before it outputs the <link> tag.
Anyone from the Mojarra team agree/disagree?
Neil
On Jan 13, 2010, at 12:43 PM, Lincoln Baxter, III wrote: > I believe it is
your responsibility, s...
14 years, 9 months
Re: [jsr-314-open] finding spec issues
by Ed Burns
>>>>> On Tue, 12 Jan 2010 09:39:20 +0100, Ganesh <ganesh(a)j4fry.org> said:
G> Hi,
G> Clicking on:
G> "Issues the EG intends to address for JSF 2.next"
G> on:
G> https://javaserverfaces-spec-public.dev.java.net/
G> yields:
G> "Your query returned no results. Please refine your query and try again"
G> which is due to the fact that the link contains:
G> target_milestone=2.next
G> Setting target milestone to 2.0a yields 1 issue (266),
G> which seems scarce to me.
First, please note that 2.0 Rev a is a revision, not an update. We
choose to only make trivial changes in a revision but instead use an
actual spec version update, that is 2.1, for larger changes. I know
it's confusing but both 2.0 Rev a and 2.1 must be conducted through the
JCP Maintenance Release program.
Thanks for pointing out the error in the query. This is probably why
Ryan avoided having these handy queries on the mojarra page: you have to
maintain them! I have updated the links. The "2.0 Rev a" link now
returns 16, and the unscheduled link now returns "204"
We are still in the midst of targeting our issues. Because there is
currently no searchable archive of messages, I'll re-post my request for
issue captains here.
>>>>> On Fri, 11 Dec 2009 12:13:42 -0800, Ed Burns <ed.burns(a)sun.com> said:
EB> Back in August of 2008 [1] we did an issue prioritizing exercise which
EB> involved nominating seven "Issue Captains" to be responsible for
EB> understanding a certain subset of the issues.
EB> At Jim Driscoll's suggestion, I recently re-worked the sub-components in
EB> our issue tracker of record and now they make sense. I am hereby asking
EB> for some more issue captains to take the issues in this query [2] and
EB> assign the proper sub-component. Let's leave the priority field for
EB> another time, but you can set it if you want.
EB> The isssue captains the last time [3] were:
>> Issue Captain Issues
>> ====================
>>
>> Ed Burns
>> Roger Kitain
>> Jim Driscoll
>> Ryan Lubke
>> Mike Friedman
>> Pete Muir
>> Kito Mann
EB> [2] has 253 issues, which means about 36 each.
EB> The work would need to be done in time for the EG meeting I'd like to
EB> have somewhere in the first two weeks of January. I'll send another
EB> mail about that.
EB> Thank you very much.
EB> Ed
EB> [1] http://archives.java.sun.com/cgi-bin/wa?A2=ind0808&L=JSR-314-EG&P=R8119&X...
EB> [3] http://archives.java.sun.com/cgi-bin/wa?A2=ind0808&L=JSR-314-EG&P=R11290&...
G> Also, I'm unable to find the issue Matthias mailed through query:
G> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=720
G> though it has target_milestone=2.0 Rev a
I fixed that.
G> Am I missing something essential?
G> How do you keep track of the scheduled issues?
You're in the right place, I just didn't have the system updated.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 9 months
Re: [jsr-314-open] [Behavior] Why is HtmlOutputText not a ClientBehaviorHolder ?
by Ed Burns
>>>>> On Tue, 12 Jan 2010 21:15:04 +0100, Matthias Wessendorf <matzew(a)apache.org> said:
MW> On Tue, Jan 12, 2010 at 9:07 PM, Ed Burns <Ed.Burns(a)sun.com> wrote:
>>>>>>> On Tue, 12 Jan 2010 11:03:34 -0500, Andy Schwartz <andy.g.schwartz(a)gmail.com> said:
>>
AS> So strange. Matthias and Lincoln's responses didn't make it to my
AS> Oracle account, but did make it to gmail. Apparently I've got some
AS> mail delivery issues here. Yay.
>>
AS> On Tue, Jan 12, 2010 at 10:45 AM, Lincoln Baxter, III
AS> <lincolnbaxter(a)gmail.com> wrote:
>>>>
>>>> What are your performance concerns, if I have not inferred correctly?
>>>>
>>
AS> My concern is that there will be increased overhead during
AS> h:outputText rendering due to an increased # of attribute lookups It
AS> is possible that overhead is nominal, but not sure. The use case
AS> where this overhead would be most noticeable would be the stamping
AS> case, where we may end up stamping out h:outputText components many
AS> times (once per row/column of a data table).
>>
>> I agree with Andy. I oppose doing anything to h:outputText until we
>> have some concrete performance numbers on the impact of the proposed
>> change. Also, I feel the benefit to the user of doing this change is
>> marginal at best.
MW> I totally understand that. For me (personal requirement) the Trinidad2
MW> <tr:outputText>
MW> is all I need and making a custom (or extensional) outputText
MW> ClientBehaviorHolder
MW> is pretty trivial :-)
MW> So, I think we can close the ticket as h:outputText was never having "DOM apis"
MW> and adding them could be worse for performance; Do you want me to close it ?
Yes please.
Ed
14 years, 9 months
[jsr-314-open] [690-inputFile] (was: re: h:inputFile)
by Ed Burns
>>>>> On Tue, 12 Jan 2010 10:35:12 -0500, Neil Griffin <neil.griffin(a)portletfaces.org> said:
NG> Hi Guys,
NG> I'm reviving an older thread here, now that my ability to post is working again. :-)
I see that you posted something very similar to this proposal to issue
690. Is there any difference between this email and the one in the
issue?
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 9 months
Re: [jsr-314-open] [Behavior] Why is HtmlOutputText not a ClientBehaviorHolder ?
by Ed Burns
>>>>> On Tue, 12 Jan 2010 11:03:34 -0500, Andy Schwartz <andy.g.schwartz(a)gmail.com> said:
AS> So strange. Matthias and Lincoln's responses didn't make it to my
AS> Oracle account, but did make it to gmail. Apparently I've got some
AS> mail delivery issues here. Yay.
AS> On Tue, Jan 12, 2010 at 10:45 AM, Lincoln Baxter, III
AS> <lincolnbaxter(a)gmail.com> wrote:
>>
>> What are your performance concerns, if I have not inferred correctly?
>>
AS> My concern is that there will be increased overhead during
AS> h:outputText rendering due to an increased # of attribute lookups. It
AS> is possible that overhead is nominal, but not sure. The use case
AS> where this overhead would be most noticeable would be the stamping
AS> case, where we may end up stamping out h:outputText components many
AS> times (once per row/column of a data table).
I agree with Andy. I oppose doing anything to h:outputText until we
have some concrete performance numbers on the impact of the proposed
change. Also, I feel the benefit to the user of doing this change is
marginal at best.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 9 months
[jsr-314-open] [468-relocationTarget] REQUIREMENT (was: Re: [jsf2.next] <h:head> vs. <head>)
by Ed Burns
>>>>> On Tue, 12 Jan 2010 10:37:03 -0500, Neil Griffin <neil.griffin(a)portletfaces.org> said:
NG> Once again, I'm reviving an older thread. So glad to be able to post
NG> again! :-) When running in a portlet environment, it is forbidden
NG> for a JSF portlet to render tags like <head> and <body>. Tags like
NG> that are controlled by the portlet container, when aggregating
NG> portlet fragments into a complete HTML document.
NG> So I think it would be better to have the page author to explicitly
NG> specify h:head and h:body. If they specify plain old <head> and
NG> <body> then the portlet container will likely strip them
NG> out. Currently, we can override the renderers for h:head and h:body
NG> in a portlet bridge in order to have them not render those tags.
Spec issue 468 is this exactly. Because this is a request for a
component (actually a new renderer type, I think), I'd love to assign
issue 468 to someone on this list, get them to write the component, and
share it with the group.
Any takers?
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 9 months
Re: [jsr-314-open] Archives ?
by Ed Burns
>>>>> On Tue, 12 Jan 2010 11:09:12 -0500, Andy Schwartz <andy.schwartz(a)oracle.com> said:
AS> Not sure that it matters, but a personal reason that I have for wanting
AS> this addressed soon is that I seem to be having jsr-314-open mail
AS> delivery problems here. If the archives were available, I could easily
AS> find out what I have missed. Not having these available is, well,
AS> frustrating.
AS> Of course, there are more important reasons for addressing this problem
AS> quickly, but figured I would share my personal pain while we were on the
AS> topic. :-)
Yes, the archives are absolutely vital and once were my sole reason for
sticking with the @jcp.org mailing lists when the vogue was to use
java.net. However now it seems that both java.net and jcp.org are
having either IT or process trouble!
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 9 months
