core/ajax/preview.php to controller #18675

rullzer · 2015-08-30T13:05:13Z

Yet another ajax endpoint that can go. And thus functionality we can actually test!

At the moment I dropped the forceIcon argument. Since it makes the code ugly. And we should not serve tiny png files anyway. Does anybody know if the forceIcon is actually used? (the files app already sets it to 0).

Unit tests are added and coverage is at 100%.

CC: @PVince81 @nickvergessen @Xenopathic @MorrisJobke

Endpoint is now a nice controller. * Added unit tests * Not yet possible to force icon returned

scrutinizer-notifier · 2015-08-30T13:05:20Z

A new inspection was created.

karlitschek · 2015-08-30T14:49:55Z

@rullzer https://github.com/owncloud/core/search?q=forceIcon&type=Issues&utf8=✓

oparoz · 2015-08-30T15:27:01Z

Great initiative :)

Maybe move this to the app domain (of core) instead of keeping it into core since making Preview an app is on @georgehrke's roadmap for 8.2?

georgehrke · 2015-08-30T15:32:16Z

Does anybody know if the forceIcon is actually used?

forceIcon defaults to true, so we have to check every place a preview url is called ...
Trashbin or public sharing might use it, not sure though.
I'll check tomorrow (if no one is faster than me)

Maybe move this to the app domain (of core) instead of keeping it into core since making Preview an app is on @georgehrke's roadmap for 8.2?

No, was outsourcing previews to an app discussed somewhere or is there an issue for that?

oparoz · 2015-08-30T15:35:14Z

@georgehrke #13610
And there were discussions before that which led to the issue creation and which were referring to the use of an app for everything related to previews.

georgehrke · 2015-08-30T15:37:35Z

In this issue I meant moving it to a controller and getting rid of the ajax end points (just as this pr does).
I never wanted to move the preview functionality to an app. Sorry if there was some confusion about it.

oparoz · 2015-08-30T15:48:27Z

OK, but why not keep all appframework based stuff in the apps folder? /core contains old ajax endpoints, assets, templates. It doesn't seem right to add Preview there.

rullzer · 2015-08-30T15:49:40Z

avatar stuff is also in /core

oparoz · 2015-08-30T15:51:26Z

avatar stuff is also in /core

@rullzer Yeah, one controller. That's why I'm thinking it wouldn't be a bad thing to start the trend, but the project's architects have to voice their opinion.

georgehrke · 2015-08-30T16:06:42Z

Because the preview api is an api offered by ownCloud's core. If we'd move it to an app, we would have apps depending on other apps. That's something we try to avoid.
The gallery app may not have a dependency on some files_preview app or what soever.

oparoz · 2015-08-30T16:34:00Z

I'm still not convinced because the provisioning API is an app and the public sharing API is also in an app. So we end up with APIs being scattered around.

PVince81 · 2015-08-30T16:41:48Z

@oparoz good point. This also reminds me that previews can be disabled in the config.
So if "previews" were simply an additional plugin for ownCloud, disabling that app would disable previews everywhere.

But it also means that the previews app knows how to inject previews in various apps like files_versions, sidebar, etc. Or alternatively have other apps check if there is a preview provider and get a preview from there. This sounds like a bigger change that needs to be thought through.

rullzer · 2015-08-30T16:43:19Z

@PVince81 with previews that would be "simple" since the dependency is via GET request. so if it is not there it will return a 404... just like the PR does when there is no preview :P

oparoz · 2015-08-30T16:51:03Z

@PVince81 - I agree that this might require a bigger discussion, but iirc, the end goal is to make previews completely optional, for @LukasReschke reasons, and there is a fallback mechanism with the media type icons, so user can always kind of see of which type each file is. They just don't get the previews.
So, Preview could perfectly exist as an official app, just like Documents.
The problem I see with ownCloud's strategy is that providers are supposed to also be moved outside of core, to the app store, effectively creating dependencies between lots of apps.

georgehrke · 2015-08-30T17:00:28Z

Well, but moving it to a dedicated app would create some really messed up dependencies.
Preview would depend on files, files_versions, files_trashbin, files_sharing, ... because it would have to inject code to display previews.
On the other hand gallery would have a dependency on previews.

providers are supposed to also be moved outside of core

Some providers, but not all. We want to outsource some of them / make the preview system extendable, because it would be insane to have preview providers for everything in core. (like some file formats used in hospitals or whatsoever)

oparoz · 2015-08-30T17:11:26Z

Maybe we're talking about 2 different things?

lib/private/preview.php stays where it is. That's what apps are using when they're injecting the dependencies. Gallery currently does that.

The Preview app/API would use the same class, but provide REST endpoints for apps which need them. Like Gallery at some point. That's the app created in this PR and it can sit anywhere, not necessarily in core. Other apps connect and either get a preview or a media type icon.

Or am I still missing something?

nickvergessen · 2015-08-31T13:31:39Z

core/preview/previewcontroller.php

+	 * @param int $y The max Y
+	 * @param bool $scalingUp
+	 * @param bool $a Keep aspect ratio
+	 * @param bool $forceIcon


not part of the method

DeepDiver1975 · 2015-09-01T09:18:06Z

Previews will be part of the next Generation webdav endpoint in 9.0

Kind of mit neccesary to move to a controller now.

georgehrke · 2015-09-01T09:28:44Z

core/application.php

@@ -88,6 +89,14 @@ public function __construct(array $urlParams=array()){
 				$c->query('UserFolder')
 			);
 		});
+		$container->registerService('PreviewController', function(SimpleContainer $c) {


How reusable is this?
Creating the endpoint in the trash bin app should just be a matter of replacing the folder that's being handed over.

oparoz · 2015-09-01T12:23:13Z

Kind of mit neccesary to move to a controller now.

OK :)

rullzer · 2015-09-01T15:28:11Z

Kind of mit neccesary to move to a controller now.

Ok lets close this then and keep previews the way it is.

oparoz · 2015-09-03T18:39:10Z

@deepdiver - This PR brings needed features like proper return codes and aspect ratio support. On top of that it's fully tested. Would it be that bad to bring this in for 8.2?
Without it per example, failed previews are fugly in a lot of places, like activity or the sidebar because they're stretched 16x16 PNGs.

rullzer added 2 commits August 30, 2015 14:56

Add keepAspectRatio parameter to creatPreview

e7da416

Burn the core/preview ajax endpoint

7d20f61

Endpoint is now a nice controller. * Added unit tests * Not yet possible to force icon returned

rullzer added enhancement 3 - To Review feature:previews labels Aug 30, 2015

rullzer added this to the 8.2-current milestone Aug 30, 2015

rullzer mentioned this pull request Aug 30, 2015

Previews sending the mimetype icon have a wrong size #18655

Closed

nickvergessen reviewed Aug 31, 2015
View reviewed changes

georgehrke reviewed Sep 1, 2015
View reviewed changes

rullzer closed this Sep 1, 2015

rullzer deleted the preview_no_more_ajax branch September 1, 2015 15:28

georgehrke mentioned this pull request Sep 21, 2015

use appframework for preview system #13610

Closed

2 tasks

oparoz mentioned this pull request Oct 1, 2015

Thumbnail generation: does not obey aspect ratio / max values for x and y #16250

Closed

lock bot locked as resolved and limited conversation to collaborators Aug 10, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

core/ajax/preview.php to controller #18675

core/ajax/preview.php to controller #18675

rullzer commented Aug 30, 2015

scrutinizer-notifier commented Aug 30, 2015

karlitschek commented Aug 30, 2015

oparoz commented Aug 30, 2015

georgehrke commented Aug 30, 2015

oparoz commented Aug 30, 2015

georgehrke commented Aug 30, 2015

oparoz commented Aug 30, 2015

rullzer commented Aug 30, 2015

oparoz commented Aug 30, 2015

georgehrke commented Aug 30, 2015

oparoz commented Aug 30, 2015

PVince81 commented Aug 30, 2015

rullzer commented Aug 30, 2015

oparoz commented Aug 30, 2015

georgehrke commented Aug 30, 2015

oparoz commented Aug 30, 2015

nickvergessen Aug 31, 2015

DeepDiver1975 commented Sep 1, 2015

georgehrke Sep 1, 2015

oparoz commented Sep 1, 2015

rullzer commented Sep 1, 2015

oparoz commented Sep 3, 2015

core/ajax/preview.php to controller #18675

core/ajax/preview.php to controller #18675

Conversation

rullzer commented Aug 30, 2015

scrutinizer-notifier commented Aug 30, 2015

karlitschek commented Aug 30, 2015

oparoz commented Aug 30, 2015

georgehrke commented Aug 30, 2015

oparoz commented Aug 30, 2015

georgehrke commented Aug 30, 2015

oparoz commented Aug 30, 2015

rullzer commented Aug 30, 2015

oparoz commented Aug 30, 2015

georgehrke commented Aug 30, 2015

oparoz commented Aug 30, 2015

PVince81 commented Aug 30, 2015

rullzer commented Aug 30, 2015

oparoz commented Aug 30, 2015

georgehrke commented Aug 30, 2015

oparoz commented Aug 30, 2015

nickvergessen Aug 31, 2015

Choose a reason for hiding this comment

DeepDiver1975 commented Sep 1, 2015

georgehrke Sep 1, 2015

Choose a reason for hiding this comment

oparoz commented Sep 1, 2015

rullzer commented Sep 1, 2015

oparoz commented Sep 3, 2015