View source for Retrieving request data using JInput

{{JVer|11.1}} {{JVer|1.7}}

==Requirements==
To be able to use JInput as described here, you must be using Joomla 1.7.1 or above.

==Starting JInput==
To use JInput you must first create the object by using this code:

<source lang="php">$jinput = JFactory::getApplication()->input;</source>

===Getting values===
To get a value from JInput you can use:

<source lang="php">$foo = $jinput->get('varname', 'default_value', 'filter');</source>

The filter defaults to cmd

Available filters are:

*INT
*INTEGER
*UINT
*FLOAT
*DOUBLE
*BOOL
*BOOLEAN
*WORD
*ALNUM
*CMD
*BASE64
*STRING
*HTML
*ARRAY
*PATH
*USERNAME

To retrieve a number of values you can use the getArray() method like:

<source lang="php">
$fooarray = array();
$fooarray[] = 'var1';
$fooarray[] = 'var2';
$fooarray[] = 'var3';
$foovalues = $jinput->getArray($fooarray);</source>


===Setting values===
To set a value via JInput you can use:

<source lang="php">$jinput->set('varname', $foo);</source>


This is based on an email discussion: [https://groups.google.com/d/msg/joomla-dev-framework/LbALkK1ifMo/5waSiIlb21gJ Framework List 23 July 2011]

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.