[seam-dev] Wicket module features
Pete Muir
pmuir at redhat.com
Thu Mar 24 10:24:20 EDT 2011
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
>>
>>
More information about the seam-dev
mailing list