[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
[jsr-314-open] localePrefix
by Kito Mann
So far it's clear that the current way locales are handled in JSF 2 is not
intuitive and requires unnecessary overhead. Since we know this now, how
about defining a solution ASAP that can be handled a the implementation
level until 2.1 standardizes it at the spec level? This way we can save some
unnecessary pain for our developers, and avoid criticism of JSF 2 going
forward. Since everybody expects it to work like the current Java platform
prefixes, I don't think a new solution would require a lot of debate.
Thoughts?
---
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter:
jsfcentral
+1 203-404-4848 x3
JSF Summit Conference Dec 1st-4th in Orlando: http://www.jsfsummit.com
15 years, 2 months
Re: [jsr-314-open] [OT] faces-config.xml names
by Andy Schwartz
One more update...
Matthias has logged the following spec issue to track this:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1376
Andy
Andy Schwartz wrote:
> Thanks Dan.
>
> BTW, regarding:
>
>> The desired semantics are to match the XML NMTOKEN type:
>
> Looking back at our original email thread, there was discussion of
> using the XML ID type (which also allows '.'). It seems fairly clear
> that the choice of javaee:java-identifierType did not match our intent.
>
> Ed, Roger -
>
> Can we find some way to address this, at the spec and/or
> implementation level? Ideally we want to do this before too many more
> frameworks publish their faces-config names.
>
> Andy
>
> Dan Allen wrote:
>> \p in the regexp basically the dot matcher (.) for specific unicode
>> classifications. So the regex says roughly:
>>
>> starts with a letter, _ or $
>> can have any number of letters, _ or $
>>
>> Letter is a loose term that encompasses strange symbols you will
>> likely never type (at least not if you are writing in English, but we
>> are friendly to other character sets as well where the dot character
>> would not match).
>>
>> Still, no literal dot (.) allowed.
>>
>> -Dan
>>
>> p.s. Not sure why we select the $ to be allowed. Or is that the end
>> of line matcher? If so, I still don't get what it is trying to say.
>>
>> On Tue, Oct 20, 2009 at 2:48 PM, Andy Schwartz
>> <andy.schwartz(a)oracle.com <mailto:andy.schwartz@oracle.com>> wrote:
>>
>> Gang -
>>
>> The spec defines the name element as:
>>
>> <xsd:element name="name"
>> type="javaee:java-identifierType"
>> minOccurs="0"
>> maxOccurs="1">
>>
>>
>> javaee:java-identifierType is:
>>
>> <xsd:complexType name="java-identifierType">
>> <xsd:annotation>
>> <xsd:documentation>
>>
>> The java-identifierType defines a Java identifier.
>> The users of this type should further verify that
>> the content does not contain Java reserved keywords.
>>
>> </xsd:documentation>
>> </xsd:annotation>
>> <xsd:simpleContent>
>> <xsd:restriction base="j2ee:string">
>> <xsd:pattern value="($|_|\p{L})(\p{L}|\p{Nd}|_|$)*"/>
>> </xsd:restriction>
>> </xsd:simpleContent>
>> </xsd:complexType>
>>
>>
>>
>> My regular expression parsing skills are not what they should be,
>> but I believe that this is unintentionally overly strict. The
>> desired semantics are to match the XML NMTOKEN type:
>>
>> http://www.w3.org/TR/2000/WD-xml-2e-20000814.html#NT-Nmtoken
>>
>> Which allows '.' (and other characters too, like '-', ':').
>>
>> This is going to require a loosening of the spec - in particular,
>> in the XSD for faces-config.xml. Can we find some way to address
>> this? Perhaps as a spec errata that allows implementations to
>> accept qualified ids?
>>
>> Andy
>>
>> lincolnbaxter(a)gmail.com <mailto:lincolnbaxter@gmail.com> wrote:
>>
>> Agreed. I don't know if that's something we can fix? Should be
>> fixed IMO. Though I don't understand the reasons it wasn't
>> included at all, so I can't really theorize.
>>
>> Sent from my Verizon Wireless BlackBerry
>>
>>
>> ------------------------------------------------------------------------
>> *From: * Dan Allen <dan.j.allen(a)gmail.com
>> <mailto:dan.j.allen@gmail.com>>
>> *Date: *Tue, 20 Oct 2009 14:20:53 -0400
>> *To: *<lincolnbaxter(a)gmail.com
>> <mailto:lincolnbaxter@gmail.com>>; <jsr-314-open(a)jcp.org
>> <mailto:jsr-314-open@jcp.org>>
>> *Subject: *Re: [jsr-314-open] [OT] faces-config.xml names
>>
>>
>>
>> On Tue, Oct 20, 2009 at 2:16 PM, <lincolnbaxter(a)gmail.com
>> <mailto:lincolnbaxter@gmail.com>
>> <mailto:lincolnbaxter@gmail.com
>> <mailto:lincolnbaxter@gmail.com>>> wrote:
>>
>> Andy,
>>
>> Prettyfaces uses ocpsoft_pretty_faces (dot is not an allowed
>> character and will cause deploy failure)
>>
>>
>> Too bad. I would have voted for the Java namespace style. I
>> like org.apache.myfaces.trinidad and org.ocpsoft.prettyfaces
>>
>> Either way, I would use a name that maps closely to the root
>> package of the component library.
>>
>> -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
>>
>>
>>
>>
>>
>> --
>> 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
>
15 years, 2 months
[jsr-314-open] Components
by Jim Driscoll
Andy had mentioned that there was interest in adding a few components
for JSF 2.next. And our audience mentioned that as well.
I thought it would be an interesting exercise to try to gather up a list
of what kinds of components already existed as either existing JSF or
JavaScript widgets, and I went a little overboard - but hopefully you'll
find it useful as something to stimulate thought on the topic.
http://weblogs.java.net/blog/driscoll/archive/2009/10/14/almost-comprehen...
Jim
15 years, 2 months
[jsr-314-open] clarification on f:validateRequired
by Michael Concini
I'm doing some testing on MyFaces to make sure all is behaving as
described in the spec for some of the new tags. I've run into an issue
where I need some clarification on the spec though regarding the
validateRequired tag.
The confusion lies in what the interaction and precedence should be for
the validateRequired tag vs. the javax.faces.VALIDATE_EMPTY_FIELDS param
setting and the algorithm specified for UIInput.validateValue().
The validateValue algorithm says that if
javax.faces.VALIDATE_EMPTY_FIELDS has not been set, that we only execute
the validators if bean validation is present. This, however, will
prevent the RequiredValidator from executing as well. Since the javadoc
states that adding an f::validateRequired tag has the same affect as
setting required="true" on the UIInput, it would seem that at least for
this validator, we need to validate empty fields even if bean validation
is not present.
What is the proper behavior here? Should we be ignoring the
validateRequired tag unless bean validation is present? Should we be
executing only the RequiredValidator if one is attached? all validators
if a RequiredValidator is attached? What about if VALIDATE_EMPTY_FIELDS
is explicitly set to false?
Any clarification on this would be much appreciated.
Thanks,
Mike
15 years, 2 months
[jsr-314-open] [OT] faces-config.xml names
by Andy Schwartz
Gang -
Not a spec issue, but figured it would be okay to ask here...
We are picking a name for the Apache Trinidad faces-config.xml file (for
ordering purposes), see:
https://issues.apache.org/jira/browse/TRINIDAD-1603
Was just wondering what other folks (eg. IceFaces, RichFaces,
PrettyFaces) have picked for their names. We're thinking about going
with a qualified name, eg. "org.apache.myfaces.trinidad".
Anyone else picked a name yet and care to share? It's not especially
that we adhere to any particular convention. More just asking out of
curiosity.
Andy
15 years, 2 months
[jsr-314-open] Coercion in the EL
by Martin Marinschek
Hi all,
I don't know if we discussed this already, but today the coercion
issue in the EL made me loose a few hours again. I've had this before,
but seemingly forgot about it - time to follow up on this.
The issue in short: collapsed="#{bb.collapsed}"
Boolean getCollapsed() {
return null;
}
will lead to a value of "false" for the collapsed attribute if
java.lang.Boolean is set as the expected type of the corresponding
value-expression, according to the EL spec. Hrmmpf.
You can read more in this blog-entry:
http://www.irian.at/blog/blogid/unifiedElCoercion/#unifiedElCoercion
Are we going to say that for JSF 2.0 Facelets we will never set the
expected-type? Or are existing EL implementations not following the
spec and this is not a problem in reality (however, at least the one
that I use does follow the spec)?
regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
15 years, 2 months
[jsr-314-open] Fwd: Components
by Martin Marinschek
Hi all,
don't know if this mail made it to the list - but I guess Matthias
would want the EG to see it. Andy already answered with a hint towards
our discussion playground, which still doesn't really work AFAIK....
regards,
Martin
---------- Forwarded message ----------
From: Matthias Wessendorf <matthias.wessendorf(a)oracle.com>
Date: Thu, 15 Oct 2009 10:15:03 -0700
Subject: Re: [jsr-314-open] Components
To: jsr-314-open(a)jcp.org, dan.j.allen(a)gmail.com,
mmarinschek(a)apache.org, Jim.Driscoll(a)sun.com, Andy
<andy.schwartz(a)oracle.com>
I like the way that the jsr-314-open(a)jcp.org list is not open.......
so I am hijacking it .... sorry.
What I wanted to "add" is the following sentence:
I am agreeing with Dan on NOT adding all these extra components (incl.
the list from Jim's blog)!
inputDate, inputFile, maybe subform and also some sort of h:document
(internally using h:head/body)
would be what I'd like to see. But not adding a bunch of rich components
etc. That would add WAY to much
overhead to the spec.... Just my cent.
Oh, as I am frustrated about the openness, maybe one more comment...
Can't you guys just rename the "jsr-314-open(a)jcp.org" to be "semi-open",
or to "no-comment-allowed-but-open-to-read" ?
Man, this is really frustrating...
Thanks!
Matthias
Dan Allen wrote:
> When Andy and I spoke last week, we seemed to be in agreement about
> the goal of this expanded set of components, which I will restate here.
>
> To recap, the existing components set--specifically the form
> elements--are roughly a 1-to-1 mapping with HTML. But by no means is
> HTML a comprehensive set of core components. The way I see it is if
> you were to take ~100 applications (web, Oracle Forms, mobile, paper,
> etc) and try to find the components that show up a majority of the
> time, excluding "rich" components like trees and menus, that should be
> your core set of components. The reason I exclude the rich components
> is because they have way too many configuration options to have a good
> standard...they end up getting replaced anyway (feel free to argue
> otherwise). The standard set should be expanded primarily in the area
> of form inputs. But I can also see the defense for better table
> support since it is of equal importance in web apps.
>
> A perfect example of a missing component is a date input. Dates are
> universal. You can guarantee that you are going to need one somewhere
> in your app. Yet, it is missing from the core component set. You have
> to take the lame and insufficient approach of using a converter with
> an h:inputText. Of course, you will eventually want to style or even
> replace the date input with some fancy version from ADF Faces,
> RichFaces or ICEFaces. But the point is, you can at least get the
> application going with the core component set. Thje developer is
> hooked at that point.
>
> Just to give you a feel for other types of components that might be
> warranted, pick up an Android device or iPhone and flip through a
> couple of apps. You'll notice some core components that you just
> expect to be there but don't map with our "traditional" view of
> inputs, painted in our minds by HTML. Inputs like phone number, date,
> time, color, file upload. So let's work to cover the "lame if absent"
> cases and then we can debate the cases that are on the fence.
>
> -Dan
>
> On Wed, Oct 14, 2009 at 4:33 PM, Jim Driscoll <Jim.Driscoll(a)sun.com
> <mailto:Jim.Driscoll@sun.com>> wrote:
>
> Andy had mentioned that there was interest in adding a few
> components for JSF 2.next. And our audience mentioned that as well.
>
> I thought it would be an interesting exercise to try to gather up
> a list of what kinds of components already existed as either
> existing JSF or JavaScript widgets, and I went a little overboard
> - but hopefully you'll find it useful as something to stimulate
> thought on the topic.
>
> http://weblogs.java.net/blog/driscoll/archive/2009/10/14/almost-comprehen...
>
> Jim
>
>
>
>
> --
> 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
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
15 years, 2 months
Re: [jsr-314-open] updated spec
by Ed Burns
>>>>> On Wed, 14 Oct 2009 16:16:10 -0400, Dan Allen <dan.j.allen(a)gmail.com> said:
DA> Is there a specification document that is more up to date than June 25,
DA> 2009? Also, is there some way to build the PDF document from source? I'd
DA> like to see these instructions outlined somewhere.
That's the most recent version, the final one we handed to JCP. As I
mentioned in a private email to you, there are extenuating circumstances
regarding ongoing spec work. I appreciate your understanding. In the
meantime, we'll keep updating the ChangeLog on the wiki.
You need Adobe Framemaker to build the PDF. If you have a license and
you REALLY want to know how to do it, we can write up some
documentation.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 2 months
