[seam-dev] Wicket module features

Fri Mar 25 04:51:58 EDT 2011

On Thu, Mar 24, 2011 at 10:45 PM, Clint Popetz <cpopetz at gmail.com> wrote:
>
>
> On Thu, Mar 24, 2011 at 8:05 AM, Marek Śmigielski
> <marek.smigielski at gmail.com> 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.
>>
>
> Do you have a fork on github I can check out?
Yes, but only with el version for now.

https://github.com/smigielski/wicket/tree/SeamModel

For model class
https://github.com/smigielski/wicket/blob/SeamModel/impl/src/main/java/org/jboss/seam/wicket/SeamModel.java
and for producer:
https://github.com/smigielski/wicket/blob/SeamModel/impl/src/main/java/org/jboss/seam/wicket/SeamModelProducer.java

If you would like to see how it is then use on Wicket page it here:
https://github.com/smigielski/wicket/blob/SeamModel/mock/src/test/java/org/jboss/seam/wicket/test/application/page/ELRequestTestPage.java

>  Because I'm still not clear
> on what is being done.  What gets injected when you inject "registration"
> above.  Does it store its injection point data and use that to lookup the
> bean through the BeanManager api on each call to Model.getObject()?
> -Clint

I still don't have working example with lookup without el. The idea is
that bean is cached in model for whole request and at the end it is
detach. Just like LoadableDetachableModel works.

When I will manage to finish new way of resolving beans, I will put it
on github and sent you the link.

>>
>> >>
>> >> 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
>> >
>> >
>
>
>
> --
> Clint Popetz
> http://42lines.net
> Scalable Web Application Development
>