And yes, I think this is definitely useful for a view layer (one of our main targets for UEL AFAIK). For example, you could use to write a way to skip the login page if the user is already logged in (of course, there are other ways to write this, but it's an easy to understand idea ;-)
<!-- Example JSF tag to register a listener for the view which gets notified of each stage of the JSF lifecycle -->
<f:registerListener bean="#{loginPageControllerBean}" />
and, assuming you use CDI as the bean container:
@Named
class LoginPageControllerBean {
@Inject
NavigationHandler navigation;
@Inject
boolean alreadyLoggedIn;
@InvokeBefore(RENDER_RESPONSE)
void checkAlreadyLoggedIn() {
if (alreadyLoggedIn) {
navigation.handleNavigation(facesContext, null, "home");
}
}
}
On 13 Apr 2010, at 11:25, Pete Muir wrote:
> Thanks Lincoln, it's much clearer to me what you mean now. I would express this as "the ability to resolve the *bean* using EL, and then invoke a method on the bean using reflection (e.g. annotations, method name pattern matching)".
>
> On 12 Apr 2010, at 20:18, Lincoln Baxter, III wrote:
>
>> I'm sure I'm not being clear ;)
>>
>> Let me ask a question.
>>
>> Assuming the following constraint:
>> • No given dependencies to any one given bean-container, just knowledge that a bean container exists, and that it is registered with the ELContext
>> How would you write a bean-container-portable extension (spring, guice, cdi, faces, other...,) using annotations, to invoke methods on Beans via EL?
>>
>> @Named("service") //CDI
>> public class BusinessService {
>>
>> @InvokeBefore(RENDER_RESPONSE)
>> public String doSomething()
>> {
>> return "success";
>> }
>> }
>>
>> In this scenario, @InvokeBefore should be the equivalent of using EL: #{service.doSomething()}
>>
>> --Lincoln
>>
>>
>> On Mon, Apr 12, 2010 at 7:44 AM, Pete Muir <pmuir_at_redhat.com> wrote:
>>
>> On 11 Apr 2010, at 20:40, Lincoln Baxter, III wrote:
>>
>>> Exactly the scenario I mentioned above ;) Someone creates a framework (like prettyfaces) and wants to provide annotation support, but doesn't want to depend on CDI, Spring, Juice, or other implementations. However, there *is* a dependency on EL, which ends up being an abstraction over these containers.
>>>
>>> Because EL already knows the names of the beans, and the classes of the beans (I think?) it can probably generate a list of names for each Bean Class. This would allow products to invoke EL via annotations
>>
>> I'm sure I'm being obtuse, but I don't understand what this means, let alone how you would use it....
>>
>>> without knowing which Bean-container is in use -- there may even be multiple bean-containers.
>>>
>>> It would be possible to write extensions for each bean-container, but resolving against the EL would be much more portable, since it is already the home for bean names in Java EE / Java web-tier.
>>>
>>> --Lincoln
>>>
>>> On Fri, Apr 9, 2010 at 6:43 AM, Pete Muir <pmuir_at_redhat.com> wrote:
>>> What scenarios do you see this being useful in?
>>>
>>> On 1 Apr 2010, at 00:06, Lincoln Baxter, III wrote:
>>>
>>>> I'm seeing benefit for a TypeMapper or NameMapper off of the ELContext object.
>>>>
>>>> When working with Bean Containers, each container has a different API for looking up beans and getting information about them. For instance, if I wanted to know what names were associated with a bean of type "com.ocpsoft.MyBean," there's currently no way of doing that through EL. I can go out to the bean containers themselves in order to get that information, but EL hides it.
>>>>
>>>> The use case:
>>>> I've annotated a class, and a method on that class, and want to use that annotation to invoke an operation on that bean:
>>>>
>>>> @ExtensionDefined
>>>> @javax.enterprise.context.Named("something")
>>>> public class MyBean {
>>>>
>>>> @ExecuteThis
>>>> public void action() {}
>>>>
>>>> }
>>>>
>>>> The custom annotations' scanner has access to the Class Type, but without providing direct support for Spring, CDI, Seam, Guice, JSF, etc -- has no idea what that class is named in the EL.
>>>>
>>>> The ELContext has hooks into whatever bean-container backs it (if there even is one -- it could be completely custom) and can provide names for a given type.
>>>>
>>>> So:
>>>>
>>>> @Inject ELContext context; //assume this works for example purposes...
>>>> TypeMapper mapper = context.getTypeMapper();
>>>> Set<String> names = mapper.getNames(Class<?> clazz); // lists all names for which the provided type is registered.
>>>>
>>>> This is a very rough concept, but what do you think? I think the value is there, but specifics need to be worked out.
>>>>
>>>> --
>>>> Lincoln Baxter, III
>>>> http://ocpsoft.com
>>>> http://scrumshark.com
>>>> "Keep it Simple"
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: el-next-unsubscribe_at_uel.dev.java.net
>>> For additional commands, e-mail: el-next-help_at_uel.dev.java.net
>>>
>>>
>>>
>>>
>>> --
>>> Lincoln Baxter, III
>>> http://ocpsoft.com
>>> http://scrumshark.com
>>> "Keep it Simple"
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: el-next-unsubscribe_at_uel.dev.java.net
>> For additional commands, e-mail: el-next-help_at_uel.dev.java.net
>>
>>
>>
>>
>> --
>> Lincoln Baxter, III
>> http://ocpsoft.com
>> http://scrumshark.com
>> "Keep it Simple"
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: el-next-unsubscribe_at_uel.dev.java.net
> For additional commands, e-mail: el-next-help_at_uel.dev.java.net
>