[#1143] - Sql as 'option' type for JFormFieldList
- Closed
- 15 Oct 2013
- Medium
- Build: master
- # 1143
- Diff
- okonomiyaki3000:sql_option
- Success default The Travis CI build passed Details
User tests: Successful: Unsuccessful:
Allows you to create <option> tags for JFormFieldList or any class that inherits from it which basically function exactly like JFormFieldSQL. This essentially makes JFormFieldSQL obsolete and adds its functionality to all classes that extend JFormFieldList. And, since it's built on top of #1115, that means you can create checkbox or radiobutton inputs based on SQL.
An example of the sql field type from the wiki (http://docs.joomla.org/SQL_form_field_type) looks like this:
<field name="title" type="sql" default="10" label="Select an article" query="SELECT id AS value, title FROM #__content" />But could now be rewritten as:
<field name="title" type="list" default="10" label="Select an article">
<option type="sql" query="SELECT id AS value, title FROM #__content" />
</field>Which might not seem better except you can also do this:
<field name="title" type="checkboxes" label="Select some articles">
<option type="sql" query="SELECT id AS value, title FROM #__content" />
</field>Also, I've added this:
<field name="title" type="checkboxes" label="Select some articles">
<option type="sql" query="SELECT id AS value, title FROM #__content" >
<query driver="mysqli" query="SELECT `id` AS `value`, `title` FROM `#__content`" />
<query driver="sqlsrv" query="SELECT [id] AS [value], [title] FROM [#__content]" />
</option>
</field>Which makes it so that the option's query will be used by default but, if there is a query for the specific database driver being used, that one will be used instead.
Ah, I think I get what you're saying. I could add something like this:
<field name="title" type="checkboxes" label="Select some articles">
<option type="table" table="#__content" value="id" text="title" />
</field>
Not as flexible as a query but very simple and it's no trouble to have both.
Done. I'm using value_field and key_field as the attribute names for consistency.
I suddenly had an idea of how a future version of this could be made more awesome but I'll leave it alone for the moment.
That's so cool! Thanks.
Thanks for your contribution - At this time we are only using github as the place to submit code fixes, the actual reporting of issues and testing fixes is still taking place on Joomlacode.
As it has been some time since you opened this issue can you please confirm that it is still valid with the current Master or Joomla 3.2 beta. If it is no longer valid then please can you close this issue. Otherwise please can you:
1) Open an item on the Joomlacode tracker in the appropriate area.
CMS Bug Reports: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8103
CMS Feature Requests: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8549
2) After submitting the item to the Joomlacode tracker, add a link to the Joomlacode tracker item here and make sure that you add a link to this GitHub issue or pull request on the joomlacode tracker item.
I've never understood why rather than query you wouldn't have table, value and text attributes (and maybe optionally distinct) in the sql type. Do you not care about the distinct issue? I really like the driver handling.
I definitely favor a better way of handling sql than the sql field provides and this looks powerful.