[jsr-314-open-mirror] [jsr-314-open] Use a Renderer on a composite component
by Leonardo Uribe
Hi
The javadoc of Application.createComponent(FacesContext context, Resource
componentResource) says this:
".....Call UIComponent.setRendererType(java.lang.String)<file:///D:/jdk-1_5_0-doc/jsf20/mojarra-2.0.3-SNAPSHOT/docs/javadocs/javax/faces/component/UIComponent.html#setRendererType%28java.lang.String%29>on
the
UIComponent instance, passing "javax.faces.Composite" as the
argument........"
Now suppose a custom composite component extending from UIInput, but
implementing NamingContainer/UniqueIdVendor. The component family in this
case is "javax.faces.Input". The result is the component will not work
because the renderer used for composite components assumes the family
"javax.faces.NamingContainer". This is ok, because the user just need to
register a custom renderer for its composite component under that
family/rendererType like the spec says.
The problem is why it is mandatory to set "javax.faces.Composite" as
renderer type. The javadoc should say:
"...If the renderer type is not set (return null), Call
UIComponent.setRendererType(java.lang.String)<file:///D:/jdk-1_5_0-doc/jsf20/mojarra-2.0.3-SNAPSHOT/docs/javadocs/javax/faces/component/UIComponent.html#setRendererType%28java.lang.String%29>on
the
UIComponent instance, passing "javax.faces.Composite" as the argument...".
In that case, a user can override the rendererType on the constructor and
avoid this hack that works with the current spec:
public void setRendererType(String rendererType)
{
//Ignore this call !
if (!"javax.faces.Composite".equals(rendererType))
{
super.setRendererType(rendererType);
}
}
Why override the default Renderer and use a custom one? Let's suppose the
component proposed needs some custom code for converter, or for decode. The
right place to put that kind of code is the Renderer class, not the
component, but note it is possible to put that on the component class.
Does that sounds reasonable? should I create an issue for this one?
regards,
Leonardo Uribe
14 years, 9 months
Re: [jsr-314-open-mirror] [jsr-314-open] Enabling easier hotplugging
by Ed Burns
>>>>> On Tue, 23 Mar 2010 20:51:53 +0100, Werner Punz <werner.punz(a)gmail.com> said:
WP> Btw. my personal opinion regarding all this is that this should be
WP> solved in a special spec which frameworks can attach to. After all
WP> the entire configuration change aspect is not only JSF specific but
WP> goes way depper into every framework.
WP> But I guess someone has to do the first step before an umbrella jsr
WP> spanning all JEE frameworks is opened :-)
Yes, that's certainly true. In fact, there's a time honored tradition
of JSF being an important place where innovation enters the platform.
This is a very thorough proposal, Werner. Thanks for preparing it.
I'd like to see this API done in terms of existing APIS, such as the
java.lang.management MBeans [1]. Is it possible we can use JMX rather
than introducing a new API?
Ed
[1] http://java.sun.com/j2se/1.5.0/docs/guide/management/overview.html#mbeans
--
| edward.burns(a)oracle.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 9 months
Re: [jsr-314-open-mirror] [jsr-314-open] Enabling easier hotplugging
by Werner Punz
Ok guys I posted an initial proposal in issue
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=774
you also can download the proposal directly from
http://people.apache.org/~werpu/Proposal%20Configuration.pdf
It is just a proposal for 2 extension points first an extension point which
gives read and write access to the configuration
(although it is up to the implementation whether the right access is granted
and in which state of the application)
Secondly system events all extensions and also the implementation must use
as extension point
to get configuration write and read behavior in. This notification system
uses the existing system events to perform that
but more details in the PDF.
Btw. can someone please close
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=7...
I cannot do it, it is oviously now covered by the proposal and the
unload itself is part of a connecting extension framework or the respective
implementation.
Werner
On Tue, Mar 16, 2010 at 8:49 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
> On Tue, Mar 16, 2010 at 12:07 PM, Martin Marinschek <
> mmarinschek(a)apache.org> wrote:
>
>> Hi guys,
>>
>> just so that I can add my 2cents as well: I believe it would be a
>> valuable addition to JSF if we had some standardized hooks into the
>> configuration management - that was really missing from the beginning.
>>
>> I believe it was also discussed from early on, but always delayed to a
>> later version.
>>
>
> That later version needs to be JSF 2.1. Time to make it happen :)
>
> -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
[jsr-314-open-mirror] [jsr-314-open] Tradmark text added as footer to all pages on javaserverfaces.org
by Ed Burns
Per request from Oracle, I have added the following trademark assertion
to the bottom of every page on javaserverfaces.org.
"Java and JavaServer Faces are trademarks or registered trademarks of
Oracle and/or its affiliates."
For consistency with the first page, I have also added this text below
the trademark assertion. On the first page, this text was already
present:
"http://www.javaserverfaces.org is maintained and operated by members of
the JSR-314 (JSF 2.0) Expert Group and dedicated community contributors.
Got a suggestion to make javaserverfaces.org better? Is there a page we
forgot? Please post your suggestion in the community forums."
Per the informal governance agreement reached at the November
2009 EG meeting, because this changes is not a substantive change, I
took the liberty of making the change without first notifying the EG.
Ed
--
| edward.burns(a)oracle.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 9 months
Re: [jsr-314-open-mirror] [jsr-314-open] This mailinglist is horribly broken and we must migrate it
by Ed Burns
I spoke with Max Lanfranconi today and he shared that the root cause of
all of our problems with our mailing lists is a shortage of human
resources. As the only full time Oracle person that is officially
entirely devoted to the JSF spec and implementation (Roger and Ryan
officially have other responsibilities), I understand how this feels.
He enumerated the items in their queue and our issues will be the first
to be resolved. I will continue with my plan to have a conversation
with Eduardo Pellegri-LLopart about this next week.
SECTION: ACTIONS TAKEN
The following actions have been taken right now to address the problem
Dan has been raising and continues to raise.
1. Audit of existing LISTSERV jsr-314-open web interface subscriptions
resulted in a few-additions to the mailman jsr-314-open list (the actual
one that processes the list). It should be current now.
2. I have edited my blog entry that introduced the jsr-314-open list
http://weblogs.java.net/blog/2009/03/04/response-call-fix-jcp-oberver-status
and removed the links to the LISTSERV web interface.
3. I have posted a new blog entry describing the interim process for
subscribing/unsubscribing.
http://www.java.net/blog/edburns/archive/2010/03/19/new-process-subscribi...
SECTION: ACTIONS PROPOSED
The following actions have not yet been taken, but I propose we take
them.
1. I propose the following trivial changes to the javaserverfaces.org
front page.
* "Key Links" area retitled as "Key Links and Information"
* In the "Key Links and Information" section, delete the bullet item starting
with "Expert Group (EG) Mailinglist & Archives".
* In its place add the following text
"To subscribe (read-only) to the official Expert Group (EG) mailing
list on which the development of the JSR-314 Specification (JSF 2.0)
is discussed, send an email to list-request(a)jcp.org with "SUBSCRIBE
JSR-314-OPEN" in the subject line."
This is just an alias that forwards to max(a)jcp.org. This is an
interim solution.
* Add a bullet below the previous one.
Those wishing to earn posting permission to jsr-314-open must join the
[Extended Expert Group|link to javaserverfaces.org's expert group
page.] The best way to join is to make yourself known to one of the
existing EG members who can petition the EG for you to be added as an
Extended EG member. In general, you'll need a good reason for being
accepted to the Extended EG. Having lots of experience with and
passion for JSF certainly helps.
2. Take down the LISTSERV web interface for jsr-314-open(a)jcp.org. The
only value the web interface has is to enable searching the
jsr-314-open(a)jcp.org mailing list BUT ONLY FOR CONTENT BETWEEN LIST
CREATION AND JUNE 2010! I think that this is of little value and
only confuses things.
3. Someone has to figure out how we can import all the
jsr-314-open(a)jcp.org emails from list creation until now into an
external list tracker, such as gmane. I estimate I have about 90% of
the emails ever sent to jsr-314-open(a)jcp.org in my archive. Can I
somehow insert them into a gmane list mirror, and then subscribe the
mirror to jsr-314-open?
ACTION: Please voice any concerns with these proposed actions by noon
PDT Monday 22 March 2010.
Thanks,
Ed
--
| edward.burns(a)oracle.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 9 months
