>From: "Marcio E Miranda" <[EMAIL PROTECTED]> > > That's what I understood from the documentation in the website, but the fact > is > that I get an error (the browser shows an exception) if I don't register a > managed bean with the same name of the view. > > And the error has nothing to do with a component backing bean. The same > application that works fine without Shale, start to show this error message > after adding the Shale configurations in the web.xml. > > Could you please confirm if the following filter is requited by Shale (I'm > using > this in my web.xml): > > ><!-- Shale Application Controller Filter --> ><filter> > <filter-name>shale</filter-name> > <filter-class>org.apache.shale.faces.ShaleApplicationFilter</filter-class> > </filter> > ><!-- Shale Application Controller Filter Mapping --> ><filter-mapping> > <filter-name>shale</filter-name> > <url-pattern>/*</url-pattern> > <dispatcher>REQUEST</dispatcher> > <dispatcher>FORWARD</dispatcher> > </filter-mapping> > > > If not, maybe this is the cause of the strange behavior. >
This looks correct. You might check to see that the "<dispatcher>" nodes are supported. > Regarding the portlet issue, you mean that Shale adds a requirement to the > portlet container? So it means that I might not be able to deploy my portlet > application in some portal vendor because I use Shale? > I believe that is a true statement but portal talk is outside of my domain but from what I understand, not all portals support filters. > - Marcio > > -----Original Message----- > From: Gary VanMatre [mailto:[EMAIL PROTECTED] > Sent: sexta-feira, 24 de março de 2006 12:22 > To: Struts Users Mailing List > Subject: Re: Is Shale supposed to work in a portlet environment? > > >From: "Marcio E Miranda" > > > > Hi, > > > > > > > > First of all, there is one point in Shale that I didn't understand very > > well. Why the developer has to register a managed bean for each view? > > > The shale ViewController adds additional lifecycle events to the vanilla JSF > lifecycle. This is accomplished without hooking into a specific > implementation > of JSF. The solution is loosely coupled and it's not a requirement that you > associated every page with a ViewController. The mechanism for the extra > callback events are on the ViewController. The view controller is a managed > bean that is associated with a page by it's view id. > > > > When I try to access a page without registering a bean with the same > > name of the view in faces-config.xml, I get an error from Shale stating > > that the expression #{myviewname} could not be evaluated. If I then > > register a bean with the same name of the view in faces-config.xml, it > > works. There is no such a requirement in a JSF application that doesn't > > use Shale. > > > > The error that you are seen has to do with binding a component to a backing > bean > using a expression language (EL) binding. You would see this error regardless > of having Shale in the picture. > > If you don't have a ViewController associated with a page, you will see a > *warning* message in the log. > > WARNING: No ViewController for viewId /usecases.jsp found under name usecases > > Besides the ViewController, the Shale subview component adds a "prerender" > callback event on the view controller. > > I really like the new tiger annotations that allow you to register managed > beans > without XML. This makes it easy to register view controllers. > You are also able to make a view controller out of any managed bean and give > your own method signatures to the callback events. > > For example: > > /** > * Sample ViewController > * class for /examples/dataList.html. > */ > @Bean(name="dataTable", scope=Scope.SESSION) > @View public class DataTableBean { > > > @Prerender public void loadPeople() { > people = new ArrayList(); > for (int i = 0; i < 10; i++) { > BasicPerson person = new BasicPerson(); > person.setFirstName("First" + i); > person.setLastName("Last" + (10 - i)); > people.add(person); > } > } > > private List people = null; > public List getPeople() { > return people; > } > > } > > > > > > > Now to the portlet issue. I have a portlet application, which uses > > Shale, that runs fine in a web container (note that I had to define a > > managed bean with the same name of the view for it to work). Then, I've > > deployed the same application in a portlet container (Liferay). When I > > try to access the portlet, I get an error stating that the expression > > #{index} could not be evaluated. I checked the stack trace and realized > > that the exception was raised by the Shale controller (seems to me that > > this is the same issue described above). What is the workaround? Is > > Shale supposed to work in a portlet environment (I'm using the portlet > > implementation provided by My Faces)? > > > > Shale requires the portlet container to implement filters. > > > > > > > > - Marcio. > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
