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:[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" <[EMAIL PROTECTED]>
>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
