myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <>
Subject A bunch of belated answers about ADF
Date Sun, 26 Feb 2006 21:21:15 GMT
Hi all,

I've been remiss in not subscribing to the users list - I've only been on
the dev list - and I hadn't realized that people were already talking
about ADF Faces over there, before we've even gotten a truly
Apache branded release out.  Well, nice to know we're attracting
that much interest! :)   But, to answer a bunch of questions from the
Nabble archive:

- "Are there any differences between adf-faces-10_1_3_0_4 (the current
version from Oracle) and the drop in Myfaces?"

Yes.  The drop in MyFaces is on the 11.0 branch.  The main point of
divergence is that the old "BLAF" look-and-feel is history, and has
been deleted both from the drop.  That codebase had lots of
dependencies on our old UIX-based rendering architecture, which has to
go as we move forward, and we want to concentrate on our skinning APIs
for providing a different look-and-feel.

- "I was just browsing through the developer manual from Oracle - it
seems like ADF faces is a whole framework build on top of JSF, with
its data control framework, page life cycle management etc. Can it
co-exist with Shale?"

Craig basically answered this one, but I think the main point of
confusion is ADF Faces vs. ADF.  ADF includes controller code, model
code (based on JSR 227), etc.  That's not what was donated - the
donation here was ADF Faces, which doesn't have many framework
features - it's mostly a component set (with some component-specific
frameworky features like PPR and skinning).  The main exception is the
presence of a "processScope", which is part of ADF Faces, and a Dialog
Framework, which has some very limited navigational concepts. 
Reconciling those with Shale will be worthwhile, but there's no
incompatibility per se.

- "File upload with ADF not working...  you probably have to copy the
apache commons fileupload jar into your application"

Nope;  the ADF Faces code actually doesn't use commons fileupload, but
instead a long-used-at-Oracle implementation of file upload.  One
project going forward is moving to commons-fileupload after seeing if
there's any features in the Oracle codebase that are missing in

- "The drop made public under ([1]) has dependency to Sun's JSF impl.
No big deal in changing it to MyFAces (["

Only sorta - our Maven build has a dependency on Sun's impl, but our
code has no dependencies at all on the Sun impl.  (A small lie:  one
of our tests does, but as Matthias said, not a big deal to switch.)  I
think the demo WAR in our drop has the Sun JSF impl in it, but just
delete those JARs and drop in the myfaces JARs.  (I should have done
this myself in the drop, oops.)

- "I use the ADF Faces 'Process scope' facility a great deal...."

This was a problem with values disappearing from the process scope. 
The code was relying on a dummy "get" method being triggered during
Render Response to do initialization.  It does hit a limitation of our
processScope - it's not thrilled with being mutated during Render
Response..  Laurie Harper's suggestion of using Shale is a good one; 
with JSF 1.2, a beforePhaseListener on the f:view would work well too.
 You could hack around the processScope limitation by forcibly putting
something, anything, in the processScope before Render Response, so
we'll at least generate an ID correctly.

"RE: ADF Blowing Up...  I traced it to the exact line: 
_adfRenderingContext.getProperties().put(key, value);"

This is a Facelets/ADF Faces issue.  When using Facelets with ADF
Faces, you don't register the FaceletViewHandler with
faces-config.xml, you use an ADF Faces specific registration point in
WEB-INF/web.xml, and then all will be well.  Check the Facelets user
list, which has talked about this.

"[ADF] disabling skinning:  it's perfect when you use a css "component
model" but
some people like him prefer to use a "page template model" (I don't
know how it is done) and he would really appreciate if we could
disable this feature to get rid of all the class id generated "

ADF Faces is built around a component model;  that's deeply built in
to our rendering approach, and it's one we think fits far better with JSF than
older CSS models.  Also, the same poster asked...

"Some renderers are true new JSF renderers while
some other are UIX adapters so it is quite confusing. "

Yep, the UIX adapters are going to all go, bit by bit.  It's a large
effort, so it'll
take some time, but the JSF renderers are the way to go.

"Two render kits? (MyFaces + ADF)  I noticed that ADF Faces
"overrides" the default MyFaces render kit for all html/core
components.  For example, <h:commandButton/> renders differently with
ADF Faces - it won't create a default dummy for the way MyFaces will.

We don't override all of them - just commandButton, commandLink, and form.  That
does mean the dummy form support is off.   Other than these, we tunnel through
to the original renderers even when you use oracle.adf.core. So add in
an <h:form>
or <af:form> to the top of your page, and you should be OK.

"ADF Renderer-Kit and Tomahawk incompatibility."

A post about a glitch with creating an HtmlCommandLink;  I suspect
the issue here is also that dummy form support is off;  manually add in
a form.

"I suppose that the Oracle Renderer does not like that  a new component
is added to the component tree during the Render Response phase. "

Nope, we're OK with that.

Then a thread about building ADF Faces, with one especially unanswered

"NOTE: These seems to be compiled such that they require a
1.5 JDK. If you need to run on 1.4, you must build it
yourself. "

That won't work:  ADF Faces requires JDK 1.5, period.  That is, of course,
subject to change based on MyFaces dev discussion, but at the moment,
that's the state of things.

Also, finally, there were some threads about dependencies on adfshare.jar.
This JAR is not a dependency in the code drop, and won't be going forward.

Adam Winer

View raw message