[seam-dev] Wicket module features

Pete Muir pmuir at redhat.com
Thu Mar 24 08:14:55 EDT 2011


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.

> 
> 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




More information about the seam-dev mailing list