[jsr-314-open] Metadata complete jar files
by Andy Schwartz
Gang -
Section 11.5.1 of the spec defines the following annotation scanning
behavior:
> Requirements for scanning of classes for annotations
> * If the <faces-config> element in the WEB-INF/faces-config.xml file
> contains metadata-complete attribute whose value is “true”, the
> implementation must not perform annotation scanning on any classes
> except for those classes provided by the implementation itself.
> Otherwise, continue as follows.
> * If the runtime discovers a conflict between an entry in the
> Application Configuration Resources and an annotation, the entry in
> the Application Configuration Resources takes precedence.
> * All classes in WEB-INF/classes must be scanned.
> * For every jar in the application's WEB-INF/lib directory, if the jar
> contains a “META-INF/faces-config.xml” file or a file that matches the
> regular expression “.*\.faces-config.xml” (even an empty one), all
> classes in that jar must be scanned.
Since application developers have the ability to disable annotation
scanning at a global level, this means that any component set that wants
to support this mode would need to provide a metadata complete
faces-config.xml file. I don't think this is a hardship for most
component vendors, since presumably component vendors are going to want
to provide design-time metadata (eg. JSR-276 metadata), which, for the
moment, requires a faces-config.xml file anyway.
A question that came up here is whether we can tweak section 11.5.1 to
accommodate metadata complete jar files. That is, can we specify that
any jar that contains a faces-config.xml with a metadata-complete="true"
attribute would not be scanned? This would allow component vendors to
indicate that their jar files are metadata complete, and thus avoid the
cost of annotation scanning for the contents of the jar.
Note that while the annotation scan is typically a one time hit (during
application startup), design-time tools may end up starting/stopping JSF
repeatedly during the development process. Thus, avoiding unnecessary
scanning should provide for a more efficient development experience.
Any thoughts on whether we could/should make this change? Does anyone
know of reasons why we avoided specifying this originally?
Also - if we agree to make this change, is this small enough that we
could get this into the the next MR?
Andy
13 years, 8 months
[jsr-314-open] ADMIN: Final list of issues for JSF 2.0 and actions for each
by Ed Burns
This is the final list of issues for JSF 2.0. No other issues will be
considered for 2.0.
I do not think content of any of these issues, nor their quantity,
warrant another Proposed Final Draft, but I will of course produce an
Editor's Draft for the public on jsr-314-open to review.
I will send another email with the dates for the remainder of JSR-314.
Any further discussion on any topic sent to this list will be rolled
into the next release of the spec.
SECTION: List of EG Members from whom I have obtained explicit buy-in
I have obtained explicit buy in for this list in its present state from
the following EG members.
Pete Muir Status: DONE, but need final official answer from JBoss. Promised by 1800 EDT 20090415.
Andy Schwartz 617 794 7974 Status: DONE Spoke with him 1319 20090415
Kito Mann 917 848 3359 Status: DONE Spoke with him 1600 20090415
Martin Marinschek +43 699 1805 3906 Status: DONE Spoke with him at 1400 EDT 20090415
Ken Paulsen x42083 Status DONE Spoke with him 1403 20090415
Alexandr Smirnov DONE IRC chat with him 16:00 20090415
SECTION: Issue sums
Number of issues remaining: 30
I've broken down the issues into two groups, bigger and smaller. I
assert that we do not need to do a PFD2 because none of the issues are
so big as to warrant such an action.
Bigger issues:
Number of bigger issues: 16
deferred: 5
will fix: 10
pushed to EG member requesting the issue: 1
Smaller issues:
Number of smaller issues: 14
deferred: 1
will fix: 13
SECTION: Bigger issues
PM> ISSUE: 1) Fully stateless views. This is a performance optimization
PM> which is ideal for the use case of pages which are output-only (no
PM> form). This is moderately complex to get right, and a blocker in our
PM> opinion. This also has the support of Apache.
We see two aspects to consider.
a. Marking specific views in an app as stateless. Putting a
transient="true" attribute on <f:view> doesn't work here because the
template page with <f:view> can be shared across pages.
There are several options we could try but none of them are feasible at
this point in time.
b. If the Form Renderer never calls StateManager.writeState(), and the
ViewHandler is aware of this fact, then you have a stateless view.
Therefore, statelessness is an implementation detail. Adam Winer
provided this idea, which we implement in Mojarra.
ACTION: Defer to a later release.
EB> Pete agrees to defer, but Gavin does not.
EB> Andy agrees to defer.
EB> Ken agrees to defer.
EB> Martin agrees to defer.
EB> Kito agrees to defer
EB> Alexandr, agrees to defer, but is unhappy about it.
PM> ISSUE: 3) Better handling of whitespace in facelets. Currently
PM> whitespace in view sources can get "eaten" and you have to resort to
PM> tricks like to add space. I would put this as a critical and
PM> the (spec) complexity as low (simply switch it on/off).
ACTION: Defer to a later release.
EB> Pete says, "70 - yes, defering that is fine"
EB> Andy is ok for deferring this
EB> Ken is ok to defer.
EB> Martin agrees to defer. Not a spec issue.
EB> Kito agrees to defer.
EB> Alexandr, agrees to defer
PM> ISSUE: 2) First class support for page actions. This allows a more
PM> action orientated approach (Struts style) approach to page
PM> authoring, where some arbirtrary method can be run when the page is
PM> accessed. Use cases include security (redirect to another page if
PM> the user isn't logged in for example). JSF2 currently includes
PM> "second class" support - it's possible to do this stuff, but not in
PM> simple fashion. As the design for this has already been done, and
PM> reviewed/approved by the EG, the complexity is low. I would put this
PM> as a blocker. It also has the support of Oracle.
Pete, when we had the discussion regarding View Parameters, we decided
to defer Page Actions to a later release. We will not reverse that
decision.
ACTION: Defer to a later release.
EB> Pete says "I am happy for this to slip, given you can do a
EB> workaround with events. l know Dan is unhappy with the current
EB> state. On this one, Gavin was wavering, and would probably be happy
EB> to slip it".
EB> Andy can accept deferral for this
EB> Ken says, "Events should be able to accommodate this use case until
EB> we have a chance to improve the user-experience in a later release.
EB> I think we should defer this.
EB> Martin says ok to defer. But Ed and Martin agree that we should
EB> have a {Pre,Post}BuildViewEvent that is published appropriately.
EB> Kito agrees to defer.
EB> Alexandr, agrees to defer
PM> ISSUE: 5) make behaviour of new components more consistent -
PM> currently f:validateBean (JSR-303 support) / f:ajax use different
PM> strategies to mark areas of the areas of the page to enable. Align
PM> these. This is a blocker (once it is written in stone we can't go
PM> back and fix it) and complexity low (the EG has agreed on the
PM> correct design, so the language needs tweaking in the spec and
PM> javadoc). This has the support of Oracle.
ACTION: If the EG agrees that the default validator setup currently hard
coded into UIInput.encodeEnd() can be moved into
Application.createComponent(), this can be done.
EB> Pete agrees with the plan on this.
EB> Andy agrees with the plan on this.
EB> Ken agrees with the plan on this.
EB> Martin agrees with the plan on this.
EB> Kito agrees with the plan on this.
EB> Alexandr agrees with the plan, but thinks the tag handler is a
EB> better place to imbue the component with the default validator.
PM> ISSUE: 7) Allow multiple error messages for a component to be
PM> displayed - especially useful for JSR-303 support. This is
PM> complexity low, and priority minor (easy for an addon to fix).
ACTION: Pete, please submit a diff patch modifying the following files:
standard-html-renderkit-base.xml jsf-api/doc/standard-html-renderkit-base.xml
message-message-props.xml jsf-api/doc/message-message-props.xml
to specify the change, and the necessary implementation changes for this
feature.
For to the patch to be accepted at this VERY late date it must meet the
following requirements. Because of the late timing of this feature
request we will be unable to accept the feature if the patch doesn't
meet all of the following requirements.
* All existing automated tests still run successfully after applying the patch.
* The spec wording in the patch requires no grammatical or formatting
changes.
* The patch is sent to the EG list no later than 23:59 EDT Wednesday
20090415.
RL> ISSUE: 2. View ID Derivation Fix
RL> (java.net Issue 1002)
RL> Status: Ed had a fix - push back from Ken Paulsen on the fix;
ACTION: Because this breaks the V3 Admin GUI, it must be fixed for 2.0
=> edburns fix by Thursday 20090316 17:00 EDT.
RL> ISSUE: 3. Client Behavior in Composite Components
RL> (patch from Exadel)
RL> Status: Patch 1 checked in; Patch 2 checked in;
RL> Javadocs / prose updates need to be made.
ACTION: Fix checked in to revision 6952, will review spec implications
RL> ISSUE: 4. Bean Validation Bug Fixes
RL> (java.net issue 1058)
RL> Status: Checked in; Needs discussion; Javadocs, prose updates
ACTION: Will review docs, RELEASE_PENDING. Make sure spec for
CompositeComponent Attributes ELResolver mentions this, 5.6.2.2
JD> ISSUE: Impl 1071: UIData.visitTree()
ACTION: Will Fix. fully specify
JD> ISSUE: Impl 1072: Facelet Meta* Javadocs not cleanroom implementable
ACTION: Will fix.
EG> ISSUE: JavaScript disabled support [Was: Outcome of JSFDays
EG> discussions]
ACTION: This can easily be doable in a later release. Considering the
late date of this request we need to defer it.
EB> Pete is ok with deferring this.
EB> Andy is ok with deferring this.
EB> Ken is ok to defer.
EB> Martin is ok with defer
EB> Kito agrees to defer.
EB> Alexandr agrees to defer.
EG> ISSUE: minor feature enhancement for Facelets/VDL
ACTION: Defer to a later release
EB> Pete's ok with deferring this.
EB> Andy's ok with deferring this.
EB> Ken is ok to defer.
EB> Martin ok to defer.
EB> Kito ok to defer.
EB> Alexandr is ok to defer.
EG> ISSUE: required attributes in composite components
ACTION: Defer to a later release
EB> Pete's ok with deferring this.
EB> Andy's ok with deferring this.
EB> Ken is ok to defer this.
EB> Martin is ok to defer this.
EB> Kito ok to defer this.
EB> Alexandr, agrees to defer
EG> ISSUE: remove target attr from h:outputStylesheet (was:
EG> h:outputStylesheetdocs need to be updated)
ACTION: Will fix this
EG> ISSUE: #{compositeComponent.attrs....} verbosity
ACTION: Change "compositeComponent" to be "cc". Implementations may
provide a context-param that allows renaming the implicit object name to
an arbitrary value for the case where an app happens to have a
managed-bean named cc.
EB> Pete says he won't object to this solution.
EB> Andy is ok with this action
EB> Ken says, "I like 'cc' better to solve the verbosity issue. I
EB> recommend deferring on the renaming via context-param for now -- but
EB> would not object to it making the release if others feel strongly
EB> that it needs to be done now."
EB> Martin is ok with this solution.
EB> Kito is ok with this solution.
EB> Alexandr is ok to defer.
EG> ISSUE: composite insert children
ACTION: 2 days. Take the following steps
EB> Pete is ok with this action.
EB> Andy is ok with this action.
Ken says,
KP> I am very nervous about the reparenting (insert*) commands. If 2
KP> composite:insertFacet/Children tags are used in the same composite
KP> component, it will likely fail. Is that acceptable?
EB> We will specify that if multiple <composite:insertFacet> elements
EB> exist with the same name in the <composite:implementation> section,
EB> the "last one wins".
EB> We will specify that if multiple <composite:insertChildren> elements
EB> exist in the <composite:implementation> section the facelet layer
EB> must throw a FaceletException.
KP> If the component inserted has code which does: getParent(), they'll
KP> be exposed to the internal workings of a composite component (which
KP> they shouldn't know exists).
Yes, you are correct, but I feel this is sufficiently corner case to
ignore.
KP> I would prefer render* in most cases. In cases where this isn't
KP> possible (implementing a facet inside a composite component),
KP> perhaps we can do a proxy component which can be added to the inner
KP> facet and delegate rendering to the page-facet? I think there will
KP> be problems with this implementation. If I am wrong, then I do not
KP> object to this going in -- otherwise, I think it should be deferred.
EB> Martin is ok with this action.
EB> Alexandr is ok with this action.
1. rename composite:insertFacet to composite:renderFacet
2. create composite:insertFacet that reparents the named facet from the
top level component to be a facet child of the parent tag in the
composite:implementation section in which the composite:insertFacet
resides.
3. delete composite:renderUsingPageChildren
4. create composite:insertChildren that reparents the children from the
top level component to the parent of tag in the composite:implementation
section in which the composite:insertChildren resides.
5. For composite:insert{Facet,Children} support nested composite
components.
=> edburns take this to Bill and see what he thinks, if we need to do a
PFD2.
SECTION: Smaller issues
PM> ISSUE: 6) Better support for timezones. Currently only one of two
PM> timezones can be used - default or system. The user may well be in
PM> some other timezone entirely, so make the timezone used
PM> configurable. This is a critical issue, and the complexity is medium
PM> (but we have a full proposal for this waiting in the wings that
PM> didn't make it due to time constraints)
If this was a truly critical issue, it would have been brought up a long
time ago, not after the PFD has been published. Furthermore, this is a
platform level thing. I direct you to your JSR-316 EG rep for this feature.
ACTION: Defer to later release.
EB> Pete is ok with deferring this.
EB> Andy is ok with deferring this.
EB> Ken says defer.
EB> Martin ok to defer.
EB> Kito ok to defer.
EB> Alexandr is ok to defer
RL> ISSUE: 2. 11.4.7 - Absolute ordering. I think if a document name
RL> is explicitly referenced but not present, an exception should be
RL> thrown.
ACTION: We'll log a message in this case.
EB> Pete's ok with this action.
EB> Andy's ok with this action.
EB> Ken's ok with this action.
EB> Martin is ok with this action.
EB> Kito is ok with this action
EB> Alexandr states, "if related document was not present, it is
critical error, therefore Exception should be thrown." Given the
prevailing opinion, we'll stick with logging.
RL> ISSUE: 3. FacesRenderKit annotation hasn't existed from some time
RL> now.
ACTION: Remove this from the spec.
RL> ISSUE: 4. Javadocs for EditableValueHolder.addValidator() and
RL> ValueHolder.setConverter() mention ResourceDependency annotation
RL> processing. This documentation should be moved to
RL> Application.createConverter() and Application.createValidator().
ACTION: Will fix this in the spec.
RL> ISSUE: 5. 3.1.11 mentions that the AttributesMap, if the current
RL> component is composite, must eval any ValueExpressions stored in the
RL> Map. This is incorrect. This logic is handled by the
RL> CompositeComponentAttributesELResolver
ACTION: Will fix in the spec.
RL> ISSUE: 6. Preface references META-INF/managed-beans.xml. Support
RL> for this file is no longer required.
ACTION: Will fix.
RL> ISSUE: 7. 5.6.2.2 Doesn't mention any support for the special
RL> parent keyword in #{compositeComponent} expressions.
ACTION: Will fix.
RL> ISSUE: 8. 6.1.1.15 lists Flash as a property of FacesContext. It's
RL> now a property of ExternalContext.
ACTION: Will fix.
RL> ISSUE: 9. 7.1.1 and 7.1.2 Typo in assertion marker
RL> 'defualtActionListener' and 'defualtRenderKit' There may be others.
ACTION: Will fix
RL> ISSUE: 10. 7.4.2 will need to be discussed due to the
RL> implementation of issue 1066.
ACTION: Will fix
RL> ISSUE: 11. 7.4.3 should include a navigation case example with
RL> redirect parameters.
ACTION: Will fix
RL> ISSUE: 7.5.1 and others. This may already be done, but
RL> PageDeclarationLanguage should be ViewDeclarationLanguage
ACTION: Will fix. Make sure retargetAttachedObjects and retargetMethodExpressions are on VDL, not ViewHandler.
RL> ISSUE: 1. Spec ResponseWriter methods: startCDATA endCDATA (java.net
RL> issue 1055) Status: impl done; method javadocs / prose need to be
RL> done;
ACTION: Will fix
EG> ISSUE: View and custom scoped eager managed beans?
ACTION: Will Fix. Add eager for session scoped managed beans
RL> Update 3rd bullet in 11.5.1 so that pattern for custom faces config file
names is something that ends with .faces-config.xml. This brings it in
alignment with 11.4.
--
14 years, 6 months
Re: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
by Ed Burns
>>>>> On Tue, 18 Aug 2009 08:08:31 +0200, Martin Marinschek <mmarinschek(a)apache.org> said:
MM> Hi Ed,
>> Which I still don't understand. Can you please explain explicitly?
MM> I sent a mail to Kin-Man that we can't pass parameters from the
MM> framework to the method-expression. So, we can now do:
MM> #{bb.action(myparam)}
MM> to call a method with signature:
MM> public String action(String myparam) {}
MM> but we can not do:
MM> #{bb.valueChangeListener(myparam)}
MM> to call a method with signature:
MM> public void valueChangeListener(ValueChangeEvent ev, String myparam) {}
MM> only with signature:
MM> public void valueChangeListener(String myparam) {}
MM> so what we loose is the ValueChangeEvent, which was provided by the
MM> JSF framework as a parameter to the invoke-call in the
MM> Method-Expression instance (we will only receive the parsed
MM> parameters).
Thanks. Now I understand your request.
MM> I already got mail by Kin-Man - he said this won't be included, we
MM> are too late.
MM> This effectively means we cannot use the new EL functionality to solve
MM> the problem that was discussed in this thread (using
MM> valueChangeListeners in a dataTable), and therefore, even though we
MM> can get rid of the f:setPropertyActionListener, we would still need an
MM> f:setPropertyValueChangeListener - a pity.
I agree that the feature you request is indeed valid. Can you please
file it in the uel.dev.java.net issue tracker?
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 2 months
[jsr-314-open] DRY and form with JSF 2
by Damien Gouyette
Hello,
I have a lot of forms to do and i don't understand a point
<h:outputLabel value="client's birthdate" for="birthDateField"/>
<h:inputText id="birthDateField" label="client's birthdate"/>
<h:message for="birthDateField"/>
if i don't set label on inputText, i have an error message like :
formNew:birthDate: 'a' could not be understood as a date. Example:
12/09/2009 instead of
client's birthdate : 'a' could not be understood as a date. Example:
12/09/2009
Can you reuse outputLabel value if exists ?
Just for information, this message is the french error message when i
set a dateConverter on my inputText. (little bug)
Damien GOUYETTE
15 years, 2 months
Re: [jsr-314-open] revisiting the JSR-314 openness policy
by Ed Burns
>>>>> On Fri, 18 Sep 2009 12:00:28 +0100, Pete Muir <pmuir(a)redhat.com> said:
PM> On 18 Sep 2009, at 00:09, Dan Allen wrote:
>> 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.
PM> My preference would be for there to be two email lists, both with
PM> public, non-password-protected, archives. The first is the EG list.
PM> The second is the a discussion list. A regular member of the EG can
PM> post unmoderated to either list. Any subscriber can post to the
PM> discussion list. If a member of the community is an expert on a
PM> particular sub-topic, we should pull them into the EG list, using
PM> moderation to allow their posts through.
I like Pete's suggestion. Dan, is the lack of email gateway the only
roadblock to using the existing facility on the new jcp.org site?
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 2 months
Re: [jsr-314-open] AJAX library in JSF 2.0
by Pete Muir
On 13 Sep 2009, at 22:53, Jim Driscoll wrote:
>> I hope that AJAX4JSF is modified so that it builds on top of the JSF
>> standardized APIs instead of being a complete replacement for them.
>
> That's something that can best to achieved by their customers
> lobbying the AJAX4JSF people.
>
> AFAIK, there's nothing to stop them specifically from adopting the
> current API set - other than their reluctance to rewrite an existing
> codebase. But that's based on the one link that you sent on - you'd
> have to ask them directly if that's true.
Essentially this is the opposite of the RichFaces 4 plan (I agree, the
comment that this discussion is based on is ambiguous at best). Just
like ICEFaces, we intend to build RichFaces 4.0 on top of the JSF 2
Ajax API. I've asked Jay (RichFaces project lead) to blog in detail on
this to clear up the confusion :-)
From initial discussions with Alex, my understanding is JSF 2 Ajax
will account for around 70% of what was in Ajax4JSF (which IMO just
validates how complete JSF 2 Ajax is!). The remaining 20% has not been
specified (not ready yet, or no consensus or ...), and will be built
as extensions on top of JSF 2 Ajax.
HTH
15 years, 3 months
[jsr-314-open] [C036-ElInResources] ACTION: Vote: Resource.getInputStream() underspecified (was: Evaluating EL in resource files)
by Ed Burns
>>>>> On Fri, 25 Sep 2009 08:55:11 +0200, Werner Punz <werner.punz(a)gmail.com> said:
WP> Anyway I think this discussion gets a little bit off topic ;-), wasnt it
WP> about how to apply the el to javascripts originally?
Thank you. Please take the valuable discussion of caching and resources
to a separate thread.
>From the previous discussion, I draw two alternatives, which I place on
the table for further debate.
OPTION RestrictAllowableExpressions
With this option, we modify Resource.getInputStream() to state that the
implementation must evaluate EL Expressions in resource files if and
only if the expression is simple (not compound) and starts with the
"resource" implicit object. Handling of any other kinds of EL
Expressions requires decorating the ResourceHandler.
OPTION DefaultToOptOut
With this option, we modify Resource.getInputstream() to state that EL
evaluation in Resource files is disabled by default. For simplicity, I
suggest the user convey their intention at a per-application granularity
using a context-param. If the user does decide to opt-in, all EL
Expressions in all resources are evaluated every time the resource is
served. Resource.getInputStream() will include non-normative text
alerting the user to possible scope complications.
I prefer RestrictAllowableExpressions because decorating the
ResourceHandler is an easy way to allow more powerful behavior.
ACTION: Please voice your opinion by 1700 EDT Monday 28 September 2009.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 3 months
[jsr-314-open] Evaluating EL in resource files
by Ed Burns
Greetings EG,
We have two problems here. First, let me restate the intent of the
feature.
FEATURE SHORT DESCRIPTION:
==========================
Let JSF2 resources refer to other resources in a way that the browser
can make GET requests to load them via the ResourceHandler.
RATIONALE for FEATURE:
======================
CSS files may refer to other files using the following syntax
url( some URL )
The url() element may appear in several places in a CSS file, most
commonly to the right of @import, as in
@import url(layout.css)
@import url(typography.css)
@import url(colorAndMedia.css)
Unfortunately, this doesn't "just work" when the CSS file in question is
in a JSF resource library, for obvious reasons.
The solution we chose was to allow EL expressions in CSS files. That
way, you could say this in your css file:
@import url(#{resource['this:layout.css']})
@import url(#{resource['this:typography.css']})
@import url(#{resource['this:colorAndMedia.css']})
and when the file actually gets served up it would look like:
@import url(/jsf-ezcomp02/javax.faces.resource/layout.css.jsf?ln=ezcomp);
@import url(/jsf-ezcomp02/javax.faces.resource/typography.css.jsf?ln=ezcomp);
@import url(/jsf-ezcomp02/javax.faces.resource/colorAndMedia.css.jsf?ln=ezcomp);
PROBLEM 1. This behavior should have been specified in the javadocs for
Resource.getInputStream(). I've added this to the ChangeLog.
PROBLEM 2. JavaScript resources have the same problem; they can refer
to other javascript files and the browser needs to know how to fetch
them. We employed the same solution: put EL in there and it gets
evaluated on the way out.
Unfortunately, the prototype JavaScript library uses #{} to mean
something important.
SUGGESTED SOLUTION to PROBLEM 2.
Let's assume PROBLEM 1 didn't exist. I suggest we modify the spec for
getInputStream() to say that all resources EXCEPT JavaScript resources,
must do the EL evaluation on the way out. We need some way for users to
enable the feature for JavaScript resources because, let's face it, not
everyone uses prototype. Ryan and I suggest we adopt a protocol that
says, "if the resource name ends in '-el' we always turn on the EL
evaluation on the way out".
Thoughts?
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 3 months
Re: [jsr-314-open] composite:insertFacet target facet name
by Ed Burns
>>>>> On Tue, 15 Sep 2009 19:29:22 -0400, Andy Schwartz <andy.schwartz(a)oracle.com> said:
AS> Gang -
AS> As currently specified, composite:insertFacet's "name" attribute serves
AS> two purposes:
AS> 1. It identifies the name of the facet on the containing composite
AS> component to insert.
AS> 2. It identifies the name of the facet on the target component into
AS> which the facet is being inserted.
[...]
AS> 1. Add an attribute to composite:insertFacet that allows a target facet
AS> name to be specified:
AS> <h:panelGrid>
AS> <composite:insertFacet name="backupCaption" targetName="caption"/>
AS> </h:panelGrid>
AS> 2. Specify that the target facet name can be picked up from a wrapping
AS> <f:facet> tag:
AS> <h:panelGrid>
AS> <f:facet name="caption">
AS> <composite:insertFacet name="backupCaption"/>
AS> </f:facet>
AS> </h:panelGrid>
AS> I prefer #2 since is consistent with typical facet usage.
I happen to prefer #1, but everyone else favors #2, we'll go with #2.
Andy, can you please file a spec issue and share the number with the
group? Once you have it, I'll add an entry in the changelog wiki.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 3 months
