Downloading result sets as xls or csv about laravel-administrator

[gilr]

CSV and XML? And why not XLS... PDF could be great... Json is offered by some admin generator too.
Another option could be to select either "displayed columns" or "all table columns"... or to be able to add or remove any colums of the displayed list :)

The symfony2 sonata admin bundle can give some great ideas: http://demo.sonata-project.org/admin/login (admin / admin).
Or this article (django), but in french: http://www.clever-age.com/veille/blog/l-admin-generator-de-django-vu-par-un-developpeur-symfony.html

[janhartigan]

Hey @gilr. Thanks for the suggestions! I'm not really at the point where I'm ready to implement this just yet, but it's been at the back of my mind for a week or so. In an ideal world, I think this would include support for:

• CSV, XLS, and JSON (not so sure about XML or PDF...the latter simply because the last time I looked at PDF generators, they were a massive pain in the ass)
• Downloading the visible result set. This would include the filters. Ideally, we'd want to make it clear in the downloaded file what those filters are, so there's no confusion for anyone who receives that file.
• Downloading the database table that this model represents

I was toying around with the idea of letting developers define even more result sets to download (based on the column option syntax) for any given model, but we'd need to come up with a clever way to present all these options without cluttering up the layout.

[gilr]

I didn't think about filters, but of course it's a great idea. Having these two options: current filters (yes/no), and columns (visible/all) should satisfy a large range of users' needs!
CSV and XLS are enough for me; I thought about XML maybe for more professional use, and about PDF only for presenting/printing results in a convenient way. But the 'print' option may be achieved by other means.

[pjeutr]

I used basic csv download functionality for a project, see my pull request.
Didn't know wich way to go for styling a button, so I made a hack to use the included jquery ui css.

In my opinion sorting is not needed for csv and xls.
Still need to include filter support, but didn't see a clear way to do it, not used to the knockout way of doing things.
Could use knockout to put vars in the request?

xls can be easily achieved using http://pear.php.net/manual/en/package.fileformats.spreadsheet-excel-writer.intro.php
But that creates a dependency so...

[Gadoma]

Here are some of my thoughts concerning the row-export fetures:

1. In general I regard data export as a very convenient functionality of any panel admin. I took part in some procjects where customers specifically required such features, so it's nothing exotique. As mentioned, the Sonata Admin Bundle for Symfony2 does offer data export in many formats and it does come in handy. I think it's also worth mentioning the classic phpMyAdmin as it incorporates a lot of different import/export routines, handling quite a few file formats. Additionally, PMA offers detailed settings (very useful!) for each export file type, for example the separator for CSV or Windows/Mac option for Excel worksheets.

2. @gilr
   regarding your first comment, I think that for the sake of this issue, it'd be best to separate the data export and data presentation/reporting features. While obviously you need some data to populate a generated pdf, the functionality itself concerns reporting rather than data export. Moreover, everybody wants their PDF to look different, so the feature should handle some templating to provide that in a good fashioned way.

3. @janhartigan
   referring to your first reply, as I stated above - I'd suggest focusing od data export here. So, I'd surely skip PDF export in this feature. And about the XML - I think it's a good and handy data format, certainly an export to xml would be useful.

As for the exported scope, in my opinion using filters is a good approach, but it should shurely include an option to "export without pagination" which would return all rows matching to filters but not paginated. I think that "columns visible/all" suggested by @gilr is also a great idea. Regarding @pjeutr "sorting not needed" idea - I cant agree with that. Remember DRY! :) The rule is to benefit from what is already done (sorts, filters, visible columns etc.), it'd really suck if I had to manually sort my data in excel after downloading export from Administrator ;)

To sum up, in my opinion the ideal-world data-export function would have the below features:

• data export:
  CSV - with ability to set options such as separator, value quoting etc. - see phpMyAdmin for examples)
  XLS(X) - with ability to set diffrent Excel standards (at least old XLS vs new XLSX and Mac/Windows version select)
  JSON - no big ideas here ;)
  XML - as above
• global settings:
  CODEPAGE of the exported data - always a goodie to have on board! Obviously makes life easier if you're not latin1 native and when a lot of people around don't use UTF 🙀
• scope features:
  download all rows
  download all filtered rows (not just the currently visible paginted results)
  download only visible rows
  include columns in download - a radio list with [all, only columns, only filters, only rows) that would ofcourse define the columns of exported result set.

Furthermore, referring to the data presentation issue - in general I think it's also a good idea, but it needs to be logically separated. I think that the feature should include export to PDF and to HTML (yep!) while using blade templating to structure the data into the presenter result file. Providing we can specify a different template depending on the model name, presenter result file type and admin current locale - it will be a superb feature!

Regards,
Gadoma

[janhartigan]

So yesterday I thought up an interesting alternative to this: #263. I figure...why create another dependency when I can just pass in the filtered/sorted query to that action button callback and let the dev return any kind of response from there. There are packages out there that make it crazy simple to do Excel exports. Couple this with the fact that not everyone will want to format their exports the same way, create a specific kind of export file, or serve it to the user in the same way.

Thoughts?

[Gadoma]

The proposed idea is ofcourse very good, because it's universal and elastic yet very powerful == Laravelish 👍 . However it is to be noted, that while the solution deals with the "how to wrap the data export functions" problem, still a good set of some pre-made exporters working in Administrator out-of-the box are of high popular demand :)

Anyhow, I guess it'd be good if you could prepare some examples using the #263 that would demonstrate

• how to deal with the scope features I mentioned in my earlier post
• how to export an example file in at least one of the discussed result formats

This ofcourse inclines using some dependant code (DRY! ;) ) to write the result file. So I guess eventually you'd have to decide anyway - what external exporter libs to use.

Regards,
Gadoma

[janhartigan]

Well the problem is, I guarantee you that if I implement one library, there will be a decent-sized contingent of people who hate that I didn't choose their favorite library. I am also willing to bet that a large percentage of people (if not a majority) will want a different column layout than the one they're presenting the admins in the UI. Maybe they want to put it on a queue, or maybe they want to save it to a directory instead of putting it out to the browser. There are so many possibilities that it rapidly gets to the point where it's not worth my time to maintain them all. With the callback approach, there's nothing stopping people from DRYing the process using whatever library they like.

I get that it would be nice for a lot of devs to be able to just flip a switch and have access to all this functionality, but at the end of the day, it's potentially a lot of work maintaining it on my end when I can alternatively provide a catch-all solution that satisfies everyone's needs without catering to everyone's desires. Of course, this is an open-source project, so I'm wide open to pull requests if someone can manage to make it happen.

[Gadoma]

I fully understand your concerns and I couldn't agree more. To sum up all the stated arguments, I guess that it'd best to do it your way and keep it simple and let's hope that others could input some working examples, using their favourite libraries and export routines - and submit it all to the official docs. Two birds with one stone! 👍

[janhartigan]

Definitely. I'm planning on creating a separate docs page specifically for this. Thanks for all your suggestions @Gadoma :)

[janhartigan]

See the above commit that adds support for a global_actions option in model config files. It works exactly like the actions array, except it's passed the filtered Illuminate\Database\Eloquent\Builder object (with the exception of limit/offset due to the necessity of running the count query). The positioning of the global custom action buttons is right to the left of the "new item" button. This may not be the sexiest thing in the world, but as mentioned in other threads/issues, there are bigger theming problems that have to be tackled before I start addressing the overall look/feel of Administrator. For now this is a convenient solution.

Also for all custom actions I've added the ability to return a Response::download() in order to initiate a file download. This works for all custom actions, so you can play around with this on settings pages or model pages.