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

[#33739] We don't need to require format #3606

Closed
wants to merge 3 commits into from

Conversation

wilsonge
Copy link
Contributor

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=33739&start=0

Raw is already default in the switch/case and therefore isn't needed to be passed in. It also didn't throw an exception on introduction in 3.2 (so technically a b/c break when the exception was introduced)

Raw is already default
@betweenbrain
Copy link
Contributor

👍 to simplification

wilsonge added a commit to Joomla-Ajax-Interface/component that referenced this pull request May 16, 2014
@wilsonge wilsonge changed the title We don't need to require format [#33739] We don't need to require format May 16, 2014
@Bakual
Copy link
Contributor

Bakual commented May 16, 2014

Maybe it would make sense to have already a default value specified where we define the $format with $input->getWord('format');on line 28? Like this: $input->getWord('format', 'raw');?

@wilsonge
Copy link
Contributor Author

We could - but does it really matter with the switch having a default case?

@Bakual
Copy link
Contributor

Bakual commented May 16, 2014

Technically it doesn't matter, and we would still need the default case in the switch statement.

For me it's more a bit better codestyle since you see from the beginning that raw will be the default value.

👍 anyway to this PR 😃

@wilsonge
Copy link
Contributor Author

Fair enough :) Added it in

wilsonge added a commit to Joomla-Ajax-Interface/component that referenced this pull request May 19, 2014
@betweenbrain
Copy link
Contributor

The elseif at https://github.com/wilsonge/joomla-cms/blob/patch-20/components/com_ajax/ajax.php#L42 needs to be changed to if. Otherwise, it tests fine.

@wilsonge
Copy link
Contributor Author

Fixed although I dunno how no one has picked up on this so far :P It's must have been in the component for a while lol

@betweenbrain
Copy link
Contributor

Fixed although I dunno how no one has picked up on this so far :P It's must have been in the component for a while lol

This issue stemmed from the change at wilsonge@3379503. This just illustrates that it's not clearly coded as the removal of the format bit included the initial if statement. I'm honestly not thrilled with the readability, which I can say with a clear conscience since I wrote it. 😆

@betweenbrain
Copy link
Contributor

Thanks for updating the PR @wilsonge. Unfortunately, we have an issue when not specifying a format. Essentially, the entire HTML document is returned with the raw data. One option would be to add $app->close(); at https://github.com/wilsonge/joomla-cms/blob/patch-20/components/com_ajax/ajax.php#L177

@Bakual any thoughts on that change?

@wilsonge
Copy link
Contributor Author

So that's what we did in 3.2 - so if we don't anymore it's a b/c break

@piotr-cz was that a mistake in your PR when you did the revamp of com_ajax - or was it intentional (if intentional - why)?

@betweenbrain
Copy link
Contributor

For the record, I was never a fan of requiring the format parameter, but also didn't fight that change.

Regarding b/c, if we can change the component now to not require the format parameter, while still working when it is specified, I wouldn't consider that a b/c issue. But, I suppose you are right that the previous change was a b/c issue, although not likely to affect anyone as it was first included with 3.2.

TL;DR:
I agree

@dbhurley
Copy link

I agree with @betweenbrain, I see no need for the requirement on formal parameter. It would not be a b/c issue to drop this requirement as it would not prevent any current implementations from functioning.

👍

@wilsonge
Copy link
Contributor Author

I kinda meant about the $app->close() thing as well - we shouldn't be pushing out everything - only the module contents I guess?

@betweenbrain
Copy link
Contributor

I kinda meant about the $app->close() thing as well - we shouldn't be pushing out everything - only the module contents I guess?

Agreed.

@Bakual
Copy link
Contributor

Bakual commented May 19, 2014

any thoughts on that change?

That was probably the reason why format was made required? Especially the &format=raw changes the application flow in Joomla in that it uses a different document renderer.
Closing the app early will prevent execution of certain plugin events. So it's not ideal, however in this case I think closing the app is fine and will not break anything.

The best way would be if we could set the document type to raw during runtime. This used to work in J1.5 but doesn't work anymore since 1.6 I think.
What I did in my own extension is that I check the presence of the format=raw and redirect if it's not set properly. See https://github.com/Bakual/SermonSpeaker/blob/master/com_sermonspeaker/site/controller.php#L37
It's not ideal either but would at least set the correct document type.
One could consider doing something like this.

@piotr-cz
Copy link
Contributor

@wilsonge What do you mean?

@wilsonge
Copy link
Contributor Author

So in the change here: 94a82ca we removed $app->close() when in raw format. Was there a reason for you removing it or was it a mistake?

@Bakual
Copy link
Contributor

Bakual commented May 19, 2014

Thinking a bit more about this. I think $format = strtolower($input->getWord('format', 'raw')); should actually default to html. It's the behaviour of Joomla and you can't really change that in a specific component due to already loaded document types.
So the only working way is redirecting to format=raw if no format is given (like I do in my extension) or default to html like Joomla does. Everything else will shoot us in the foot earlier or later.

If we default to html, then the switch statement will actually work correct and we probably don't need the $app->close().

@piotr-cz
Copy link
Contributor

I'm for having the html format as default too to keep the consistency. But it's a b/c change.

As for closing the application, I wouldn't ever do it (so plugins can add other data to response), but there might be a problem as some plugins just assume full html format and alter the output. I'm not sure if it's still happening.

We've had quite a discussion about that in #1960

@Bakual
Copy link
Contributor

Bakual commented May 20, 2014

I'm for having the html format as default too to keep the consistency. But it's a b/c change.

It shouldn't be a b/c break. Currently if you don't pass the format, you get an error. Afterwards you'll get a HTML response.
We don't change the default in the switch statement.

@piotr-cz
Copy link
Contributor

oh yeah.

@wilsonge
Copy link
Contributor Author

Tbf the very first version of the plugin defaulted to raw. That was part of what #1960 did - so it could be a b/c change. I dunno

@Bakual
Copy link
Contributor

Bakual commented May 20, 2014

Tbf the very first version of the plugin defaulted to raw. That was part of what #1960 did - so it could be a b/c change. I dunno

Yeah, and that didn't work, right? And thus we made the format parameter required and throwing and error if not given. So the BC was done then.
Now we don't have a BC if we default to html if no format is given. I would prefer raw or json myself since that is what we likely want most of the time. But due to the way Joomla initialises the document, this doesn't work. At least I'm not aware that we can change the document type during runtime.

@wilsonge
Copy link
Contributor Author

It did work. #1960 initially was just making the json response use JReponseJson instead of just using json_encode on the results. It scope then got expanded to be a more major refactoring.

@Bakual
Copy link
Contributor

Bakual commented May 20, 2014

Ah true, the close was there before and got removed and instead the format was made required. If I got that right.
Looks a bit like running in a circle 😃

@betweenbrain
Copy link
Contributor

In my opinion, if we can't default to a more usable format like raw of JSON, I'd just assume leave things as they are then. By returning HTML, when the format parameter is omitted, the page will simply look broken to the end user and no meaningful message will ever get displayed. I'd rather the end user be informed of what is wrong.

I'd prefer that we default to raw, if the format parameter was omitted. 🍶

@betweenbrain
Copy link
Contributor

@piotr-cz

As for closing the application, I wouldn't ever do it (so plugins can add other data to response), but there might be a problem as some plugins just assume full html format and alter the output. I'm not sure if it's still happening.

Do we want other plugins to do this though?

@brianteeman
Copy link
Contributor

Closed as per the comment on the tracker

@brianteeman brianteeman closed this Aug 8, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants