JPAContainer fieldFactory upgrade impossible?

The current jpacontainer.fieldfactory implementation is using the deprecated Form. However, upgrading it to use FieldGroup instead looks non-trivial or even impossbile, since the FieldGroupFieldFactory interface differs significantly from the deprecated FormFieldFactory interface, because it does not have the propertyId in the createField method.

So a FieldGroupFieldFactory implementation would not be able to create fields based on the JPA/bean annotations of the property, or am I missing something?

You are not missing something.
However all is not lost, I had to make some major changes to the FieldFactory provided by JPAContainer in a previous project and though it was no small task to integrate all our needed changes , it was not a massive undertaking either…

Basically I copied the source from JPAContainer ( Only the classes I absolutely needed to copy, there is quite a few though ) to a new package ( ie refactoring ). Once you have your own version of the Factory working, 90% of the battle is won…

Alternatively you can get a Pro Account and get the Vaadin team to prioritise a ‘new’ FieldGroupFieldFactory for JpaContainer…

Hi Petrus,

Thanks for your response.

The problem lies not within the current implementation of the JPAContainer or its FieldFactory (besides being outdated), but in the fact that a FieldGroup cannot pass the required information (the name of the property) to a FieldGroupFieldFactory.

So I don’t see how copying/altering parts of the current implementation would get me to a point where I can use it like I want to:


Layout formLayout = new FormLayout();
FieldGroup fg = new FieldGroup();
fg.setFieldFactory(new JPAContainerFieldGroupFieldFactory(personContainer));

// 'friends' property cannot be passed to JPAContainerFieldGroupFieldFactory through
// FieldGroupFieldFactory#createField(Class<?> dataType, Class<T> fieldType)
formLayout.addComponent(fg.buildAndBind("friends", "friends"));

I’m writing my own “EntityFieldFactory” mechanism now, and use it like this:


Layout formLayout = new FormLayout();
FieldGroup fg = new FieldGroup();
EntityFieldFactory fieldFactory = new EntityFieldFactory();

for (String propertyId : properties) {
    Field field = entityFieldFactory.createField(entityType, propertyId);

    if (field == null) {
        // use the default FieldGroupFieldFactory
        field = fg.buildAndBind(propertyId.toString(), propertyId);
    }
    else {
        field.setCaption(propertyId.toString());
        fg.bind(field, propertyId);
    }

    formLayout.addComponent(field);
}

So my EntityFieldFactory will probably end up containing all the current JPAContainer fieldfactory smartness, but this is clearly a work around.

Please
create an enhancement request
about what information should be available where but isn’t. A few words in the ticket about why this is needed would also be good.

I’m not quite sure that a change request is needed.
The factory has changed in that it no longer gets access to the propertyID of the property it needs to generate a field for, it only gets the Type of the property.
If you have very specific behavior override it is the FieldGroup that should(currently in v7.x) make this decision and generate appropriate fields ( via factory or something else ).

This is not a JPAContainer issue , but a Vaadin 7.x philosophy/pattern change.

It is indeed not a JPAContainer issue (I think I did not state that), but indeed a philosophy/pattern change: one that limits the possibilities of the FieldGroupFieldFactory (compared to the old FormFieldFactory) - which to me looks like the natural thing to plugin if you want (very) specific Fields created.

If you suggest to let the FieldGroup make such decisions via a factory, why not use FieldGroupFieldFactory?

Any way, I will create an enhancement request, and maybe it can be decided there.

Can’t login at dev.vaadin.com (maybe need to turn pro?), I leave it at this.

Did you try to register a new account on dev.vaadin.com (top right corner)?
Anybody should be able to do that and those accounts are separate from vaadin.com accounts.

Found a similar issue - dropped a comment there:

http://dev.vaadin.com/ticket/9748

Not clear what the status / resolution is.

I have same issue. I looked quickly in the code, and it seems to me that it’s not big deal to add propertyId into factory call. It’s in Field group on two places right ?

I also want to access propertyId inside the createField method od FieldGroupFieldFactory. Is it possible?? If yes how??

Yup, FieldGroupFieldFactory API makes it impossible to automatically generate FieldGroup based forms with One-to-Many and Many-to-Many relationships the way it was possible with old Forms. This is a very serious stepback and someone from Vaadin dev team should investigate this issue. If the old Forms will be removed in 8.0, all devs that currently use JPA Container with it’s automatic form generation won’t be able to upgrade.

I agree, I have developed in the past with Vaadin6 and now I started a new project with Vaadin7. I promised quick developing time thanks to Vaadin power but now I see I have to use deprecated Forms because I see that new FieldGroup is less powerful.
But the thing I do not understand is this: since now Vaadin is at 7.3.5 (and not 7.0.0) how it is possible that no alternative solution is presented? Am I missing something? Is there a better way to do it and I am not seeing it?
Do other developers use another strategy?
Thanks for interest,
Mario

Hi,

Too many developers are just quiet and don’t complain about bad API. The current API was developed by framework developers, not users adapting it to real use cases :frowning:

The new FieldGroup API is really good if you use a pre created form views and then just bind that into the bean you are editing. But for autogeneration I know from experience that it just don’t work (you can see my name in the ticket :wink: ). I most often prefer the pre created strategy, but I think both have their use cases so Vaadin should definitely fix this somehow. I’d drop the “autogeneration” features from the (Bean)FieldGroup altogether and remove the deprecated annotation from Form (and possible make some enhancements to it). Then From should be used when autogenerating the UI and (Bean)FieldGroup when using the pre created strategy.

cheers,
matti

Thanks for your explanation you read in my mind…
Anyway you gave me an idea: I can accept to create the form on my own and to bind it. But now is there a way to quickly create a onetomany widget? So I can drag&drop all widgets using eclipse plugin and then fire autobind. Better than nothing but only if there is a onetomany widget I suppose.

I add also that also using the old Form can be very difficult:

https://vaadin.com/forum#!/thread/1296615

So basically I am trying all ways and I am stuck in each direction… :frowning:

Hi,

That is another thing that should be solved somehow in the framework to make form generation simpler. In my V6 era SmartFields project I had
a service
that OneToMany & ManyToMany fields used automatically to get available selections. If you have lots of autogenerated views, I think you should create something similar (but probably with more meta data than in my that my old project).

cheers,
matti