[#3900] - [#30884] DRY list fields
- Closed
- 24 Aug 2015
- Medium
- Build: staging
- Easy Test
- # 3900
- Diff
- okonomiyaki3000:dry_list_fields
- Foreign ID 30884
- Success The Travis CI build passed Details
User tests: Successful: Unsuccessful:
This is a resurrection of #1115 which had closed in favor of #1192 but that change may be too radical. I still think it's a great idea but maybe this can get approved first.
The tracker is still here: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=30884
| Title |
|
||||||
Hmm. These are some good ideas. Let me think about them for a day or two. If you look at what #1192 does, the getOptions function mostly gets removed anyway. The idea there is there that there will be different option types which each generate one or more option items. Since I'd still like to see that idea used in the future, I'll see what can be done at this point to move in that direction.
To test this patch, you only really need to use a JForm which uses radio buttons or checkboxes (plural). Their options should be intact and working properly.
brianteeman
- | Status | New | ⇒ | Pending |
nicksavov
- | Labels |
Removed:
?
|
||
Ive tested the patch and the radiobuttons and checkboxes worked fine!
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3900.
| Category | ⇒ | Libraries |
| Status | Pending | ⇒ | Ready to Commit |
| Easy | No | ⇒ | Yes |
I have just restartet the Travis job (wich errord some days bevor).
and tested this just successful. Together with the test by @tflm84 I'm going to RTC here. Thanks @okonomiyaki3000
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3900.
joomla-cms-bot
- | Labels |
Added:
?
|
||
| Labels |
Added:
?
|
||
roland-d
- | Status | Ready to Commit | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-08-24 12:31:32 |
| Closed_By | ⇒ | roland-d |
| Labels |
Removed:
?
|
||
| Milestone |
Added: |
||
Yay!
This is a good move into the right direction! So following suggestion should not prevent this from being reviewed, tested and merged:
Architecturally, I believe it would be even better to have the common part refactored into either a small common intermediate abstract class from which all 3 extend ? or even better, to a third class with an Interface class that gets injected using DI ? That would decrease dependencies (an important software architecture measure nowadays) instead of increasing them ?