JRequest Deprecated for JInput

[Amy Stephen]

JRequest has been marked deprecated in 11.1 and JInput is indicated as it's replacement.

Since new development should avoid usage of deprecated classes and since developers should take deprecating a method as a sign to change their existing code, having available usage information would be helpful.

Thanks.

[Lobos]

I second this!

[Ian]

So since I did some of the work for JInput, I'll write a few notes here until we get a chance to create some more complete documentation.

The idea behind JInput is to abstract out the input source to allow code to be reused in different applications and in different contexts.  What I mean by this is that you could have a controller that grabs data from an input source.  Instead of always getting it from the request (i.e. get and post variables), you get it from JInput.  So say for instance you have a MVC triad in your component that is meant to get data from the browser as a client (a typical web application).  Now suppose you want to reuse that same code but interface with it using JSON.  Instead of rewriting your triad, you just extend JInput and have it grab it data from a parsed json object and perform any translation that you need to perform.

The plan is to have JApplication instantiate JInput in its constructor.  Then in your code you get the input object from the application and get your input from there.  It will be a public property in Japplication so that it can be swapped out of that is appropriate.

We get the added benefit that we get rid of the static JRequest which makes a whole bunch the code a whole lot easier to test because you can inject mock inputs directly instead of trying to fudge with hackish dependencies.

The end result will be that your code will get the input object from the application (we will probably add something to JController at some point to make it more convenient to use there as well).

Once you have your JInput object, you use it fairly in a fairly similar manner to how JRequest is used:

$input->get('varname', 'default_value', 'filter');

Where filter is a filter that is supported by JFilterInput.  JInput::clean proxies to JFilter.  We'll have to tweak JFilter a little bit so that it is more extensible.  It defaults to cmd so that developers have to be intentional about things if they want to have more lenient filtering.

There is also a getArray method that allows you to specify an array of key and filter pairs so that you can get a whole array of filtered input.

If you want to get data from a specific super global array, you can do $input->get->get(...) or $input->post->get(...).

So that's the basic idea.  Feel free to post more questions if you have any.

We'll be adding input as a public property to JApplication in the near future.  It might be an idea if the CMS folks so chose to release a 1.7.1 that included this so developers can use it now.  Otherwise, at this point in time, it is best to still use JRequest.

Ian

[elin]

I posted a copy of this on the wiki http://docs.joomla.org/JInput_Background_for_Joomla_Platform ; thanks Ian.

Elin

[Studio 42]

I don't understand the advantage to change JRequest to JInput ?

Static calsl is 4 time faster as dynamic calls and you have to maintain the two for a long time or all the component writed for joomla doesn't work anymore.
The idea can great but the result can be poor.

Do some test before change i, this can be a benefict for a not well programmed component but not in general use.
I think is better  to call 1 time jRequest for same value and reuse it and in this case you have no advantage to use dynamic calls.


Patrick

French/English writed :)

[Ian]

I think there is almost always a benefit of moving from static classes to instantiated objects from a design perspective.  It is almost always better to use an object instance than a static class because your code becomes less coupled, more flexible and a lot easier to test.  Right now unit tests are a challenge because we have a hardcoded dependency on JRequest or other statics in many instances which makes it hard to isolate the particular code we're attempting to test.

There may be a performance difference but I imagine it is rather miniscule in the grand scheme of things and I don't think this is a place where it is worth compromising design principles for the sake of it.

Ian

[garyamort]

On Saturday, July 23, 2011 2:44:16 PM UTC-4, Ian wrote:

So since I did some of the work for JInput, I'll write a few notes here until we get a chance to create some more complete documentation.

The idea behind JInput is to abstract out the input source to allow code to be reused in different applications and in different contexts.  What I mean by this is that you could have a controller that grabs data from an input source.  Instead of always getting it from the request (i.e. get and post variables), you get it from JInput.  So say for instance you have a MVC triad in your component that is meant to get data from the browser as a client (a typical web application).  Now suppose you want to reuse that same code but interface with it using JSON.  Instead of rewriting your triad, you just extend JInput and have it grab it data from a parsed json object and perform any translation that you need to perform.

Another example which I noted when looking through code in 1.7 today, there is now a "cli" class for views - so Joomla can be run from the command line.  In addition there is a daemon application type lurking around which looks fairly cool.

2 good uses for those would be:

Command line installation/updates of Joomla!  If you take a look at "Drush" it is a fantastic command line app that pulls in the Drupal libraries it needs, will install/upgrade components for Drupal - as well as allows configuration from the command line.  In Joomla! with JRequest and many other assumptions of being called from the web, this is very difficult to do.

As for the Daemon mode, that's perfect for embedded platforms[mp3 players, digital camera's, etc] - in that while you can shoehorn PHP onto the embedded device, running PHP + Apache/Nginx/Lighty + other stuff is just a complete non starter.  In situations like that, you don't need a web server that can handle thousands of simultaneous requests - you just need one that can handle 2 or 3 simultaneous requests.  So being able to start up a Joomla! Daemon and have it bind to port 80 allows you to move Joomla onto teeeny tiny platforms.

[rolandd]

I just want to chime in as I am trying to figure out how to convert JRequest to JInput. Since Ian mentioned it is better to instantiate an object and I see the following remark in the request.php:

* @deprecated   12.1  Use JInput::Get

Is that correct?

[Studio 42]

I know that the conversation is older than a year.

So I used in some cases jinput, other times JRequest.

I do not think the code is more readable and no timegain with  jinput. Only in joomla, prehaps, internal uses.

I hope JRequest, will not be removed in joomla 3.5 ...

Is a TEST CASE existing in joomla dev site, to compare the benefict?

[Andrew Eddie]

On 20 March 2013 09:02, Studio 42 <studio...@gmail.com> wrote:

I know that the conversation is older than a year.

So I used in some cases jinput, other times JRequest.

I do not think the code is more readable and no timegain with  jinput. Only in joomla, prehaps, internal uses.

I hope JRequest, will not be removed in joomla 3.5 ...

Is a TEST CASE existing in joomla dev site, to compare the benefict?

You will need to confirm the future of JRequest with the CMS. Best to ask that on the joomla-dev-cms list as the CMS will be making the final decision on how long that class will exist.

However, it is not included in the new Framework (see https://github.com/joomla/joomla-framework). If you are writing new applications (not the Joomla CMS), you will need to use Joomla\Input\Input.

Hope that helps.

Regards,

Andrew Eddie

[Viktor Iwan]

Does Platform 13.1 still include jrequest ?

[Michael Babker]

Platform 13.1 won't include JRequest, but it will remain in the CMS through the 3.x series at a minimum.

--
Source code: https://github.com/joomla/joomla-framework
Visit http://developer.joomla.org for more information about developing with Jooma!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-frame...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework?hl=en-GB.