[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
[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.
--
13 years, 10 months
[jsr-314-open] JSF 2.1 ajax spec enhancements
by Ganesh
Hi,
Here's my wishlist for JSF 2.1 ajax spec enhancements. All
proposed enhancements are pure client side (js) stuff. Still
they are basic features that make a lot of difference in
practical use.
If there are no objections I will open spec enhancement requests
for JSF 2.1 on the 4 parameters and 2 functional clarifications
described hereafter.
First i'd like to see 4 parameters added to f:ajax as well as to
jsf.ajax.request. All 4 of them are optional and default to the
2.0 behaviour to guarantee backward compatibility:
1. delay: Number of milliseconds before an ajax request is issued.
If another ajax request comes in before the end of the delay the
prior one is discarded. Very important one for onkeyup events in
autosuggest boxes to avoid bombing the server down.
2. timeout: Number of milliseconds before a xhr request is cancelled.
We've already got
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=682
on this one.
3. queuesize: The 2.0 spec specifies an unlimited ajax queue, though
for most usages a queue size of 1 is appropriate. This param makes
the queue size configurable. Follow up requests would replace prior
request if the queue is full.
4. pps (true/false): Only the components named in the "execute"
parameter are processed in phase 2-4, but the spec insists
on submitting all elements included in a form. If pps is set to
true submission is reduced to the form params named in execute.
This is a performance feature that can boost speed on large
pages.
There are also 2 functional clarifications I want to propose.
Mojarra and MyFaces partly differ in this, so I think we need to
clarify.
runscripts: If a piece of XHTML comes in via xhr and contains <script>
tags the ajax engine should automatically trigger execution of
these scripts. This is important if you want to replace a js function
or if the scripts somehow initialize UI elements. It depends on a
combination of the js replacement code
(innerHTML/adjacentHTML/contextualFragment/...) and the browser
platform whether the browsers automatically run these scripts,
IE mostly doesn't run them FF mostly does so. The ajax engine should
know whether the browser does automatically run the scripts and if it
doesn't they should be triggered via js.
applystyles: If a piece of XHTML comes in via xhr and contains <style>
tags the ajax engine should automatically apply the styles to the page.
Again some browser engines with some replacements methods do apply
the styles others don't and the ajax engine should be responsible
to guarantee it.
Best regards,
Ganesh
14 years, 3 months
[jsr-314-open] getting behind CDI
by Dan Allen
I'm going to venture out onto a limb here in hopes of leveraging the
influence of your professional recommendations. I ask that you read through
this message with an open, forward-looking mind.
I feel strongly that, as a group, we should provide a consistent
recommendation regarding the programming model of JSF by getting behind CDI.
Now, I realize there are Spring developers and supporters on this EG. So,
before going any further, I want to clarify that the point I am making
relates specifically to the native Java EE 6 technology stack. Spring has
always been a strong alternative to the native Java EE programming model and
continues to be a great companion of JSF. The common rival that we want to
downplay is JSF managed beans.
I made the following analogy in my JSF 2 talk at JSF Summit that sets the
stage for my advice:
Facelets replaces JSP as CDI replaces JSF managed beans
(Keep in mind CDI is not a programming model, but adds additional discovery
of a platform-defined managed beans)
When JSF was created, no other facility was available for defining
contextual managed beans. As of Java EE 6, there is now a platform-wide
definition of a managed bean. With the services of CDI, there is a way to
discover, produce, scope, inject, name and override beans. All of a sudden,
the injection facility, and limited number of services in the JSF managed
bean facility looks rudimentary in comparison. And the reality is, before
CDI, most developers likely used an alternative bean container anyway
(probably Spring) to define managed beans. So the JSF managed bean facility
has been falling out of favor for a long time.
But there is a more serious problem with continuing to recommend the use of
the JSF managed bean facility. The injections do not take the scope of the
injected bean into consideration. That means, you cannot inject a
request-scoped bean into a session-scoped bean without causing the
request-scoped bean to become a session-scoped bean through attachment. This
is a very typical occurance with having managed beans in a web application.
CDI not only keeps beans in different scopes loosely coupled, it hides the
scope at the injection point. Therefore this discrepency of JSF managed
beans alone could be enough to question their viability. (If you are a
type-safety advocate, CDI has that going for it over JSF managed beans as
well. And with @ManagedBean, you still can't scope a stateful EJB, which
could cut out an unnecessary middle layer).
Having stated my advice for recommending CDI over JSF managed beans, let me
address some common misconceptions that may be stopping you from embracing
CDI.
*
Isn't CDI heavyweight?*
No. CDI is extremely efficient. All bean definitions and injection points
are calculated at startup. The scanning process is localized to archives
that contain a beans.xml file, so the number of classes to scan is
reasonable. The scanner is pluggable, so it can leverage the scanning that
may already be taking place in the application server. I would estimate that
it doesn't take any longer than looking for @ManagedBean annotations on
classes. Also, proxies are used to manage scoped injections, meaning the
overhead of interceptors is not present.
*Doesn't CDI require extra setup?*
CDI is present in any Java EE 6 application server (full or web profile), so
you can depend on it being there. JSF 2 is part of the Java EE 6 platform,
which is one of it's greatest differentiators over competing web frameworks.
(Of course, other web frameworks could use CDI too, but that is a separate
point).
*But I won't be able to use CDI in a Servlet Container, right?*
Not true. The CDI reference implementation (Weld) provides a single
extension JAR (weld-servlet.jar) that you drop into your web application
archive and you get a full CDI environment (you just don't get EJBs, but
that's to be expected).
*What about older Java EE containers?*
The Weld servlet extension JAR could be added to an application deployed to
a pre-Java EE container and likely work just fine. Let the Weld team know
what doesn't work: https://jira.jboss.org/jira/browse/WELDX
*Isn't it easier just to get started with JSF 2 along?*
Use these Maven 2 archetypes to get started with JSF 2.0 + CDI 1.0 in a
jiffy: http://tinyurl.com/weld-archetypes (soon to be available in the Maven
Central Repository)
*But we worked hard to be able to define JSF managed beans with annotations*
Yes, when we did that Java EE 6 was not around and it was a good step
forward at the time. But 6 months has gone by and Java EE 6 is here, along
with CDI. It's time to embrace the improvements.
*Isn't CDI just a Red Hat thing*?
Of course not. We should all be behind CDI. As the spec lead, Red Hat worked
very hard to define a set of services for Java EE managed beans that would
make the development of enterprise applications simpler. That's exactly the
type of effort we all put in for the JSF 2 specification. (JSF 2 was forged
by all of us collectively. CDI has the same story). So CDI is your
technology, one that you can use in Java EE 6 or even outside of it. There
is no reason to back away from it.
Perhaps a lot of the heated debating over dependency injection turned you
off, but that heated debate really made the whole platform better because EG
members, like us, talked and worked things out in the end. I really want you
guys to view CDI as just as much part of our collective stack as the EL,
JSF, JPA and other successful technologies.
Showing users how to use @ManagedBean on a class and inject other managed
beans with @ManagedProperty or an EJB with @EJB is showing developers only a
portion of the value of this platform's programming model. We want to put
our best foot forward. That's why we show composite components in
presentations and not how to create a components in Java. We show Facelets,
not JSP. We want to make it seem as easy as it can be.
Rather than recommending:
@ManagedBean
@RequestScoped
public class BlogEditor {
@ManagedProperty("#{blogDao}") BlogDao blogDao;
// getters and setters required
}
We want to show them:
@Named
@RequestScoped
public class BlogEditor {
@Inject BlogDao blogDao;
}
or even simpler, we can use the built-in @Model stereotype that combines
@Named and @RequestScoped
@Model
public class BlogEditor {
@Inject BlogDao blogDao;
}
The only consolation is that they have to add an empty beans.xml to WEB-INF.
I'm asking you to consider my request to get behind CDI. We aren't talking
about a big change here. But the consistency of the message, and the power
that they get with CDI, will make a huge impact. I encourage you to read the
Weld reference guide as it very clearly explains what CDI is all about (if
it doesn't, tell us). http://tinyurl.com/weldrefguide
(I'll conclude by saying that if this were a Spring + JSF 2 talk, I won't
start by recommending @ManagedBean as a first step).
I welcome your feedback. I'll be glad to answer questions as well.
-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, 3 months
[jsr-314-open] [jsf2.next] WITHDRAWN Proposal to support new semantic HTML5 tags
by Ed Burns
>>>>> On Sat, 12 Dec 2009 23:08:59 -0800, Jim Driscoll <Jim.Driscoll(a)Sun.COM> said:
JD> For the most part, no. The exceptions appear to be noted in the article
JD> (but, I haven't reviewed the HTML5 spec - it ironically causes Firefox
JD> to crash whenever I try).
JD> So instead of saying <div class="nav">, you instead say <nav>
JD> However, it turns out that there's serious problems with using these
JD> tags, at least according to John Resig (I attended a talk he gave on
JD> Friday).
JD> While the HTML5 shiv referenced below will allow these tags to work in
JD> IE in the basic case, there are still two problems: 1) they won't nest,
JD> and 2) innerHtml won't work with these tags.
JD> So, given those problems, I withdraw the proposal. Since these problems
JD> occur in IE8, it looks like these tags may be as far as 5 years away
JD> from being usable. Tragic.
Withdrawl noted and agreed.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 3 months
Re: [jsr-314-open] wrap ups of JSF Summit 2009
by Ed Burns
>>>>> On Wed, 16 Dec 2009 22:09:58 -0500, Dan Allen <dan.j.allen(a)gmail.com> said:
DA> On Wed, Dec 16, 2009 at 9:49 PM, Andy Schwartz <andy.schwartz(a)oracle.com>wrote:
>> Dan Allen wrote:
>>
>>> I look forward to reading about the conference through another
>>> perspective.
>>>
>>>
>> Here's another, covering JSF Summit + the 3 other conferences that I
>> attended this fall:
>>
>> http://andyschwartz.wordpress.com/2009/12/17/jsf-2-on-the-road/
>>
>> Though be warned: I come from the "It's my stupid blog so I'll make it as
>> long as I want thank you very much" school of blogging. :-)
>>
DA> Wow! Should we give that a book cover and publish it? Hehehe. Looking
DA> forward to reading it.
DA> Hey, does anyone have the picture of the JSF EG at the end of JSF Summit on
DA> their camera? I never saw a tweet about it (or I missed it).
I recall that was on Andy's camera, before he dashed to the airport.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 3 months
Re: [jsr-314-open] Additional nominations
by Ed Burns
>>>>> On Mon, 07 Dec 2009 14:26:42 -0500, Andy Schwartz <andy.schwartz(a)oracle.com> said:
AS> Thanks for proposing this Lincoln. +1 from me of course.
AS> At the EG meeting we also discussed giving members of the JSF
AS> implementation teams as well as component vendors write access to
AS> jsr-314-open. Along those lines, it seems to me that we should be
AS> including:
AS> - RichFaces: Jay Balunas
Added.
AS> - PrimeFaces: Cagatay Civici
I've requested him to become a full JCP member so that he can officially
be on the EG.
AS> Absolutely. I assumed that Werner already had write access to
AS> jsr-314-open, but if not, we need to correct this.
He does.
MM> to our mailing list before) - and Leonardo Uribe as well as Matthias
MM> Wessendorf should have write access to our mailing list, IMHO.
I granted Matthias write privs (under his employment at Oracle)
I have granted Leonardo write privs. Martin, can you guarantee that he
has signed the JSPA?
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 4 months
Re: [jsr-314-open] An observation on where we should focus attention
by Ed Burns
>>>>> On Thu, 17 Dec 2009 12:13:52 -0600, Jason Lee <jason(a)steeplesoft.com> said:
JL> On 12/17/09 12:05 PM, David Geary wrote:
>> I'd love to see some built-in interoperability in JSF for GWT. GWT
>> gives you a lot of Ajax firepower (in fact, it's unrivaled, IMO) on
>> the client, and JSF provides lots of firepower on the server.
>> Combining the two technologies is a very attractive proposition.
>>
>> Grails has a GWT plug-in, and I would love to see JSF have something
>> along those lines.
JL> Exadel started gwt4jsf some time ago, but I think it died on the vine.
JL> Might be a good project for $SOMEONE to pick back up:
Sigh. I had a sit down with Bruce Johnson at JAOO 2006 (the one and
only time I went there, sadly) and we mapped out what I thought was a
very nice integration strategy. Nothing ever came of it, but it went
something like this:
GWT's RMI-like serverside integration is feature poor when viewed from
the perspective of someone used to EL, DI, and JPA. Wouldn't it be nice
if you could just have ELExpressions in your GWT components and value
bind them to server side objects? In this way, you could re-use your
POJOs and write both JSF views and GWT views to them.
There were some other niceties in there that I'm sure will come up if we
start to work on this in earnest.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 4 months
[jsr-314-open] Please welcome Cagatay Civici to the JSR-314 EG
by Ed Burns
Many of you already know Cagatay as the man behind the excellent
PrimeFaces JSF component library. His official membership on the
JSR-314 EG is long overdue.
PMO, Cagatay assures me he faxed his JCP paperwork on 16 December 2009.
When you have recevied and processed it, please officially add him to
the JSR-314 EG.
Thank you.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 4 months