[seam-dev] jsf in seam 3

[Pete Muir]

On 27 May 2009, at 05:59, Dan Allen wrote:

> Regarding the discussion of the design for StatusMessages...
>
> On Tue, May 5, 2009 at 7:59 AM, Clint Popetz <cpopetz at gmail.com>  
> wrote:
>  I want to
> point out that using a deployment type and @Specializes would seem to
> place us in the same situation as Seam 2.x with respect to the view
> layers co-existing in the same deployment, which
> https://jira.jboss.org/jira/browse/JBSEAM-3645 was meant to address.
>
> In other words, I'd rather that the choice of the StatusMessages bean
> that will be activated isn't based on deployment type, but rather is
> chosen at runtime based on the type of request, using the pattern in
> the patch for the above jira issue.  Deployment types would of course
> still be used to choose which implementations of things like
> StatusMessages are available.
>
> I have taken a first stab at solving this problem. I'm open to other  
> approaches, but first let me explain what I've done. As Clint points  
> out, from one request to the next, you may be dealing with different  
> frameworks (Wicket vs JSF for instance). But within the request, you  
> want to be able to take specific actions relating to the current  
> framework. Clearly, this is not the appropriate scenario for a  
> deployment type since that is design for a setting/environment that  
> is fixed. So I did some brainstorming.
>
> What I realized is that StatusMessages are really a generic  
> repository that should be updated and consumed by the framework- 
> specific activity. Therefore, it seems to me like there should be  
> one and only one conversation-scoped StatusMessages. Then, if you  
> want to have some extra methods for convenience (for instance in JSF  
> to add a StatusMessage from an existing FacesMessage) you create a  
> class which extends and wraps the StatusMessages component  
> (StatusMessages would be injected into it and all overrides  
> delegating to it). You could also override the onBeforeRender()  
> method where you might put the logic for converting and transfering  
> to the native message type and storage. The executor of that  
> conversion would be implemented in the framework-specific listener.
>
> For instance, 9 out of 10 times you simply inject the StatusMessages  
> to use in your application:
>
> @Current StatusMessages statusMessages;
>
> For JSF, there is a FacesMessages bean which inherits from  
> StatusMessages (to keep the API the same) and delegates calls to the  
> StatusMessages instance. It also adds the logic to create  
> FacesMessage objects in the onBeforeRender() method
>
> public void onBeforeRender() {
>     super.onBeforeRender();
>     // create FacesMessage objects and register them here
> }
>
> The ConvertStatusMessagesListener (a JSF system event listener)  
> executes the onBeforeRender() call.
>
> manager.getInstanceByType(StatusMessages.class, new  
> AnnotationLiteral<Faces>() {}).onBeforeRender();
>
> There are also some convenience methods on the FacesMessages  
> instance. If you want to use them, you inject as follows:
>
> @Faces FacesMessages facesMessages;
>
> I can't use @Current here because otherwise the resolution would be  
> ambigous. I could just clone the StatusMessages API in the  
> FacesMessages class to avoid having to use this binding type, so if  
> you have a feeling/advice there, I would be glad to here it.

This is a reasonable approach IMO.

>
>
> Okay, that's one approach. Now for something different. There is a  
> similar specialization w/ the Expressions class (an EL convenience  
> API). If working within the JSF request, we want to override some  
> methods so that the bean uses the current JSF EL context. In this  
> case, I decided to try Clint's approach described in the cited issue  
> report. A producer method will locate beans that have the binding  
> type @RuntimeSelected and will consult the isActive() method to  
> determine which one is prepared to handle the current request. The  
> isActive() method comes from the RuntimeSelectedBean interface. So  
> the bean must have both the binding type and the interface. There is  
> a second binding type, @Default, which indicates which  
> implementation should be used when there are no @RuntimeSelected  
> implementations present or active. It is mutually exclusive with  
> @RuntimeSelected.
>
> So you have:
> public @Default class Expressions { ... }
> public @RuntimeSelected class FacesExpressions extends Expressions,  
> RuntimeSelectedBean {
>     public boolean isActive()
>     {
>         return FacesContext.getCurrentInstance() != null;
>     }
> }
>
> public @RuntimeSelected class WicketExpressions extends Expressions,  
> RuntimeSelectedBean {
>     public boolean isActive()
>     {
>         return Application.exists();
>     }
> }
>
> The producer type for the Expressions bean is application-scoped and  
> the producer method is dependent-scoped (or request-scoped?). The  
> available instances are looked up when the producer is initialized  
> and the instance is selected from this set each time the producer is  
> resolved.
>
> Of course, I could have used this strategy for the StatusMessages  
> too, except in the case of StatusMessages it is logical to use the  
> shared/generic StatusMessages bean. It's only when you need to  
> convert the messages do you need the specialization and therefore I  
> think we can avoid having to do the runtime selection.
>
> I've committed all of this to the Seam trunk if you want to check it  
> out. I'm open to suggestions...I'm just trying to get used WB and  
> find a workable approach. The solutions we decide on are important  
> because the define a standard practice we will follow as more cases  
> arise.
>
> -Dan
>
> -- 
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://in.relation.to/Bloggers/Dan
>
> NOTE: While I make a strong effort to keep up with my email on a daily
> basis, personal or other work matters can sometimes keep me away
> from my email. If you contact me, but don't hear back for more than  
> a week,
> it is very likely that I am excessively backlogged or the message was
> caught in the spam filters.  Please don't hesitate to resend a  
> message if
> you feel that it did not reach my attention.
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20090528/61a9618a/attachment.html