p:datatable selection problem after upgrade to PF 5.2 RC

[djmj]

What about enhancing this approach using a JSF converter since it follows the same conversion idea and provides a clean reusable interface?

In my generic DAO's my overriden methods simply call the converter method.
A converter could also be passed to datatable attribute in markup as in any other component.

Code: Select all

public class MyJsfGenericDAO <T extends Entity> extends LazyDataModel<T>
{
	private final Converter converter;

	public MyJsfGenericDAO(...)
        {
            this.converter = new MyEntityConverter(entities);
        }


	@Override
	public Object getRowKey(final T t)
	{
		return this.converter.getAsString(FacesContext.getCurrentInstance(), null, t);
	}

	@Override
	public T getRowData(final String rowKey)
	{
		return (T) this.converter.getAsObject(FacesContext.getCurrentInstance(), null, rowKey);
	}
}

[rider]

why did you change this?
I cannot find any advantage for this! Why changing a running system?
For me it´s a showstopper to migrate to 5.2. I have ± 100 lazy datatables in my application.
I have to adjust all this lazy datatables. I´m sorry but this is wasting my time

[kukeltje]

If I read it correctly, many (including me) used it not like it was intended. So from the PF point of view they did not change it or at least did not break backwards compatibility. But someone from the PFteam may state otherwise.

I am btw lucky. My LazyJPADatamodel uses genericks, so chaning one file fixes it for all (ok almost all, not the few ones with composite keys).

[matsa]

I've got a non-lazy related problem with this upgrade:

For non-lazy tables I use a generic data model like this:

Code: Select all

class GenericDataModel<T> extends ListDataModel<T> implements SelectableDataModel<T>, Serializable

Selection on this model has worked fine because I've implemented getRowKey/getRowData thusly:

Code: Select all

@Override
    public Object getRowKey(T object)
    {
        return container.getConverter().getAsString(FacesContext.getCurrentInstance(), null, object);
    }

    @Override
    public T getRowData(String rowKey)
    {
        return (T) container.getConverter().getAsObject(FacesContext.getCurrentInstance(), null, rowKey);
    }

On upgrade to 5.2(.1) this data model stopped working. None of the data tables had the rowKey attribute defined and selections are always empty. I understand how rowKey makes sense when using list as data model directly but in this case I've implemented SelectableDataModel.

[holden]

Hi *,

I get the same problem with data table selection, the returning set is always empty.
Also ajax selection events are triggered, but the event.getObject returns null.
This problem occurs since 5.2 RC and is still present with 5.2(.2).

On upgrade to 5.2(.1) this data model stopped working. None of the data tables had the rowKey attribute defined and selections are always empty. I understand how rowKey makes sense when using list as data model directly but in this case I've implemented SelectableDataModel.

Can you kindly check it?

Regards,

[holden]

Hi *,

I get the same problem above, with no lazy loading and selection: the selected set is always empty;
the ajax selection event is triggered but event.getObject returns always null.

The issue occurs since 5.2 RC, and it's still present in 5.2.2

Can you kindly check it?

Regards

[juanise]

I prefer the old system, I do not know why you restrict the way we use datatables, in my case a have a lazy datatable that mix entities from database and others from my app.
It works ok before I update to 5.2.

[matsa]

Someone at PrimeTek should really respond to this. I've gotten great value from the SelectableDataModel I've described in my previous post and I won't be able to migrate beyond 5.1 until someone tells me how to handle this.

[tandraschko]

There is already a issue: https://github.com/primefaces/primefaces/issues/229
We will fix it as soon as possible.

[matsa]

That's great!

It seems to be a duplicate of: https://github.com/primefaces/primefaces/pull/230

There's already a pull request available it seems!

Looking forward to moving past 5.1.