[seam-dev] Wicket module features

[Pete Muir]

On 24 Mar 2011, at 13:05, Marek Śmigielski wrote:

> On Thu, Mar 24, 2011 at 1:14 PM, Pete Muir <pmuir at redhat.com> wrote:
>> 
>> On 23 Mar 2011, at 21:55, Marek Śmigielski wrote:
>> 
>>> On Wed, Mar 23, 2011 at 9:54 PM, Clint Popetz <cpopetz at gmail.com> wrote:
>>>> 
>>>> 
>>>> On Wed, Mar 23, 2011 at 3:02 PM, Marek Śmigielski
>>>> <marek.smigielski at gmail.com> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> In last few day I have deeply thought over wicket modul features
>>>>> essential to fully integrate with wicket framework. In wicket
>>>>> architecture there is idea of model as a state bean. Its quite
>>>>> different in terms of live cycle from scopes provided by CDI.
>>>>> 
>>>>> 1. It is page scope (in some cirumstances more than one http request)
>>>>> 2. It is serialized after each request and store in session or disk.
>>>>> 
>>>>> Wicket modules misses integration throught model object with wicket
>>>>> architecture so I've developed some integration with it. The idea is
>>>>> that you can achieve CDI beans exactly in the same way like in JSF,
>>>>> through expressionLanguage. So you can inject any named or other el
>>>>> bean via:
>>>>> 
>>>>>   @Inject @ModelExpression("#{nameBean}")
>>>>>   private SeamModel<String> label;
>>>>> 
>>>>> and later use it on your page directly:
>>>>> 
>>>>> Label label = new Label("headerLabel", headerLabelModel);
>>>>> 
>>>>> or wrap it by other wicket model:
>>>>> 
>>>>>   @Inject @ModelExpression("#{registartion}")
>>>>>   private SeamModel<Registartion> registartion;
>>>>> 
>>>>> 
>>>>> Form registrationForm = new Form("registartionForm", new
>>>>> CompoundPropertyModel(registartion));
>>>>> 
>>>>> and later use it on whole form.
>>>>> 
>>>> 
>>>> I'm not sure what benefit this provides.  The wicket page instance is
>>>> already a scope, if you wanted something specific to the page, you could
>>>> just add it as a field to the page or component.  And EL as a referencing
>>>> mechanism is a little too JSF-esque (weakly bound, not refactoring safe) to
>>>> be well suited to a wicket integration layer.
>>> I think that it's worth to have some way of injection components
>>> straight to wicket model beans. Duplication of the fields between
>>> wicket page and request component (or any scope component) in my
>>> opinion is unnecessary. I agree that EL and wicket concept don't fit
>>> well, but I haven't had any other idea how to inject a bean to wicket
>>> page wrapped with Model interface without EL. Now I realize that if I
>>> can get actualType of class form injection point, I can also resolve
>>> targeted bean in typesafe way. SeamModel bean may be very similar to
>>> InstanceImpl class from weld core. What do you think?
>> 
>> You mean you need to know the generic type of the injection point?
>> 
>>   protected static Type getFacadeType(InjectionPoint injectionPoint)
>>   {
>>      Type genericType = injectionPoint.getType();
>>      if (genericType instanceof ParameterizedType )
>>      {
>>         return ((ParameterizedType) genericType).getActualTypeArguments()[0];
>>      }
>>      else
>>      {
>>         throw new IllegalStateException(TYPE_PARAMETER_MUST_BE_CONCRETE, injectionPoint);
>>      }
>>   }
>> 
>> Does that.
>> 
>> I would be very against introducing EL into Wicket, it completely removes a key benefit of Wicket.
>> 
> I understand problem with EL and Wicket. I have modified the way
> SeamModel(wrapper over actual bean that implements IModel) is produced
> by throwing out qualifier with EL. I have Implemented SeamModel get
> wrapped bean method, based on get method of InstanceImpl class and
> this one works as expected. I can now inject bean like that:
> 
> @Inject
> SeamModel<Registration> registration;
> 
> 
> but when I have any other qualifier besides @Inject,
> 
> @Inject @UserRegistraion
> SeamModel<Registration> registration;
> 
> CDI search for SeamModel bean with this qualifier and throws
> unsatisfied dependency injection. What I try to achive is to have
> posibilty to inject SeamModel in exactly the same way that Instance
> component is injected or to have producer method which satisfied all
> qualifiers.

In Weld we register Instance as having the @Any qualifier only, which means it resolves for all IPs. Then we apply the qualifiers at the IP at a later date.

> 
> 
> 
>>> 
>>> As to benefits, besides saving few lines of code on each page, you get
>>> very safe way of injection beans from any CDI scopes. Injecting
>>> request scope beans into a page isn't safe at all and for some
>>> developers can be not natural. The same applies to situation when your
>>> conversation scope timeouts or was destroyed. If you injected that
>>> bean into wicket page it will hold reference to your object and cause
>>> unstable behavior.
>>>> 
>>>>> 
>>>>> As I follow seam 3 for some time now I understand that this is time
>>>>> for bugfix rather than adding new features. Is it possible to merge
>>>>> this code before final realese?
>>>>> 
>>>>> Second feature is rather small and not soo excited as previous one.
>>>>> I've prepared possiblity to inject ResourceStreamLocator. Deafault is
>>>>> exactly the same as in wicket but I had also developed alternative
>>>>> one, which enables throught configuration to change the place where
>>>>> html file are stored. In my opinion it's also simplification.
>>>>> 
>>>> 
>>>>  Wicket already has a way to register resource stream locators, I don't see
>>>> why we need a yet another way to do it.  Can you elaborate?
>>> It depends how many features would you like to have in wicket module.
>>> But as I review why I put it in wicket module instead of my project (I
>>> wrote it a month ago), I can't find any strong arguments. It would be
>>> better to have wicket module as simple as possible so forget about it.
>>>> 
>>>> -Clint
>>> 
>>> Marek Smigielski
>>> 
>>> _______________________________________________
>>> seam-dev mailing list
>>> seam-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>> 
>>