On Wed, Mar 23, 2011 at 3:02 PM, Marek Śmigielski <marek.smigielski@gmail.com> wrote:

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

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.

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?