Hi.
I think Edit flexifilter form is too crowded when there are many components, especially for nested components. I suggest to use tabledrag instead of fieldsets, to improve user friendliness.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | flexifilter_ui.patch | 44.9 KB | dmitrig01 |
| #6 | flexifilter_ui.patch | 37.62 KB | dmitrig01 |
| #5 | flexifilter_ui.patch | 27.26 KB | dmitrig01 |
| #4 | flexifilter_ui.patch | 11.47 KB | dmitrig01 |
Comments
Comment #1
cwgordon7 commentedGood idea; the administration pages will likely see reworking in the 1.2 version if not the 1.1 version. As always, patches are welcome :) .
Comment #2
cwgordon7 commentedThis is now a DROP task.
Comment #3
cwgordon7 commented(Forgot about the no-numbering rule)
Comment #4
dmitrig01 commentedInital patch... doesn't add Drag 'n Drop.
Comment #5
dmitrig01 commentedAnother update... has lots of code that doesn't yet work
Comment #6
dmitrig01 commentedNow with awesomeness out of the box
Comment #7
dmitrig01 commentedLatest update
Comment #8
corsix commentedGetting this:
Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of form_get_cache(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in E:\HTML\Apache\users\drupal60_dev_clean\modules\flexifilter\flexifilter.admin.inc on line 762after enabling flexifilter. Apparently the line in question needs to be changed from$form = form_get_cache($form_build_id, &$form_state);to$form = form_get_cache($form_build_id, $form_state);Comment #9
corsix commentedFirstly, I cannot edit things using Firefox2. I can rearrange components, but clicking on one doesn't yield a way to edit it.
Secondly, saving a flexifilter gives a bunch of PHP notices:
Comment #10
kourge commentedI have concerns with the JavaScript file in this patch. The JS code is conveniently reproduced below due to the lack of the actual existence of the file as of now, because the JS file is still part of the patch.
Let's start with line 2.
$(function() {/*...*/})is certainly a very compact way to state$(document).ready(function() {/*...*/}), but it does not offer as much clarity. It's not a severe problem, though.The biggest problem is this:
component_id = $(this).parent().find('td:last .flexifilter-cid').val();It should be this:
var componentId = $(this).parent().find('td:last .flexifilter-cid').val();The reason to use
varis because in JavaScript if you don't, and if a global variable has the same name, it would be overwritten. Usingvarwould indicate that it's intended to be local. Not only that, you should never leave outvarfor declaring local variables because it's costly. It's an expensive operation since the JavaScript engine would have to go through the trouble of looking for a variable with the same name. (A more technically correct way to put it is that it would search up the whole scoping chain until it hits the global namespace if there aren't any variables with the same name.)So never leave out
varunless it's intended. I suggestedcomponentIdinstead ofcomponent_idbecause in JavaScript, camelCasing is the practice, rather than underscore_separation.Lastly, it would be best to consolidate the following two lines:
Into one line:
$(this).css('background-color', '#FCFF97').animate({ 'background-color': '#ffffff' }, 'slow');Not only would this save space and eliminate visual redundancy, it would also avoid calling
$(this)twice, speeding up the performance (a tiny bit).I'm happy to see the
(function($) {/*...*/})(jQuery);wrapping. This ensures library compatibility.Comment #11
birdmanx35 commentedWord on the street says dmitrig01 is still working on this locally.
Comment #12
birdmanx35 commentedComment #13
amitaibusubscribe
Comment #14
Wolfflow commentedSubscribe