MyFaces Extension Filter breaks ADF's af:inputFile
I discovered this painfully today, thought I'd pass it along. It seems that by the time the HttpRequest gets to the ADF Filter, it's input stream is all tapped out and doesn't contain the file data anymore. I stepped through that filter (ADF) forever trying to find the error, couldn't, and so tried removing the MyFaces Extensions Filter, which worked. Didn't feel like wasting any more hours figuring out the how's and why's, but I'm assuming the Extensions Filter does much the same as the ADF Filter and then leaves the stream dry. Since I don't use any Tomahawk/Sandbox components yet (biding my time until InputAjaxSuggest is ready for primetime), I'm hoping the exclusion of this filter won't hurt me. Side issue- are the ADF-specific incubator mailing lists operating? I subscribed and got confirmation to all (both?) of them, but haven't received any messages.
Re: Anyone got a working ADF + MyFaces Tomahwak setup?
Murray Brandon wrote: If so, can you please shoot me a copy of your web.xml and faces-config.xml files? Thanks! note- I'm using Facelets, Spring, Shale as well. faces-config.xml (relevant parts) faces-config application default-render-kit-id oracle.adf.core /default-render-kit-id /application /faces-config web.xml (includes some stuff you don't need) ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=2.4 xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; display-namedisplay/display-name context-param param-namejavax.faces.STATE_SAVING_METHOD/param-name param-valueclient/param-value /context-param context-param param-namejavax.faces.DEFAULT_SUFFIX/param-name param-value.xhtml/param-value /context-param context-param param-nameoracle.adf.view.faces.ALTERNATE_VIEW_HANDLER/param-name param-valuecom.sun.facelets.FaceletViewHandler/param-value /context-param context-param param-namefacelets.DEVELOPMENT/param-name param-valuetrue/param-value /context-param context-param param-namefacelets.BUFFER_SIZE/param-name param-value8192/param-value /context-param context-param param-namefacelets.LIBRARIES/param-name param-value/WEB-INF/facelet/taglib/jb-custom.taglib.xml;/WEB-INF/facelet/taglib/sandbox.taglib.xml;/WEB-INF/facelet/taglib/shale-core.taglib.xml/param-value /context-param !-- for custom JSON Shale remoting -- context-param param-name org.apache.shale.remoting.OTHER_RESOURCES /param-name param-value /json/*:org.jb.plat.util.JSF.JSONMethodBindingProcessor /param-value /context-param filter filter-nameshale/filter-name filter-class org.apache.shale.faces.ShaleApplicationFilter /filter-class /filter filter-mapping filter-nameshale/filter-name url-pattern*.xhtml/url-pattern /filter-mapping context-param param-namecontextConfigLocation/param-name param-value/WEB-INF/spring/applicationContext.xml,/WEB-INF/hibernate/applicationContext-hibernate.xml,/WEB-INF/spring/baseball.xml/param-value /context-param listener listener-classorg.springframework.web.context.ContextLoaderListener/listener-class /listener filter filter-namesessionFilter/filter-name filter-classorg.jb.plat.util.OpenSessionInViewFilter_autoflush/filter-class init-param param-namesessionFactoryBeanName/param-name param-valuesessionFactory/param-value /init-param /filter filter-mapping filter-namesessionFilter/filter-name url-pattern/*/url-pattern /filter-mapping listener listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class /listener servlet servlet-nameFaces Servlet/servlet-name servlet-classjavax.faces.webapp.FacesServlet/servlet-class load-on-startup1/load-on-startup /servlet servlet-mapping servlet-nameFaces Servlet/servlet-name url-pattern*.xhtml/url-pattern /servlet-mapping filter filter-nameadfFaces/filter-name filter-classoracle.adf.view.faces.webapp.AdfFacesFilter/filter-class /filter filter-mapping filter-nameadfFaces/filter-name servlet-nameFaces Servlet/servlet-name /filter-mapping servlet servlet-nameresources/servlet-name servlet-classoracle.adf.view.faces.webapp.ResourceServlet/servlet-class /servlet servlet-mapping servlet-nameresources/servlet-name url-pattern/adf/*/url-pattern /servlet-mapping filter filter-nameMyFacesExtensionsFilter/filter-name filter-classorg.apache.myfaces.component.html.util.ExtensionsFilter/filter-class init-param param-namemaxFileSize/param-name param-value20m/param-value /init-param /filter filter-mapping filter-nameMyFacesExtensionsFilter/filter-name url-pattern/faces/*/url-pattern /filter-mapping filter-mapping filter-nameMyFacesExtensionsFilter/filter-name url-pattern*.jsf/url-pattern /filter-mapping filter-mapping filter-nameMyFacesExtensionsFilter/filter-name url-pattern*.xhtml/url-pattern /filter-mapping listener listener-class org.apache.commons.chain.web.ChainListener /listener-class /listener /web-app
Re: Migrating ADF Faces app to use Facelets
I actually just finished doing the same thing, so I sympathize w/you, Frank. :-) Totally worth it, though- the ADF components are fantastic, and Facelets is great to work with. Couple other tips I thought I'd chime in with, in the hopes of sparing others some time/web hunting: 1) It's crucial to put the context-param about the alternate view handler in web.xml, as Frank notes. Declaring it in faces-config under application will blow up. 2) the latest drop I got hold of (the MyFaces drop, not the last Oracle version) had two facelet-taglib files, af.taglib.xml and afh.taglib.xml, which had incorrect XML syntax and blew up Tomcat on startup--specifically, the docTypes were 'taglib' but the root element was 'facelet-taglib'. I unzipped adf-faces-implxxx and changed them, then zipped it back up; then was fine for a while. I learned later, however, that these files (while seeming to provide facelets support out of the gate) were actually interfering with adf-facelets.jar, which provides real Facelets support. (the other files worked for many things, but couldn't handle String[] attributes for whatever reason) So I went back and removed af.taglib.xml and afh.taglib.xml from adf-faces-implxxx, letting adf-facelets.jar handle all the facelets stuff, and everything worked. 3) a tangent, but related- if you find yourself trying to get Tomahawk ADF components working together, you may find this example helpful. The Tomahawk EqualsValidator won't work if you're comparing the component to an ADF component, and here's why: UIInput foreignComp = (UIInput) uiComponent.getParent().findComponent(_for); in EqualsValidator (line 72) is casting the compare to component to UIInput, but ADF input components don't extend UInput. You can create a custom ADFEqualsValidator by replacing the above with: UIXEditableValue foreignComp = (UIXEditableValue) uiComponent.getParent().findComponent(_for); or, of course, create an overarching EqualsValidator that tries both casts. In general, if a Tomahawk component isn't playing nice with ADF, that might be a good first place to look- the ADF components' hierarchy jumps straight from UIComponent to UIXComponent, so any casts from UIComponentBase down are going to fail. Perhaps this will change as ADF code moves into the fold, but for now, this is something you'll need to work around. also HingTH- Rogers Frank Felix Debatin wrote: Hi, finally I managed to migrate our ADF Faces app to use facelets. Ton of work, but it went smoothly and really pays off, making the page writing much more clean and powerful. What a wonderful combination!!! Here is a small migration guide for those who intend to do the same (note: I'm a Facelets beginner so there might be alternatives or better solutions): 1. Get the ADF Facelets contribution on the Facelets website and precisely follow the instructions provided there. I ended with the following entries in web.xml: context-param param-nameoracle.adf.view.faces.ALTERNATE_VIEW_HANDLER /param-name param-valuecom.sun.facelets.FaceletViewHandler /param-value /context-param context-param param-namefacelets.DEVELOPMENT/param-name param-valuetrue/param-value /context-param context-param param-namefacelets.VIEW_MAPPINGS/param-name param-value*.xhtml/param-value /context-param ... servlet-mapping servlet-namefaces/servlet-name url-pattern/faces/*/url-pattern /servlet-mapping 2. Include the XML name spaces in your pages as follows (and don't forget to change the extension .xhtml if you have the recommended web.xml configuration) af:document xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:f=http://java.sun.com/jsf/core; xmlns:af=http://xmlns.oracle.com/adf/faces; title=Hello World af:form Hello World! /af:form /af:document 3. Directly replace af:forEach tags with c:forEach. The af:forEach tags are not provided in the contributed tag library, but the c:forEach worked fine wherever I substituted them. 4. Replace af:region with ui:include, providing a src attribute pointing to the page instead of the old region attributes. (Consider ui:decorate as an alternative if you like.) This requires some manual rewriting. The region af:attributes need to be replaces by include ui:params. Get rid of the var. in the former region definition files. Consider surrounding the region definition files with ui:composition. 5. (Optionally - cleaner). Get rid of f:verbatim by writing straight inline HTML. 6. (Optionally - cleaner). Replace af:outputFormatted with af:outputText and HTML markup for user supplied values, so user-supplied markup is filtered out. 7. Take care not to include any non-ADF stuff such as inline text or markup in ADF tables, including the details. This will cause an ugly stack trace that completely messes up the involved session. I didn't encounter
Re: immediate action for non commands
Best way to do this now is with Cherokee (or whatever it's called). af:selectOneListbox takes an autoSubmit attribute, which does exactly what you want. I was thinking you could also set partialSubmit=true and do your refresh with PPR, which would be slick, but I'm not seeing that attribute in the docs. Looks like autoSubmit mandates a full refresh. :-( Dennis Byrne wrote: The kludge you speak of is the most popular way to do this. One warning. Let's say you have two controls, selectOneMenu and inputText. Your requirement is that the inputText is to be rendered *only* when a certain item (let's call it 'ITEM X') in the selectOneMenu is selected. You accomplish this by hooking a js event hander into @onclick or @onchange of the selectOneMenu. The js clicks a hidden commandButton and the form is submitted. In the action or actionListener of the commandButton, you dynamically render the inputText element and the form is then rerendered. If the user clicks then back button, on both IE and FireFox at least, the browser will not go back to the server. It will simple display the first page in the state it was in just *before* the form was submitted. There are two important parts to keep in mind. First, the selected item of the selectOneMenu was 'ITEM X'. Second, the inputText field was *not* rendered when the form was submitted. The user will have then effectivly placed the form into a state that is against the initial requirement. Dennis Byrne -Original Message- From: Lance Frohman [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 28, 2006 08:57 PM To: ''MyFaces Discussion'' Subject: immediate action for non commands What is the best practice if I need a drop down list - h:selectOneListbox - change to go to the server, as if there was an immediate=true on a command button. Depending on what is selected in the h:selectOneListbox, the page will be displayed differently. I was using a kludge with onclick= submitting a h:commandButton style=visibility:hidden; ... Thanks, Lance
facelet-taglib for Shale commonsValidator? + general facelet-taglib autocreation
Is there a file floating around out there to use Shale validators (and tags in general) in Facelets? I couldn't find one anywhere on the web. I think I've also seen a Facelets utility somewhere around Sourceforge that auto-creates the facelet-taglib's- does anyone have experience with that tool? Is it pretty much plug-'n'-play, or do a lot of components tend to need custom handlers?
dumb question about JARs
where are they? The Sandbox components don't seem to be in tomahawk-1.1.2xxx or myfaces-1.1.2xxx off the site, and although I do find references to sandbox.jar in posts here, for the life of me I can't find it anywhere online. Can someone point me in the right direction? Side question- I can look at the whole source tree in Eclipse (using SVN via Subclipse), and just copy-paste into my project, but I don't have a ton of confidence in my ability to pull in everything I need between /commons, /core, and /tomahawk/ Java source + resources. Is there a file(s) that explains exactly what goes into the various distribution JARs?--a Maven file I'm guessing? Thanks in advance- Rogers
best solution for partial page refresh
Hi,
I've been looking into different ways to partially refresh a JSF page
(actually a Facelets page) to get more responsive components (datagrids,
etc.), and have come up with a few options. Thought I'd see if anyone
on this list had strong opinions on one versus the others. I'm willing
to do client-side JS if necessary, but ideally the solution would be as
simple as adding an attribute in a JSF-ish tag.
Here's what I've found:
1) ADF Faces. Jacob Hookom did a blog entry in September with the
following code snippet from Oracle's ADF:
af:commandButton action=#{bean.method} partialSubmit=true/
af:commandButton text=Refresh Some Things partialSubmit=true id=refresh/
af:outputText value=#{oneValue} partialTriggers=refresh/
af:outputText value=#{anotherValue} partialTriggers=refresh otherRefresh/
This is exactly what I'm looking for (assuming there are af:datagrid,
af:xxx components for all the regular components), but I wasn't sure
whether or not the donated Oracle components include this partial
refresh capability. I've heard some components are only available in
the commercial release ... is this one of them?
2) ajaxanywhere http://ajaxanywhere.sourceforge.net/. A pretty clean
way to designate parts of the page to refresh. This project looks like
an option, but it does seem like triggering the partial refresh requires
you to call an ajaxanywhere-specific JS function--which is not a
dealbreaker, but less nice than the ADF method. My sense is I could
definitely make this work if the other two options aren't feasible yet.
3) JSF Avatar. Not much info out there about Avatar, but it seems to be
a Sun-powered extension of JSF that allows you to designate a
ProcessingContext, so that JSF can organically create just the
components that're asked for by an AJAX request. This one is
conceptually appealing, but it seems very nascent and I'm not sure how
usable it is. (only available in a Glassfish container? I need
something I can drop into Tomcat or Resin) I've read that the
server-side piece is implemented somewhere at Sun, and I'd be willing to
homebrew the client piece if necessary. Has anybody here actually used
Avatar? Do the Blueprints examples use Avatar? (haven't looked yet)
I know about some others (ajax tags, some jhook plan on the horizon for
a custom partial-page rendering engine), but these seem like the most
practical options for a project migrating to JSF today.
Only other requirement is that it works in Facelets. I'm even willing
to switch to RI (I know, I know- it's a MyFaces list) if that's required
for Avatar.
Any thoughts would be much appreciated. Thanks in advance-
Rogers
Re: best solution for partial page refresh
Thanks Jonas, that's great news. I've got the zip here
http://wiki.apache.org/myfaces/adfproposal and am going to give it a
shot. Is Facelets supported baked into that archive (the one from
wiki.apache/myFaces) somewhere, or do I need a separate jar to get ADF
tags working in .xhtml files?
on a side note- I just realized the book I preordered a couple days ago
is yours. Hope it's good! :-)
Jonas Jacobi wrote:
Hi Rogers,
The donation includes this functionality. The parts that are available
in the commercial solution (and not in the donation) are RenderKits
for Wireless and Telnet.
Partial Page Rendering should work out of the box :)
Thanks,
Jonas
Rogers Reilly wrote:
Hi,
I've been looking into different ways to partially refresh a JSF page
(actually a Facelets page) to get more responsive components
(datagrids, etc.), and have come up with a few options. Thought I'd
see if anyone on this list had strong opinions on one versus the
others. I'm willing to do client-side JS if necessary, but ideally
the solution would be as simple as adding an attribute in a JSF-ish tag.
Here's what I've found:
1) ADF Faces. Jacob Hookom did a blog entry in September with the
following code snippet from Oracle's ADF:
af:commandButton action=#{bean.method} partialSubmit=true/
af:commandButton text=Refresh Some Things partialSubmit=true
id=refresh/
af:outputText value=#{oneValue} partialTriggers=refresh/
af:outputText value=#{anotherValue} partialTriggers=refresh
otherRefresh/
This is exactly what I'm looking for (assuming there are
af:datagrid, af:xxx components for all the regular components), but
I wasn't sure whether or not the donated Oracle components include
this partial refresh capability. I've heard some components are only
available in the commercial release ... is this one of them?
2) ajaxanywhere http://ajaxanywhere.sourceforge.net/. A pretty
clean way to designate parts of the page to refresh. This project
looks like an option, but it does seem like triggering the partial
refresh requires you to call an ajaxanywhere-specific JS
function--which is not a dealbreaker, but less nice than the ADF
method. My sense is I could definitely make this work if the other
two options aren't feasible yet.
3) JSF Avatar. Not much info out there about Avatar, but it seems to
be a Sun-powered extension of JSF that allows you to designate a
ProcessingContext, so that JSF can organically create just the
components that're asked for by an AJAX request. This one is
conceptually appealing, but it seems very nascent and I'm not sure
how usable it is. (only available in a Glassfish container? I need
something I can drop into Tomcat or Resin) I've read that the
server-side piece is implemented somewhere at Sun, and I'd be willing
to homebrew the client piece if necessary. Has anybody here actually
used Avatar? Do the Blueprints examples use Avatar? (haven't looked
yet)
I know about some others (ajax tags, some jhook plan on the horizon
for a custom partial-page rendering engine), but these seem like the
most practical options for a project migrating to JSF today.
Only other requirement is that it works in Facelets. I'm even
willing to switch to RI (I know, I know- it's a MyFaces list) if
that's required for Avatar.
Any thoughts would be much appreciated. Thanks in advance-
Rogers
--
*Jonas Jacobi
Author*: Pro JSF and Ajax: Building Rich Internet Components
http://apress.com/book/bookDisplay.html?bID=10044
*Blog*: http://www.orablogs.com/jjacobi
Re: Dojo integration (was Re: 'Simulating' commandLink from Javascript')
Martin Marinschek wrote: Our final goal is to get rid of prototype and use dojo instead as our base-library for AJAX. So we want to further AJAXify our component set with the help of dojo, and replace the existing implementations with dojo-functionality. Fantastic, thanks for the clarification Martin. Sounds like Dojo will be used under the covers, then. At some point, it might be useful to expose which Dojo components are being loaded into the page, so developers can know which ones they're getting for free and don't need to load.
Dojo integration (was Re: 'Simulating' commandLink from Javascript')
Laurie Harper wrote: Hmm, OK, thanks; that makes sense. So, it's either time to start wrapping Dojo widgets with JSF components, or time to learn about Shale's remoting features ;-) Picking up on this- I'm just about to refactor two Dojo/JSP projects (one work, one personal) into Dojo/Shale/JSF/Hibernate projects, and this sliver of the stack is exactly what I'm wrestling with. My first thought was to define a relatively narrow Dojo interface for thick client-side stuff (letting MyFaces do simple stuff like autocompletes), keeping the server fairly decoupled, but now I'm wondering if they can be wired more tightly. Somebody posted on the Dojo mailing list about weaving Dojo libraries into MyFaces ... it wasn't clear (to me, at least) whether this was just for the purpose of using it for behind-the-scenes utility functions, or for AJAX-ifying current JSF components, or for wrapping Dojo widgets as Laurie mentioned. Does anyone know where MyFaces is going in this regard? I expect at first I'll be doing a lot of hand-wired Shale remoting in widgets, but it'd be great to have some idea of where to expect help in the future. -Rogers
