struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcio E Miranda" <Marcio.E.Mira...@fastsearch.com>
Subject RE: Is Shale supposed to work in a portlet environment?
Date Fri, 24 Mar 2006 17:10:48 GMT
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.

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?

- Marcio

-----Original Message-----
From: Gary VanMatre [mailto:gvanmatre@comcast.net] 
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" <Marcio.E.Miranda@fastsearch.com> 
>
> 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: 

/**
 * <p>Sample <code>ViewController</code> 
 * class for <code>/examples/dataList.html</code>.</p>
 */
@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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message