On Wed, Mar 23, 2011 at 9:54 PM, Clint Popetz <cpopetz(a)gmail.com> wrote:
On Wed, Mar 23, 2011 at 3:02 PM, Marek Śmigielski
<marek.smigielski(a)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?
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