Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CollectionProvider] Returned columns are empty #26

Open
timgws opened this issue Feb 22, 2016 · 6 comments
Open

[CollectionProvider] Returned columns are empty #26

timgws opened this issue Feb 22, 2016 · 6 comments
Assignees
Labels

Comments

@timgws
Copy link
Member

timgws commented Feb 22, 2016

I am using d765c9f

Here is my controller code:

class DatatableTestController extends Controller
{
    public function test() {
        $t = Datatable::make(new CollectionProvider(Categories::all()))
            ->column('id') // show the id column of the user model
            ->column('name', null, Searchable::NONE(), Orderable::NONE()) // also show the full name of the user, but do not allow searching or ordering of the column
            ->build();

        if ($t->shouldHandle()) {
            return $t->handleRequest();
        }

        return view('admin.test.categories', array(
            'datatable' => $t->view()
        ));
    }
}

admin/test/categories.blade.php has the following code:

    <h1>Testing Datatable 0.2.1</h1>

    {!!
        $datatable
            ->headers() // tell the table to render the header in the table
            ->columns('id', 'id') // show # in the header instead of 'id'
            ->columns('name', 'name') // show 'Full name' in the header instead of 'name'
            ->endpoint(route('admin.datatabletest'))
            // render just the table
            ->table()
    !!}
    {!!
        $datatable
            // now render the script
            ->script()
    !!}

The endpoint works perfectly 👍

The AJAX request that is sent contains the following request parameters:

sEcho:1
iColumns:2
sColumns:
iDisplayStart:0
iDisplayLength:10
mDataProp_0:id
mDataProp_1:name
sSearch:
bRegex:false
sSearch_0:
bRegex_0:false
bSearchable_0:true
sSearch_1:
bRegex_1:false
bSearchable_1:true
iSortCol_0:0
sSortDir_0:asc
iSortingCols:1
bSortable_0:true
bSortable_1:true

and the response is:

{
    "sEcho": "1",
    "iTotalRecords": 5,
    "iTotalDisplayRecords": 5,
    "aaData": [{
        "id": "",
        "name": ""
    }, {
        "id": "",
        "name": ""
    }, {
        "id": "",
        "name": ""
    }, {
        "id": "",
        "name": ""
    }, {
        "id": "",
        "name": ""
    }]
}

Note the empty id, and name for each column, even though running dd(Categories::all()) shows that there is infact data inside the Collection.

(Note that my register function inside DatatableServiceProvider has been edited to force VersionEngine to only use Datatable19Version (I could not find a way to nicely have ->view render with the datatable19.blade.php Datatable javascript, but that's a story for another feature request).

@timgws timgws added the bug label Feb 22, 2016
@timgws timgws self-assigned this Feb 22, 2016
@timgws timgws added this to the Public Release milestone Feb 22, 2016
@timgws
Copy link
Member Author

timgws commented Feb 22, 2016

I thought it might have been caused by 5cfce36, however reverting this commit still shows the issue.

@timgws
Copy link
Member Author

timgws commented Feb 22, 2016

I found the cause. compileCollection inside CollectionProvider calls $this->callable with the default function being set by ColumnConfigurationBuilder, however, all of them fail on a collection.

After adding the following to the list of if's inside checkCallable:

                if (is_object($data) && property_exists($data, 'attributes')) {
                    return $data->$name;
                }

I no longer get empty values returned.

timgws added a commit to timgws/OpenSkillDatatable that referenced this issue Feb 22, 2016
@Chumper
Copy link
Contributor

Chumper commented Feb 22, 2016

(Note that my register function inside DatatableServiceProvider has been edited to force VersionEngine to only use Datatable19Version (I could not find a way to nicely have ->view render with the datatable19.blade.php Datatable javascript, but that's a story for another feature request).

You can use the Datatable::view() function, which will take a view as parameters. You still need to provide your columns, but maybe we can add a function on the view to set the view or even the version.

What about two options: view($viewTemplate) and version($version) ?

Oh and we should write a test for that bug :)

@timgws
Copy link
Member Author

timgws commented Feb 22, 2016

I will write a test for it in the morning. I want to find a more permanent/suitable solution than the one I have committed here too, if possible.

     ---- On Mon, 22 Feb 2016 22:08:49 +1100  [email protected]  wrote ----

(Note that my register function inside DatatableServiceProvider has been edited to force VersionEngine to only use Datatable19Version (I could not find a way to nicely have ->view render with the datatable19.blade.php Datatable javascript, but that's a story for another feature request).

You can use the Datatable::view() function, which will take a view as parameters. You still need to provide your columns, but maybe we can add a function on the view to set the view or even the version.
—Reply to this email directly or view it on GitHub.

@timgws
Copy link
Member Author

timgws commented Apr 27, 2016

@Chumper any idea for a better solution on timgws@8a1ff4f ?

timgws added a commit that referenced this issue Apr 27, 2016
Add comment for test which ensures there is
no regression on issue #26.
@Chumper
Copy link
Contributor

Chumper commented Apr 27, 2016

I have no answer offhand right now. I thought that a collection implements ArrayAccess and therefore should have a standard behaviour.

I guess we need to experiment with the default function if you are not happy with the current solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants