Re: [jsr-314-open] Evaluating EL in resource files
by Werner Punz
On Thu, Sep 24, 2009 at 11:31 PM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
> Hmm... I suppose I've been considering it from the other angle.
>
> Resources allow abstraction between physical location and URI. Just so I've
> got this straight: We are talking about things like .css files, .js files,
> and images when we say 'resources', right?
>
> If so, I still feel as if automatically supplying browser cache headers is
> un-intuitive. How long is the default cache-expiry? What if I want to change
> that? Where do I start? Is this something people are used to having done for
> them?
>
> I think this is less an implementation more a documentation issue since all
the apis are there
to write a custom resource handler and it is no rocket science doing it.
So it comes down to, if you want the defaults use what is given if you need
special more fine grained control write your own resource handler, that way
you can influence cache eviction times etc...
As for people are used to having done for them. I can only speak from a
Weblets point of view. We provide basic defaults which are cache on afair,
but we have configuration options for cache-timeouts and anything beyound
that needs a custom Weblet.
For enforcing version updates without having even to tamper with timeout
times, we have the version numbers which are part of the url. (Same as JSF
which however does it on resource level not on bundle level), which is a
cleaner resource update mechanism than tampering with cache control times,
because it gives you a clean timed interception point for enforcing an
update in a browser neutral way!
I have yet to say I am not sure if I have used the timeout option so far,
except for turning off the cache explicitely, but there are corner cases,
where you want to provide it. Probably most cases would have been covered
with cache-off and cache-on + version numbers.
One of the reasons for using a resource library simply is that you dont have
to wrap your brain around anymore about the various pitfalls of cache
control, regarding the various browser versions and have the library doing
it for you.
I would not want to use a resource library without this option and sane
defaults doing the heavy lifting for me.
Anyway I think this discussion gets a little bit off topic ;-), wasnt it
about how to apply the el to javascripts originally?
Werner
If someone wants to serve resources from a Database, they need to write a
> custom ResourceHandler, in which case they won't benefit from the caching
> the DefaultResourceHandler provides anyway. Serving local files is probably
> the least of our worries when it comes to caching.
>
> -Lincoln
>
>
> On Thu, 2009-09-24 at 13:42 -0700, Ken Paulsen wrote:
>
> There are lots of reasons besides caching. Mostly having to do with the
> locating and serving of bits. However, the **default** ResourceHandler
> should do what most people expect it to do -- and my belief is that
> means it should cache all content. A flag (such as the development
> phase flag) can and should disable caching for development only...
>
> If someone wants to serve resources from a Database, ldap, generated via
> Java code, web services, etc.... then they need a custom Resource and
> perhaps a custom ResourceHandler. I think this gives very good
> fine-grained control to the advanced developer.
>
> Ken
>
> Jim Driscoll wrote:
> > Naive question: If we don't do cache control on resources, what's the
> > point of resources? I had thought the whole point was automatically
> > segmenting your application into dyanmic, uncached pages, and static,
> > cached pages. At least, that's the major benefit that I've been
> > telling people.
> >
> > Jim
> >
> > On 9/24/09 12:08 PM, lincolnbaxter(a)gmail.com wrote:
> >> I agree partly :)
> >>
> >> My vote is for no auto-caching, and allowing all scopes.
> >>
> >> I don't see any problem providing access to all scopes in these files
> >> if caching is not default. Caching is such a sensitive subject, and
> >> is one area where I feel the intuitive route is to omit functionality.
> >>
> >> If caching is on by default, I think logging a warning is acceptable
> >> feedback when a dev uses request or session scope in a resource file.
> >> If we want to hard stop it (not my favorite idea,) then disallowing
> >> these scopes is the only way to go, I suppose.
> >>
> >> Maybe its just me, but I prefer controlling cache headers myself.
> >>
> >> Lincoln
> >>
> >>
> >> Sent from my Verizon Wireless BlackBerry
> >>
> >> -----Original Message-----
> >> From: Ryan Lubke<Ryan.Lubke(a)Sun.COM>
> >>
> >> Date: Thu, 24 Sep 2009 11:50:23
> >> To:<jsr-314-open(a)jcp.org>
> >> Subject: Re: Evaluating EL in resource files
> >>
> >>
> >> On 9/24/09 10:22 AM, Andy Schwartz wrote:
> >>> Ken Paulsen wrote:
> >>>>
> >>>> Question: How does EL parsing in a resource effect the caching
> >>>> headers sent by the resource handler?
> >>>>
> >>>
> >>> I was wondering the same thing. Ideally every resource that we serve
> >>> up should specify http headers to encourage browser caching. Allowing
> >>> EL expressions in resource content of course complicates this. If we
> >>> want to allow arbitrary expressions then either:
> >>>
> >>> 1. We cannot allow these resources to be cached (bad). Or...
> >>> 2. We need some way to ensure that every resource URL is always mapped
> >>> to the same content (ie. EL expressions will always evaluate to the
> >>> same result for any given URL).
> >>>
> >>> For #2, this might mean allowing a resource to tweak the URL in order
> >>> to add information that ensures that the URL reflects the any EL
> >>> dependencies.
> >>>
> >>> In the examples that Ed gave, it seems possible that the EL
> >>> expressions such as this:
> >>>
> >>> #{resource['this:layout.css']}
> >>>
> >>> Would in fact always evaluate to the same value for any particular
> >>> resource URL. If this were the case, then we could safely set cache
> >>> headers for such resources.
> >>>
> >>> However, if arbitrary EL is allowed (eg. EL that references
> >>> request/session scope data), then we must either do #1 or #2 above.
> >>>
> >>> Should we consider placing some limits on what types of EL expressions
> >>> are allowed/resolved? For starters, possibly only provide access to
> >>> #{resource} expressions? If these are guaranteed to evaluate the same
> >>> for each requested URL, we should be able to cache these resources.
> >> This is what I believe was intended (I recall pointing this out some
> >> time back during some internal discussions). The expressions should be
> >> limited to results that aren't going to change between requests because
> >> of caching semantics.
> >>>
> >>> Imposing such a limitation might also help us to reduce the chance of
> >>> collisions with Prototype's use of #{}.
> >>>
> >>> BTW, Weblets provides similar functionality:
> >>>
> >>> https://weblets.dev.java.net/doc_11/longdoc/usageresources.html
> >>>
> >>> The solution appears to be limited to resolving Weblet resource URLs
> >>> (does not support arbitrary expressions). This functionality is
> >>> similar in scope to my suggestion above.
> >>>
> >>> Andy
> >>>
> >>>
> >>
>
> --
> *Lincoln Baxter, III*
> Co-Founder of OcpSoft <http://ocpsoft.com>
>
> Creator of:
> PrettyFaces <http://ocpsoft.com/prettyfaces>: URL rewriting for JSF
> PrettyTime <http://ocpsoft.com/prettytime>: Java elapsed timestamp
> formatting
>
>
>
14 years, 7 months
[jsr-314-open] Spec clarification: features not available in JSP
by Andy Schwartz
Gang -
Taking a look at the following thread from the MyFaces dev list:
http://markmail.org/thread/ykjmdu6ehdqpxyq7
I am concerned that this is an indication that we haven't been clear
enough about what is supported in Facelets vs. JSP. After all, if the
MyFaces guys (who spend a lot of time in the spec) found this confusing,
it seems likely that our average users will too.
I believe that the spec does specify that no new features/tags have been
added to JSP tag libraries. However, I had a hard time tracking this
down... Can anyone provide me with a section #?
I would like to propose two other steps that we should take to make sure
that this is clear:
1. Let's update the spec to state specifically what functionality (down
to the tag/tag library level) is not supported in JSP.
It is possible that this information is already present, but if not, I
would like to see a section that contains a list of all of the new tags
that were added in JSF 2 that are specific to Facelets (ie. not
available in JSP).
2. Let's update the Facelets PDL docs to identify tags that are not
present in JSP.
For example, the PDL doc for f:ajax should state that it is not
available in JSP.
Do these sound like reasonable changes?
Personally I think it is important to clarify this (ideally in the next
MR) as we have a large (potentially soon to be confused) user base of
JSP users looking to upgrade to JSF 2.
Andy
14 years, 7 months
[jsr-314-open] revisiting the JSR-314 openness policy
by Dan Allen
Several EG and community members, myself included, have requested--directly
or indirectly--for the openness policy of JSR-314 to be revisited. We are
concerned that the original goals have not been fully met and, therefore,
are not yet satisfied with the situation.
Certainly, the opening of the EG mailinglist for viewing by subscribers is a
step in the right direction, but it does not embrace the level of openness
that properly respects the community's role and expertise nor does it
effectively attract new participants. *It's also important to note that the
web archives stopped working in late June.*
We never addressed two key requirements that were identified and agreed on
in a previous thread (see
http://archives.java.sun.com/cgi-bin/wa?A2=ind0904&L=JSR-314-OPEN&P=2581):
1. We need a list focused on specification discussion that is
readable/writable by the public.
2. The lists we use should be indexable/accessible without requiring a login
.
Our first choice for request #1 is to allow all subscribed members of the
jsr-314-open list to post, with moderation of a person's inaugural post
(webbeans-dev uses this approach, for instance). The second choice would be
to have a separate list open to the community. In either case, both lists
should satisfy request #2.
The current solution, the jsr-314-open mailinglist, does not address either
of the above two requirements. (It's even difficult to reference a thread,
as indicated by the supporting link).
Additionally, having a moderator forward messages from the jsr-314-comments
e-mail alias is also a flawed arrangement. It causes extra work for the
moderator and confusion on behalf of the sender, the latter of whom gets
locked out from participating in the discussion he or she originates.
To muddy the waters further, the newly overhauled JCP site offers
EG-specific forums, JSR-314 included, that are open to the public:
http://wiki.jcp.org/boards/index.php?b=958
The forums meet the requirements above, with one possible exception. Based
on initial evaluation, it appears that the e-mail bridge, if it exists, may
not be enabled. I think we can all agree that having an e-mail bridge is an
implied requirement.
Let the following response by Jim Driscoll to an inquiry on the
java.netforums about whether there are public discussion boards for
JSF (
http://forums.java.net/jive/message.jspa?messageID=358786) provide
motivation to revisit the openness policy:
I'd love to have more actual users involved in the discussion of future
>> features, please do join in as much as possible. I'm not sure about the
>> read-only nature of the 314-open list - I may be wrong. If I'm right about
>> it being read only, and you have specific suggestions, file a spec bug/
>> rfe, and mail here, and I'll see to it that your points are heard on the
>> list.
>>
>
Clearly the read-only nature of the jsr-314-open list is acting as a barrier
to participation. It puts more work on the shoulders of EG members to carry
discussions back and forth, in the style of the game Telephone (
http://en.wikipedia.org/wiki/Chinese_whispers), which we all learned in
grade school quickly degrades the accuracy of the initial message. As a
result, a potential improvement to JSF dissolves.
I'd like to provide clarifications about the agreements that were made at
JavaOne that Ed cited in the forum post referenced above.
1. jsr-314-open(a)jcp.org is read only to non-EG members. Non-EG members can
>> earn they way in at the discretion of the EG.
>>
>
Regardless of whether we have one list or two, we need somewhere for
community members to post in an unrestricted manner. Currently, the
community still has no unmoderated voice in the form of a mailinglist.
2. Feedback should be sent to jsr-314-comments(a)jcp.org. This list is
>> moderated by one of the EG members, in a rotating fashion. Currently
>> this is being done by Dan Allen. The moderator will pass along content
>> to jsr-314-open(a)jcp.org at his or her discretion.
>>
>
This is a stopgap solution until we can have a real community feedback
channel. Forwarding messages is just messy and doesn't give the sender a
chance to participate.
As usual, anyone can apply to be on the EG once they join the JCP, but
>> we scrutinize membership carefully, especially for individual
>> JCP members. Organizational EG members have a little more weight.
>>
>
We should not consider individual JCP members as lesser participants than
organizations. Every participant in JSR-314 should be treated with equal
weight, regardless of whether they are John Smith, Barack Obama or Acme,
Inc.
Based on past discussions, the two changes to the openness policy of JSR-314
that were stated at the beginning of this message seem to have general
support from EG members. Does anyone have objections to these goals? If not,
are there specific barriers that we need to overcome to make this happen?
Ed, Roger - do you have suggestions for how best to pursue these goals?
-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, 7 months
Re: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
by Andy Schwartz
Thanks Lincoln. I haven't had time to debug this, but I have a theory
about what might be happening. In your sample:
> <a:editText value="#{cc.attrs.task.text}"
> rendered="#{!cc.attrs.disabled}">
> *<f:actionListener for="submit"
> action="#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)}"
> /> *
> </a:editText>
We expect "cc" to resolve to the containing composite component (ie. to
the <socialpm:taskBlock> component). I wouldn't be surprised if what is
actually happening is that "cc" is being resolved to the <a:editText>
composite component instead. One reason why I suspect this might be
happening is that I know that Ryan has investigated/resolved similar
problems not too long ago. Another reason why I am suspicious about
this is because we have faced similar issues in our own (ADF Faces)
declarative component solution. This stuff can get tricky. :-)
Hey Ryan -
Does this problem look familiar? Any thoughts on this?
Andy
Lincoln Baxter, III wrote:
> Hey Andy, here you go:
>
> In the mean time I'm going to sign up for the dev lists.
>
> ----------------------------------------------------------------------
> Using:
> <f:actionListener for="submit"
> action="*#{taskController.saveTaskAjax(cc.attrs.story,
> cc.attrs.task)}*" />
>
> *#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)}* =
> null values passed to method
> *#{taskController.saveTaskAjax(currentStoryBean.story, task)}* =
> correct values resolved, assuming currentStoryBean.story and task
> are both in the EL/page scope somewhere.
>
>
> ----------------------------------------------------------------------
> *CC Impl:*
>
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:a="http://java.sun.com/jsf/composite/ajax"
> xmlns:cc="http://java.sun.com/jsf/composite">
> <cc:interface>
> <cc:attribute name="story" required="true" type="Object" />
> <cc:attribute name="task" required="true" type="Object" />
> <cc:attribute name="disabled" required="false" type="Boolean"
> default="false" />
> <cc:insertChildren />
> </cc:interface>
>
> <cc:implementation>
> <h:outputStylesheet name="socialpm/socialpm.css" />
> <h:panelGroup id="taskBlock" layout="block" class="box-bordered p5
> #{cc.attrs.styleClass} taskBlock_#{cc.attrs.task.status}"
> style="#{cc.attrs.style}">
>
> <div class="m5l" style="margin-right: 25px;" >
> <h:outputText value="#{cc.attrs.task.text}"
> rendered="#{cc.attrs.disabled}"/>
> <a:editText value="#{cc.attrs.task.text}"
> rendered="#{!cc.attrs.disabled}">
> *<f:actionListener for="submit"
> action="#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)}"
> /> *
> </a:editText>
> </div>
> </cc:implementation>
> </html>
>
>
> ----------------------------------------------------------------------
> *consuming page code:* <-- this is where task is defined in the
> UI:Repeat, so it is in scope
>
> <!DOCTYPE html
> PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:c="http://java.sun.com/jsp/jstl/core"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:socialpm="http://java.sun.com/jsf/composite/socialpm"
> xmlns:pretty="http://ocpsoft.com/prettyfaces"
> xmlns:ui="http://java.sun.com/jsf/facelets" xml:lang="en" lang="en">
>
> <ui:composition>
> <h:form id="tasksForm">
> <c:if test="#{empty currentStoryBean.story.tasks}">
> <div class="m5">This story has no tasks. That could be a problem
> later...</div>
> </c:if>
>
> <ui:repeat value="#{currentStoryBean.story.tasks}" var="task">
> <socialpm:taskBlock task="#{task}" story="#{currentStoryBean.story}"
> members="#{currentProjectBean.project.activeMembers}"
> disabled="#{!authorizationBean.isMember or !currentStoryBean.story.open}"
> deletable="true" styleClass="m5t" refreshOnSave="false" />
> </ui:repeat>
> </h:form>
> </ui:composition>
> </html>
>
>
>
>
> On Sat, 2009-09-05 at 15:23 -0400, Andy Schwartz wrote:
>> Hey Lincoln -
>>
>> Lincoln Baxter, III wrote:
>> > First, please let me know if there is a better place to ask JSF Dev
>> > related questions.
>> >
>>
>> I suppose the Mojarra dev list might be the right place for
>> implementation questions:
>>
>> https://javaserverfaces.dev.java.net/mailinglists.html
>>
>> Though personally I am fine with you asking here. :-)
>>
>> Could you send along your composite component implementation (and
>> perhaps a snippet from the consuming page)? Just want to make sure I
>> understand the use case.
>>
>> Andy
>>
>>
>>
> --
> *Lincoln Baxter, III*
> Co-Founder of OcpSoft <http://ocpsoft.com>
> Author of PrettyFaces <http://ocpsoft.com/prettyfaces> URL Rewriting
> for JSF
>
>
14 years, 7 months
[jsr-314-open] composite:insertFacet target facet name
by Andy Schwartz
Gang -
As currently specified, composite:insertFacet's "name" attribute serves
two purposes:
1. It identifies the name of the facet on the containing composite
component to insert.
2. It identifies the name of the facet on the target component into
which the facet is being inserted.
As a result, the name of the facet exposed by the composite component
must match the name of the facet on the implementation component into
which the facet is being inserted. So, for example, if I have a
composite component as follows:
<composite:interface>
<composite:facet name="caption"/>
</composite:interface>
<composite:implementation>
<h:panelGrid>
<composite:insertFacet name="caption"/>
</h:panelGrid>
</composite:implementation>
Everything is happy, since both the composite component and the
h:panelGrid expose a "caption" facet.
However, if I want to define a composite components with two h:panelGrid
components and two captions:
<composite:interface>
<composite:facet name="caption"/>
<composite:facet name="backupCaption"/>
</composite:interface>
<composite:implementation>
<h:panelGrid>
<composite:insertFacet name="caption"/>
</h:panelGrid>
<h:panelGrid>
<!-- Uh oh. -->
<composite:insertFacet name="backupCaption"/>
</h:panelGrid>
</composite:implementation>
I am out of luck, since I now have a mismatch between the composite
component facet name and the h:panelGrid facet name. Or, at least, I
think I am out of luck... Am I missing some way to handle this use case?
If the spec does not yet provide a solution for this, I think that we
could/should solve this in one of two ways:
1. Add an attribute to composite:insertFacet that allows a target facet
name to be specified:
<h:panelGrid>
<composite:insertFacet name="backupCaption" targetName="caption"/>
</h:panelGrid>
2. Specify that the target facet name can be picked up from a wrapping
<f:facet> tag:
<h:panelGrid>
<f:facet name="caption">
<composite:insertFacet name="backupCaption"/>
</f:facet>
</h:panelGrid>
I prefer #2 since is consistent with typical facet usage.
Thoughts?
BTW, this seems like a fairly severe limitation to me. Is there any
chance that we can correct this by spec'ing the behavior from #2 in the
next MR? Of course, I am not sure what the rules are for MRs... In
this case we aren't so much adding new APIs (no new attributes/tags) so
much as specifying behavior for a particular use of existing APIs
(<composite:insertFacet> inside of <f:facet>) that was previously
unspecified.
Andy
14 years, 7 months
[jsr-314-open] AJAX library in JSF 2.0
by Dan Allen
---------- Forwarded message ----------
From: Ryan de Laplante <ryan(a)ijws.com>
Date: Sat, Sep 12, 2009 at 11:15 AM
Subject: [jsr-314-open] AJAX library in JSF 2.0
To: jsr-314-comments(a)jcp.org
Hi,
I read about the new RichFaces 4.0 being built for JSF 2.0 here:
http://www.jroller.com/a4j/entry/richfaces_4_0_0_alpha1
They are still using AJAX4JSF instead of JSF 2.0's built-in AJAX library
because:
JSF 2 Ajax implementation still very limited and not contains our
> autoupdatable zones, limitations for autoupdate, statuses, table partial
> updates, server side processing options and so on. Queue in JSF not
> configurable at all..
>
> Some of these points could be solved at application level by using some
> event's handling for example. But for some features - you will even not have
> a point to attach the functionality to. If the features that we provides
> with our ajax enchancements was implemented in JSF - we would not started
> reimplementing the weel for sure ;)
>
This makes me worry that none of the majorJSF UI component libraries will be
using the built-in AJAX library because it doesn't have enough features.
Will JSF 2.1 complete the AJAX functional requirements of RichFaces and
IceFaces?
Can anyone comment on how the JSF 2.0 AJAX library compares to other major
Java web frameworks? Is it on-par, ahead of, or behind other web
frameworks?
-----
Another question I have is about hiding managed beans from views. If I were
to build a JSF 2.0 application that lets users customize the screens with
themes/skins, I would not want them to be able to access any and every
scoped bean in the system. To have this level of control I might need to
use a web framework that gives me more control such as Struts 2, because it
uses Freemarker and/or Velocity.
Have you heard of anyone mixing JSF with Freemarker?
Thanks,
Ryan
--
Ryan de Laplante - Senior Programmer
It Just Works Software Corporation
17 Colborne St. E #202 Orillia, ON L3V1T4
Tel: 705-326-4254 ext 132
Fax: 647-341-9336
ryan(a)ijws.com
14 years, 7 months
Re: [jsr-314-open] Nested composite component facet insertion/rendering issue
by Ed Burns
>>>>> On Wed, 16 Sep 2009 10:13:36 -0400, Dan Allen <dan.j.allen(a)gmail.com> said:
DA> I suppose it depends on whether insertFacet attaches a facet to the parent
DA> component or whether it inserts the contents of the facet inline. I suspect
DA> the latter. In that case, you woud need to wrap insertFacet in <f:facet>,
DA> right?
<cc:insertFacet>
The presence of this tag in a <composite:implementation> section must
cause the named facet to be taken from the facet map of the top level
component and inserted as a facet child of the component in which this
element is nested.
javax.faces.CompositeFacet
encodeBegin() and encodeEnd() must take no action for this
renderer. Due to the specification of the <composite:insertChildren>
tag handler, the component passed to the encodeChildern() method of
this renderer will be the component with component-family
javax.faces.Output and renderer-type equal to the one for this
renderer. The implementation of encodeBegin(), must obtain the
component attribute value under the key given by the value of the
symbolic constant UIComponent.FACETS_KEY from the attributes map of
the argument component. If not found, throw IOException. This value is
referred to as "facetName" for discission. Find the closest ancestor
composite component in which the argument component is nested. If no
such component can be found, thow IOException. Otherwise, get the
facet whose name is "facetName". If found call encodeAll() on the
facet.
AS> However, if I define a second component, foo:inner, that exposes the
AS> same facet:
AS> <composite:interface>
AS> <composite:facet name="caption"/>
AS> </composite:interface>
AS> <composite:implementation>
AS> <composite:renderFacet name="caption"/>
line B^^^^^^^^^^^^^^^^^^
AS> </composite:implementation>
AS> And then attempt to pass the facet into the foo:inner component from the
AS> foo:outer implementation:
AS> <composite:implementation>
AS> <foo:inner>
AS> <composite:insertFacet name="caption"/>
line A^^^^^^^^^^^^^^^^^^
AS> </foo:inner>
AS> </composite:implementation>
1. when the using page executes, the children <f:facet name="caption">
are placed in the facet map of the top level component for foo:outer.
2. when the insertFacet on line A executes, the children are moved from
being facet children of the top level component for foo:outer to being
facet children of the top level component for foo:inner
3. when the renderFacet on line B executes, according to the spec, it
should find the facet and render it.
It looks to me like an impl bug.
Can you file it?
Ed
[1] http://java.sun.com/javaee/javaserverfaces/2.0/docs/pdldocs/facelets/comp...
[2] http://java.sun.com/javaee/javaserverfaces/2.0/docs/renderkitdocs/HTML_BA...
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 7 months
[jsr-314-open] Nested composite component facet insertion/rendering issue
by Andy Schwartz
Gang -
While looking at #{cc} expression handling, I played around with some
simple composite components and noticed the following behavior.
If I define a composite component, foo:outer, that accepts a facet:
<composite:interface>
<composite:facet name="caption"/>
</composite:interface>
And then use the component, specifying the facet:
<foo:outer>
<f:facet name="caption">
<h:outputText value="Hello, Facet! (Outer)"/>
</f:facet>
</foo:outer>
I find that things work as expected if I render the facet in the
foo:outer implementation:
<composite:implementation>
<composite:renderFacet name="caption"/>
</composite:implementation>
And also work just fine if I pass the facet into a Java-based
(non-composite) component:
<composite:implementation>
<h:panelGrid>
<composite:insertFacet name="caption"/>
</h:panelGrid>
</composite:implementation>
However, if I define a second component, foo:inner, that exposes the
same facet:
<composite:interface>
<composite:facet name="caption"/>
</composite:interface>
<composite:implementation>
<composite:renderFacet name="caption"/>
</composite:implementation>
And then attempt to pass the facet into the foo:inner component from the
foo:outer implementation:
<composite:implementation>
<foo:inner>
<composite:insertFacet name="caption"/>
</foo:inner>
</composite:implementation>
My expectation is that the facet would be inserted in to the foo:inner
composite component (via the <composite:insertFacet name="caption">) and
then rendered by the foo:inner implementation (via the
<composite:renderFacet name="caption">). However, the facet do contents
do not appear in the rendered output.
I wasn't sure whether this is a spec issue, implementation or user
error, and have not had a chance to debug further. Want to raise this
here in case anyone could comment.
FWIW, this is running against the Mojarra trunk. I have not tested
MyFaces. (I have attached the two composite components.)
Andy
14 years, 7 months
[jsr-314-open] CLOSED Re: Need guidance: invalid assumptions in design of resource versioning feature
by Ed Burns
>>>>> On Fri, 11 Sep 2009 11:18:36 -0700, Ryan Lubke <Ryan.Lubke(a)Sun.COM> said:
On 9/9/09 8:35 AM, Ed Burns wrote:
EB> I'm not fond of reducing the flexibility that we already have. Ryan has
EB> implemented something that he's satisfied with. Ryan, can you please
EB> share the details so we can further discuss the options for ammending
EB> the specification?
RL> Here's where I am currently with this issue.
RL> Implementation wise, I changed the logic to support classpath
RL> resources only within the context of the web application. This
RL> requires the use of ServletContext.getResourcePaths() in order to
RL> obtain all of the included JAR files as well as any potential
RL> content under /WEB-INF/classes/META-INF/resources and storing the
RL> paths that were discovered in some structure for lookup purposes.
RL> This worked fine in GFv2/3 and JBoss 5.1.0. However, we've run into
RL> an issue where this falls apart in embedded situations (mvn
RL> jetty:run as an example). We can't be guaranteed that /WEB-INF/lib
RL> or /WEB-INF/classes will exist in embedded scenarios. Sure, there
RL> are workarounds, but it's going to surprise developers in this
RL> situation and I don't think that's what we want.
RL> I've tried some other potential fixes and they tended to work in some
RL> cases and then failed in others.
RL> At this point, I'm thinking we should punt on trying to support
RL> versioned classpath resources and address
RL> the issue proper in 2.1.
Ok, I have added issue C033 to the changelog. [1].
Ed
[1] http://wiki.java.net/bin/view/Projects/Jsf2MR1ChangeLog
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 7 months
