Topic Closed
juergen
1.4K Posts
52.8K Downloads
16 Plugins
design, web development & visual effects

Josh -

If one (like me :o) wants to extend jQuery UI on the admin side with some components/modules it would be great if there was some info about which components are already there.
From the super-minified version included in gp|Easy it's currently hard to tell.

Is there any chance in future versions to get a handy info to check before a plugin loads unneccesary extensions (and probably casts conflicts).

if there was sth. available like ...

$jQueryUI_customInfo = array(
'UI Core' => array('Core','Widget','Mouse','Position'),
'Interactions' => array('Draggable','Droppable','Resizable','Selectable','Sortable'),
'Widgets' => array('Accordion','Autocomplete','Button','Dialog','Slider','Tabs','Datepicker','Progressbar'),
'Effects' => array('Effects Core', 'etc.', 'etc.'),
);


...  then one could do sth. like...

global $jQueryUI_customInfo;

if (!isset($jQueryUI_info['Accordion']) {
$page->head_js[] = '/data/_addoncode/'.$addonFolderName.'/jquery-ui-extensions/jquery-ui-1.8.22.accordion.min.js';
$page->css_admin[] = '/data/_addoncode/'.$addonFolderName.'/jquery-ui-extensions/jquery-ui-1.8.22.accordion.min.css';
}


... in the Plugin_Admin.php

Edited: 7 years ago#4350

juergen
1.4K Posts
52.8K Downloads
16 Plugins
design, web development & visual effects

... I'm also asking that because my new Nivo Slider Plugin already extends jQuery UI with Widgets and Tabs and as I've seen on Github 3.5 will include these components.

TIA

juergen

7 years ago#4351

Josh S.
2K Posts
277K Downloads
16 Themes
18 Plugins

Hi Juergen,

Better support for jQuery UI has been on my mind and I've been thinking more and more that we should just include the entire jQuery UI package in gpEasy. I've considered a system for gpEasy where developers could specify which components to load:

common::LoadjQueryUI('autocomplete,accordian')

I like giving devs and site admins every opportunity to keep things small and fast, but this could be a complicated endeavour.

On the other hand, if we were to just include the whole ui package, we could then offer a configuration for using code hosted on google's cdn. I'm definitely open to suggestions.

7 years ago#4364

jogai
264 Posts

Jquery is using the new grunt-based build system since the 1.8 release, and the JqueryUI download was already modular. Can't we take advantage of that? Then its the responsibility of the theme developer to include the right package of both libraries, or choose for the build in packages which are full-blown and eventually load from a cdn. Maybe with a js-folder per theme, from which gpEasy reads all the js files and return one minified & gzipped js-file to the browser.

Advantages:

  • Libraries not depending on the main gpEasy release
  • Theme developers can use jquery <2 if they need this for oldIE's
  • Full control for the developer
  • With a seperate JS folder de devs decide how big/small/fast things are

 

7 years ago#4366

juergen
1.4K Posts
52.8K Downloads
16 Plugins
design, web development & visual effects

Currently the complete jQuery UI is about 300 kB including the smoothness theme.
From my point of view thats too large to be loaded completely by default. It's ok for the admin side but not for the frontend.

Modular loading would be great. Also optional loading from cdn.

But if I want to support older gp|Easy versions I need to make some fallback like

if (!common::LoadjQueryUI('autocomplete,accordion')) { MyLegacyLoadjQueryUI('autocomplete,accordion'); }

To make MyLegacyLoadjQueryUI() work I'd still need to know which components are already available in which gp|Easy version.
Should be possible with comparison of 2 arrays:

gpEasy_jQeryUI_customInfo = array(
"2.2" => array("Core","Widget","Mouse","Draggable","Droppable"),
"2.4" => ...
"3.5" => ...
);

and another one describing jQUI's internal dependencies.

Hmm. Josh, you're right, could get a little complicated.

Anyhow, I need datepicker and slider in my next plugin :-)


 

 

 

 

7 years ago#4368

Eric
193 Posts
1.5K Downloads
1 Themes

I always avoid loading lots of code that isn't used on a specific site or page. 300kB may seem small to some, but with a slow connection, it may make the difference between someone seeing your site's content or exceeding his/her attention span.

Two options are a no brainer: include all jQueryUI and include none. It's the modular part we have to figure out. There are currently 31 components but only 6 of those have dependents. It would be nice to have an interface like the BYO page, but maybe it's better to let the developer build a custom set.

Does the CMS interface use jQueryUI and is there potential for conflicts?

7 years ago#4369

Eric
193 Posts
1.5K Downloads
1 Themes

And as Juergen suggest, who should set up the components? The theme developer or the plugin developer?

If gpEasy is set up to recognize dependencies, each theme and plugin would contain a list of the UI components it needs and gpEasy could include them and any dependencies.  

7 years ago#4370

juergen
1.4K Posts
52.8K Downloads
16 Plugins
design, web development & visual effects

Some jQueryUI functions trigger quite complex processes/event chains and it looks like it can be messed up when functions are loaded twice (i suspect so). I currently have the problem that - when I include additional components - some events fire twice. In some situations this only slows things down a bit but in others it interferes badly with calculations or animations. Very difficult to debug (at least for me) and probably error prone with different gp|Easy versions. 

For now I try to unbind every event before binding it to a function - not exactly in the inventors' sense :o)

> Does the CMS interface use jQueryUI and is there potential for conflicts?

Yes, the admin interface uses at least draggable/sortable. Probably some others, too. Josh knows better ;-)

Edited: 7 years ago#4371

juergen
1.4K Posts
52.8K Downloads
16 Plugins
design, web development & visual effects

If I remember correctly Wordpress has sth. like registering jquery components?
Probably worth taking a look into that...
/edit: http://codex.wordpress.org/Function_Reference/wp_enqueue_script

Edited: 7 years ago#4372

Josh S.
2K Posts
277K Downloads
16 Themes
18 Plugins

Does the CMS interface use jQueryUI and is there potential for conflicts?

We were only using Sortable and Autocomplete but the new new Uploaded Files area (elFinder) uses quite a few more pieces of the jquery ui.

... it can be messed up when functions are loaded twice

Definitely. Without providing a system for including jQuery UI components, two different addons could include two completely different versions of jQuery UI which could potentially cause more problems. I'm more and more convinced we should do something

To make MyLegacyLoadjQueryUI() work I'd still need to know which components are already available in which gp|Easy version.

For gpEasy previous to 3.5, we only had Sortable and Autocomplete. I'm imagining something like this:

if( version_compare($gpversion,'3.5',<) ){

   ... load other jQuery UI components

}else{

  common::LoadjQueryUI('draggable,sortable'); //not set in stone yet

}

So LoadjQueryUI( [component_list] ) could then be called from a theme or addon. gpEasy would just collect all component names, determine which other components are required and include only the necessary code.

7 years ago#4373

juergen
1.4K Posts
52.8K Downloads
16 Plugins
design, web development & visual effects

LoadjQueryUI( [component_list] ) Looks promising.

When you say gp|Easy < 3.5 uses only Sortable and Autocomplete:
With Nivo Slider for gp|Easy I had to include Widget (jQuery UI 1.8.22) to get Tabs working.
Sortable and Autocomplete also depend on Widget in 1.8.22 but it seems that the
included Widget in gpEasy (1.8.17 for gp|Easy 3.0.1 in this case) won't do it.

I don't believe that internal dependencies have changed in jQueryUI recently.
Is this a complete Widget component in 3.0.1?
If so anyone who uses jQueryUI should probably stick with 1.8.17 (or even older?) components to stay compatible with up to current gp|Easy versions.
 

And - a little OT and just for my curiosity - I like elfinder very much but I had some issues installing it under php 5.1.6 (got json errors). It works well under 5.3 though. Will elfinder force gp|Easy to PHP 5.2+?
I had a hard time to figure out which PHP version elfinder exactly demands (and had no luck so far).
/edit: finally found the info it on Github: elfinder 2 needs PHP 5.2.

Edited: 7 years ago#4375

Josh S.
2K Posts
277K Downloads
16 Themes
18 Plugins

Is this a complete Widget component in 3.0.1?

It should be. I just checked and the old versions have the widget component. Here's the jQuery UI code for gpEasy 2.3.3 and 3.0

Will elfinder force gp|Easy to PHP 5.2+?

We are changing the minimum to 5.2+ and though elFinder wasn't the only reason, it is one of the reasons we are doing it now.  Moving to 5.2+ gives us a lot more to work with and allows us to upgrade some other third party packages that don't support 4.3 (phpMailer and CssMin). We've been putting off the move for some time, and I wish we didn't have to, but the benefits of moving to 5.2+ are starting to heavily outweigh the challenges of supporting 4.3.

7 years ago#4376

juergen
1.4K Posts
52.8K Downloads
16 Plugins
design, web development & visual effects

I will take a look if i can resolve my conflicts by using only jQuery UI 1.8.7 components.
If so, it's probably a good advice for ohter theme/plugin developers to stick with 1.8.7 for backwards compatibility unless we can use a safe component loading function.

I'll tell my results here ...

Thanks for all the info!



 

7 years ago#4377

Eric
193 Posts
1.5K Downloads
1 Themes

So LoadjQueryUI( [component_list] ) could then be called from a theme or addon. gpEasy would just collect all component names, determine which other components are required and include only the necessary code.

I think the load order is important for some components. gpEasy should organize the components before including them.

Also, should the set be different for logged in (CMS mode) and logged out (Visitor mode)? It seems unnecessary to load all the code that's only used by the CMS. Especially since we're doing so much optimization in other areas.

7 years ago#4378

Josh S.
2K Posts
277K Downloads
16 Themes
18 Plugins

gpEasy should organize the components before including them.

Definitely.

Also, should the set be different for logged in (CMS mode) and logged out (Visitor mode)?

My thought was that the set for Visitor Mode will default to no jQuery UI at all. It would be up the addon and theme developers to load the components they want to use.

7 years ago#4381

juergen
1.4K Posts
52.8K Downloads
16 Plugins
design, web development & visual effects

As long as theme designers and plugin developers both use the LoadjQueryUI( [component_list] ) and the function takes care for multiple loading (from themes, gadgets, file inludes, plugin admin scripts) that would be a good solution.

7 years ago#4382

Eric
193 Posts
1.5K Downloads
1 Themes

My thought was that the set for Visitor Mode will default to no jQuery UI at all. It would be up the addon and theme developers to load the components they want to use.

This could create conflicts if multiple themes/plugins use different versions. And it could affect use when logged in as well (unless you have a way to filter it out) since CMS mode is built on top of Visitor Mode. I can imagine cases where a theme or plugin developer wants to use jQueryUI for visitor interaction.

I still think separate lists would be better:
LoadjQueryUI( [component_list]: accessed when logged in only, adds components in addition to core files and components used by gpEasy.
visitorLoadjQueryUI( [component_list]: accessed when logged out, adds components and core files. If empty (visitor mode does not require UI), the core files don't load.

7 years ago#4384

juergen
1.4K Posts
52.8K Downloads
16 Plugins
design, web development & visual effects

Hmm. Since the admin UI always loads in front of the visitor UI there will always be potential conflicts if different jQuery UI version components will be loaded - no matter how smart it gets filtered/enqueued. A complete jQUI version that can be loaded modular with LoadjQueryUI( [component_list] ) could prevent this.

For my understanding LoadjQueryUI( [component_list] ) called from Admin.php only loads when this specific admin page is accessed. Same for Gadgets and Special Pages/File includes and template.php. If it's only going to be loaded when needed (wherever) and all (multiple) calls will be filtered/combined to one custom jQUI everything is fine and there is no need for discrete admin/visitor functions.

jQuery UI theming is a lesser and completely different problem (if I'm right). If one loads a "deviant" jQUI-theme-css in admin mode (like I currently do *g*) the worst case is that the gp|Easy theme in the background will look different while he/she is logged in. Or vice versa depending on which css is loaded first. It could also get mixed depending on the components :-) Currently the differnet jQUI themes-elements use almost the same amount of space. It will hardly mess up a layout when they get switched/mixed. Might look ugly though. Anyway, it would'nt break functionality.

Edited: 7 years ago#4397

Josh S.
2K Posts
277K Downloads
16 Themes
18 Plugins

This could create conflicts if multiple themes/plugins use different versions.

One of the reasons we're implementing LoadJQueryUI() is to avoid version conflicts. By having one complete version of jQuery UI included with gpEasy, each addon and theme developer can use parts of the included jQuery UI by calling common::LoadJQueryUI( 'component_name' )

I still think separate lists would be better:

Separate lists will be very easy to do. Just check to see if the user is logged in before specifying which components to load.

if( common::LoggedIn() ){
    common::LoadjQueryUI('sortable,autocomplete');
}else{
    common::LoadjQueryUI('dialog');
}
 

 

7 years ago#4439

Topic Closed

 

News

elFinder 2.1.50 in Upcoming Release
12/28/2019

A new release for Typesetter is in the works with a lot of improvements including the ... Read More

Typesetter 5.1
8/12/2017

Typesetter 5.1 is now available for download. 5.1 includes bug fixes, UI/UX improvements, ... Read More

More News

HH-Support

Company located in T├│rshavn, Faroe Islands. * Webpage Design * ReadSpeaker Distribution Partner * Consultant & Provider of a wide range of programs for visually impaired ...

Find out more about our Provider Spotlight

Log In

  Register