On Thu, Mar 24, 2011 at 1:14 PM, Pete Muir <pmuir@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@gmail.com> wrote:
>>>
>>>
>>> On Wed, Mar 23, 2011 at 3:02 PM, Marek Śmigielski
>>> <marek.smigielski@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.

>>
>> 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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>