CDI MVP add-on

The add-on was formerly part of a plugin called CDI Utils. CDI MVP was extracted as an individual add-on a month ago due to various reasons and the API was partially changed/cleaned up in the process. Applied changes stem mostly from the user feedback and better insight gained in personal use.

From the users’ point of view the current API should be quite stable. I might add some functionality regarding the compatibility with Vaadin Navigator (as discussed earlier in this thread) but any future change should not invalidate the existing API.

Sounds strange indeed. Really can’t say what can cause such behaviour on your staging server.
Anyway, I’ll change the beans.xml to the simple version for the next release to avoid this in the future.

Thanks for the Navigation source files. I’ll take a look asap.

Hi Tomi,

Thanks for the explanation, everything is clear for me now.
Is the beans.xml planned to be integrated to the official release ?

Because right now, I have no choice but recompile myself de vaadin-client with the beans.xml right ?

I don’t think Vaadin core libraries will nor should contain the beans.xml file. Wouldn’t recommend compiling a custom build of the libraries just for this purpose either.

However, if you do want to @inject a Vaadin core component in your project, there are some options:

[b]

  1. Create producers in your own project
    [/b]
@Produces
public Button createButton(){
    return new Button();
}

This allows you to change the injected Button later on if you wish (by adding a styleName for all you buttons at once or changing the implementation to NativeButton etc.). Like so:

@Produces
public Button createButton(){
    Button button = new NativeButton();
    button.addStyleName("mybutton");
    return button;
}

(Using a qualifier wouldn’t hurt here either)


2. Create a Button extension in your project

public class MyButton extends Button{...}


3. Use the @XXProperties qualifier (CDI Properties contains the necessary producers)

@Inject
@ButtonProperties
private Button button;

That’s great, thank you for your help Tomi !

Hi,

I’m trying to use sub-windows in my app to modify some values.
I’m using CDIViews and using the fireViewEvent(…) method to call my EJB and I would also like to use this method in my own subwindows.

The problem is I need to extends Window therefore I can’t extends ViewComponent too.
Any ideas how I can reach the presenter class using fireViewEvent(…) from a subwindow using the MVP Pattern ?

Thanks a lot,

Cédric

The Content you want to display should be a View or extends ViewComponent.

I prefere to display a separate View imlementation in my SubWindows, but note there is a pitfall you should take care when displaying a View in a SubWindow , Views are currently UIScoped and thus you have one instance per UI, you cannot have two windows displaying the same View …

Usually I dont even create a subclass of Window, I simply initialize the window from where I want to display it…

    @Inject
    private Instance<WorkOrderEntryEditView> editView;

@Override
    public void editWorkOrderEntry(final AbstractWorkEntry entry) {
        final com.vaadin.ui.Window pop = new com.vaadin.ui.Window();
        pop.setCaption("Equipment Entry");
        final WorkOrderEntryEditView view = editView.get();
        view.enter();
        view.setWorkOrderEntry(entry);
        pop.setWidth(600.f, Unit.PIXELS);
        pop.setContent(view);
        pop.setClosable(false);
        pop.center();
        pop.setResizable(false);
        pop.addCloseListener(this);
        pop.setModal(true);
        UI.getCurrent().addWindow(pop);
    }

Great idea, I haven’t thought about doing it that way.
Thanks a lot !

Hi,

I’m using this addon in addition to the other vaadin-cdi-add-ons. Works like a charme.
Now I want to test my application. Here I run in a lot of problems. Which test-framework can you recommend? I tried CDI-Unit.

Hi Dennis

Haven’t tried CDI-Unit myself so can’t say much about that. But in general, for testing CDI applications I’d go with Arquillian (
http://arquillian.org/
).

Hi Tomi,

is there a way to use “@XXProperties qualifiers” with subclasses of the vaadin components?

Can I do something like:
@Inject @TextFieldProperties(captionKey = “someKey”)
protected MyTextField someString;

If that does not work: where can I find the source code of org.vaadin.addon.cdiproperties.producer.ComponentProducers?

Thanks a lot in advance,
Jürgen

Hello Jürgen
You may use the TextFieldProperties annotations with subclasses as well but then you’ll need to specify the “implementation” -property.
Also, the field must be of type TextField

@TextFieldProperties(captionKey = “someKey”, implementation = MyTextField.class)
protected TextField someString;

Tomi

Great, thank you! That was what I was looking for!

By the way: I couldn’t find the code for org.vaadin.addon.cdiproperties.producer.ComponentProducers on github. Is it available somewhere else?

Thanks again,
Jürgen

ComponentProducers is a generated java file so it’s not committed to the repository.

Hi Tomi,

while I got the “implementation”-property working, it seems that Injection into implementation classes does not work (also: @PostConstruct is not executed).

Are those implementation instances created with “new”? Is there a way to use CDI with implementation classes?

Thank you,
Jürgen

That’s correct. It won’t work as a cdi-bean as it’s instantiated with reflection.

Hi,
it seams to me, that the CDI-MVP package is broken, since Vaadin CDI 1.0.0.beta4.
On @UIscoped CDIVIEWs the presenter get’s a different View injectet than the one that is used for the user interaction.
I also tried to update to the version from git that should work with 1.0.0.beta4 but in this package the navigation test fails with the same issue.

Any hints how to get this working again ?

Stefan

Have the same problem. I’m not sure if that is a problem caused by the add on. there is a
ticket
for this issue. Anyhow is there a quick workaround available ?

Yeah it’s a Vaadin CDI problem and unfortunately the issue still remains :frowning: I tried tweaking CDIViewProvider a bit so that the referred test passes but can’t really tell if it’s correct otherwise. Added it as an attachment.
18506.java (12 KB)

Good addon!
I suppose you would make new release to compatibilize with new ones of vaadin-cdi when the referred issue went live, wouldn’t you?
So, by right now, can you recommend which version of vaadin-cdi we should use with your last release?

I am obtaining this error when starting AS, due to compatibility with vaadin-cdi lates’t version:

Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000040: All stereotypes must specify the same scope OR a scope must be specified on Merged stereotype model; Any of the stereotypes is an alternative: false; possible scopes [@com.vaadin.cdi.UIScoped(), @com.vaadin.cdi.ViewScoped()]

The problem is that I have some classes maked with @CDIView annotation (which in lastest versions is @Stereotype @ViewScoped); and the AbstractMVPView included in the addon is @UIScopedStereotype (@Stereotype @UIScoped).
This causes the conflict above.

How about this 2 alternatives
1 creating a new @ViewScopedStereotype to syncrhonize with @CDIView and mark this AbstractMVPView?
2 removing stereotype from AbstractMVPView?

Or Are there any other suggestions to avoid this conflict?