The format that PHP returns file data in for arrays can at times be awkward, especially when dealing with arrays of files. JInputFiles provides a convenient interface for making life a little easier, grouping the data by file.

Normally, PHP would put these in an array called <code>$_FILES</code> that looked like:

+

<pre>

+

Array

+

(

+

[jform1] => Array

+

(

+

[name] => Array

+

(

+

[test] => Array

+

(

+

[0] => youtube_icon.png

+

[1] => Younger_Son_2.jpg

+

)

+

+

)

+

+

[type] => Array

+

(

+

[test] => Array

+

(

+

[0] => image/png

+

[1] => image/jpeg

+

)

+

+

)

+

+

[tmp_name] => Array

+

(

+

[test] => Array

+

(

+

[0] => /tmp/phpXoIpSD

+

[1] => /tmp/phpWDE7ye

+

)

+

+

)

+

+

[error] => Array

+

(

+

[test] => Array

+

(

+

[0] => 0

+

[1] => 0

+

)

+

+

)

+

+

[size] => Array

+

(

+

[test] => Array

+

(

+

[0] => 34409

+

[1] => 99529

+

)

+

+

)

+

+

)

+

+

)

+

</pre>

+

+

JInputFiles produces a result that is cleaner and easier to work with:

+

<source lang="php">

+

$files = $input->files->get('jform1');

+

</source>

+

+

<code>$files</code> then becomes:

+

+

<pre>

+

Array

+

(

+

[test] => Array

+

(

+

[0] => Array

+

(

+

[name] => youtube_icon.png

+

[type] => image/png

+

[tmp_name] => /tmp/phpXoIpSD

+

[error] => 0

+

[size] => 34409

+

)

+

+

[1] => Array

+

(

+

[name] => Younger_Son_2.jpg

+

[type] => image/jpeg

+

[tmp_name] => /tmp/phpWDE7ye

+

[error] => 0

+

[size] => 99529

+

)

+

+

)

+

+

)

+

</pre>

+

+

In this way, the data from each file element is consolidated into a single array and can be indexed in a more straightforward manner.

+

+

== Background ==

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

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

Line 83:

Line 227:

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.

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.

Setting Values

To set a value via JInput, you can use:

$jinput->set('varname',$foo);

Retrieving File Data

The format that PHP returns file data in for arrays can at times be awkward, especially when dealing with arrays of files. JInputFiles provides a convenient interface for making life a little easier, grouping the data by file.

Background

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.