Option to have SELECT (dropdown) upgrade to SELECT2(JS)

[acayer]

Hi,

Have you ever had to use any long list of select field ..... The use of SELECT2 js library is providing some air and some quite good workaround. Anyway to pimp that out ?

Thanks

 

[cheesegrits]

Are you talking about this:

http://ivaynberg.github.io/select2/

... and potentially the Bootstrap CSS for it ...

http://fk.github.io/select2-bootstrap-css/index.html

-- hugh

 

[acayer]

yes exactly.
either as a new element or maybe just as to apply a new CSS and JS element along with the setup line, like your eval text input, to apply to the element

 

[acayer]

Are you talking about this:

http://ivaynberg.github.io/select2/

... and potentially the Bootstrap CSS for it ...

http://fk.github.io/select2-bootstrap-css/index.html

-- hugh

Hugh,
Doable in 3.1 ?

 

[lcollong]

Hi,

Any follow up on this one ? The multiple select boxes as per this example page https://select2.github.io/examples.html would be a great improvement of either regular or DBjoin mutliselect dropdown...

 

[cheesegrits]

As always with "it'd be nice" features, it's a matter of time and/or funding.

I have't actually discussed this with Rob, but when it comes to improving the dropdowns, I think we are probably more likely to go with the Joomla dropdown behaviour, which use the 'chosen' library, rather than select2.

-- hugh

 

[cheesegrits]

I've added "Advanced format" to the dropdown element, which invokes the J! behavior.chosen options.

I think we'll probably need to add some more (sub) options for that, to allow selecting of the 'chosen' style / behaviors, but it's a start.

Once we've made sure there's no gotchas, and added any styling options we need, I'll add it to the join element as well.

-- hugh

 

[lcollong]

Hi Hugh,

I've just upgraded my test site. It works great and give a nice new feature on the front-end.

Here are my test results :

1/ As soon as I activate "advanced format" in one of the multi-select dropdown elements of the loaded form, all of them become "advanced".

2/ if the add option is "on" (yes/no/no), the added element is not shown in the list (js ?) however it is saved in DB and it shows up normally on the next form load.

For this last reason it is not yet usable in my case. But it's promising !

Many thanks

 

[cheesegrits]

Yup, it's work in progress. I should probably make that clear in the tooltip.

Just FYI, we're considering deprecating the "add option" for dropdown elements. It's really nasty code, and is a legacy from the very early days of Fabrik before the join element was added. Really, if you need options which can be added, you should be using a join element, and storing the data in a table. Having user defined data stored in the Fabrik element metadata, in a format which is not accessible and is subject to change (like, the next time Joomla decide to make sweeping changes to how "attribs" are stored, like they did between 1.0 and 1.5, which caused us a year of pain) is not a good idea.

I'll look at fixing it for the "Advanced format" for now, but you may want to give some thought to your app design, and anticipate that feature getting dropped at some point. Nothing set in stone yet, but we are looking at several legacy issues which cause nothing but pain for us, and take a disproportionate about of time to maintain.

And yeah ... I realized after adding it as a per-element option that it's going to affect every dropdown on the page, as it switches on a global J! "behavior". So we'll probaby have to make that a global (or perhaps per-form) option, and you either use traditional dropdowns. Whether it's per-form or entirely global kind of depends on whether we can constrain / compartmentalize that behavior when you have more than one form on a page.

 

[lcollong]

The reasons why you may drop the add option support some time in the future sounds rock solid from the structured data "normal form" point of view. I usually don't use it so much as the regular DBjoin involves a better structured data design scheme.

However, in this particular case, the form contains some 20 choices with half of them being multiselect. Using DBjoin element would create 10 intermediate (n-m) tables and either 10 joined tables either a less number of joined table, could be only one, but with some extra "where" clause inside each of the DD element. Which is pretty heavy for exceptional adds on dropdowns with relatively few items (around 12-15).

That says. I prefer voting for strong and "sexy" DBjoin and CDD elements rather than voting for maintaining the "add feature" in the regular DD...

The second point I've mentioned in my previous post was only there to relate my tests. It's not really a case.
It would be nice if you could find time to fix the first one.

Thanks,

 

[cheesegrits]

Well, I don't think the first one is "fixable". As I said, it enables a J! 'behavior' ...

JHtml::_('formbehavior.chosen', 'select');

... which means it tells J! to include the 'chosen' JQuery library, which then simply looks for and "decorates" every dropdown on the page.

-- hugh

 

[lcollong]

Sorry Hugh. I've inversed first and second !

The only concern is the "add" feature.

Not well awake !

 

[cheesegrits]

OK, try this:

https://github.com/Fabrik/fabrik/commit/e89e633dcdcf39e5021c9fa2706b40a011e43a18

-- hugh

 

[lcollong]

No change for multi select DD element. Not visibly added but effectively added in the DB upon submit. Did not notice any JS error in the firebug console.

Note: I've updated only the two files of this today commit compare to the whole site update I made yesterday.

 

[cheesegrits]

Should be 3 files ... ah, I may have forgotten to rebuild the minified JS ... lemme check ...

-- hugh

 

[cheesegrits]

Nope, I definitely updated the minified JS. Did you remember to grab that as well?

Works for me:

http://screencast.com/t/K0xgy9TWv5g3

-- hugh

 

[lcollong]

My bad !

As all the DD were showing the new UI, I've driven my test on an item which had not the new "advanced format" button set.... :-(

Doing the test on the right element works like a charm !

I'll drive some deeper testing and keep you inform. Thanks a lot. It really improves the user experience.

 

[cheesegrits]

Yeah, I need to switch that to be a global option. The way it is right now, all the dd's get the UI treatment, but there's an extra bit of JS needs to fire (which rebuilds the sexy stuff based on the hidden, original SELECT form input) if you modify the value from JavaScript, rather than via the UI. Which is what happens when you add a value.

And at the moment, that extra but of JS only fires if the "advanced" option is set on the element itself.

Basically, when I added the option, I'd spaced on the fact that it would happen to all dd's on the page, so I made the option element specific. Whereas I need to put it in the global options, and check that to see if I need to fire the 'liszt.rebuild' after doing an update form within JS, rather than having a per element option.

Actually, I'll go and do that now, why not.

-- hugh

 

[lcollong]

Indeed. The global approach sounds to be the good one. It's a matter of global UI behavior.
Up to now, all the tests I've driven went well.

 

[cheesegrits]

Jaanus is working on some PR's. One issue we just ran across is with repeat groups, as the additional DOM structures Chosen inserts need to have their ID's updated.

-- hugh