[seam-dev] jsf in seam 3
Drew Kutcharian
drew at venarc.com
Wed May 27 01:30:02 EDT 2009
Dan,
I really like the both approaches and I think method is appropriate
for the specific use case the only thing is if all that runtime
selection stuff happen per request, wouldn't that be a performance
killer? I know the those call times are minuscule, but if that would
become a pattern for the rest of the framework, those numbers could
really add up.
Now why would someone really mix Wicket and JSF together in a single
app? In addition, if you do want to allow that runtime selection and
allow users to mix and match different view frameworks at runtime,
then you need to think about a page that has both JSF and Wicket
elements on it, for example a portal style app. Then you really need
to think about who consumes what/when.
cheers,
Drew Kutcharian
Chief Technology Officer
Venarc Inc. www.venarc.com
Phone: 818-524-2500
On May 26, 2009, at 9:59 PM, 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.
>
> 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/20090526/1211a357/attachment.html
More information about the seam-dev
mailing list