Revolution: We need a refactor of ExtJS files in manager panel

[Ruslan-Aleev]

Feature request

Summary

While working with ExtJS files, I noticed that sometimes the section consists of two files: modx.panel.xxx.js (description and tabs) & modx.grid.xxx.js (grid output).

Sometimes the description and the grid are located in the same file, for example, the section "Media Sources" (the file is called modx.panel.sources.js):

• Panel - https://github.com/modxcms/revolution/blob/3.x/manager/assets/modext/widgets/source/modx.panel.sources.js#L9
• Grid - https://github.com/modxcms/revolution/blob/3.x/manager/assets/modext/widgets/source/modx.panel.sources.js#L64

It happens that the description and the grid are also located in the same file, but the file is called differently, for example, the "Contexts" section (the file is called modx.grid.context.js):

• Panel - https://github.com/modxcms/revolution/blob/3.x/manager/assets/modext/widgets/system/modx.grid.context.js#L9
• Grid - https://github.com/modxcms/revolution/blob/3.x/manager/assets/modext/widgets/system/modx.grid.context.js#L46

Obviously everything is messed up and there is no logic in the files. Even the names are strange, "sourceS", but "context".

---

It is also worth changing the order of functions in files to be more logical.

For example, in the file https://github.com/modxcms/revolution/blob/3.x/manager/assets/modext/widgets/security/modx.tree.resource.group.js the functions are in this order:

• updateResourceGroup();
• removeResource();
• removeResourceGroup();
• createResourceGroup();

Isn't it more correct for visual perception to arrange them more logically? For example:

• createResourceGroup();
• updateResourceGroup();
• removeResourceGroup();
• removeResource();

It also makes sense to rename the functions to more logical ones that are related to other functions. For example:

• createUserGroup();
• addManager(); Although it is more correct - addUser();

Also, some functions start with _, although most do not use _ in the name.

---

The context menu is implemented differently

Basically, this is done through a separate extjs function, for example - https://github.com/modxcms/revolution/blob/3.x/manager/assets/modext/widgets/system/modx.grid.context.js#L147

But sometimes through the processor - https://github.com/modxcms/revolution/blob/3.x/core/src/Revolution/Processors/Workspace/Providers/GetList.php#L85

---

It is also worth changing the order of component properties

It is also worth sorting the properties of the components, for example, xtype and id (possibly some more), always at the top, and the rest - alphabetically.

We need a refactor for ExtJS files.

Why is it needed?

To make it easier to work with files.
To avoid duplication of code, and files, for example - https://github.com/modxcms/revolution/pull/14895

Related issue(s)/PR(s)

N/A

[smg6511]

Taking this suggestion a few steps further, I'd say it's time for a total overhaul and upgrade of the Ext framework from the decade-old 3.4 version to the modern 7.x one. Sencha does offer the current versions with open source licensing. I know it's a major undertaking—one that would require a ground-up re-development of the front end js—but at one point or another it will become necessary.

[Ruslan-Aleev]

I'd say it's time for a total overhaul and upgrade of the Ext framework from the decade-old 3.4 version to the modern 7.x one.

Yeah, it would be great. But, unfortunately, given the current level of community involvement, this is not a realistic task. Although I may be wrong :)

[Ruslan-Aleev]

On the other hand, after refactoring the current files, it will be much easier to update the ExtJS version.

[JoshuaLuckers]

The license is incompatible with commercial usage:

Sencha Ext JS is made available under Commercial License or the GNU General Public License version 3 (GPLv3). The Commercial License requires the payment of a fee for each Designated User (i.e. developer). If you choose not to pay a fee and use the GPLv3 license, you are required to release the source code of any program that you distribute that uses Ext JS. If you choose to pay for a Commercial License, you are not required to disclose your source code.

[rthrash]

https://www.sencha.com/legal/GPL/

… the big issue is for commercial Extras that touch 3PCs. Newer versions of ExtJS are incompatible.

Refactoring currently still seems to make sense for me. Less to muddle through for the eventual update to _[insert MIT licensed framework here]_.

[alroniks]

I think it is not about refactoring, but cleaning up the mess. And to simplify implementation it makes sense to follow only one rule - one component per one file. To improve performance we can detect loading the ExtJS files and combine them into one bundle, but in sources, it should be pretty clear what is where.

Filenames the second issue. In core widgets, I see the rule to divide words by dots, including namespaces.
Example: MODx.grid.Context => modx.grid.context.js. It makes sense, but too long sometimes.
As a solution, we can rid off modx. at least from the filename, it is pretty clear, that all files in modExt folder MODX related.
Next step, move type to the end of the filename. Example: context.grid.js
And group close functionality to the folders.
And drastically improvement - rename files using real name of the component. Example: UserGroupNamespace.grid.js

[Ruslan-Aleev]

There are also problems in the naming of components, for example:

• MODx.panel.ContextS - https://github.com/modxcms/revolution/blob/3.x/manager/assets/modext/widgets/system/modx.grid.context.js#L9
• MODx.grid.Context - https://github.com/modxcms/revolution/blob/3.x/manager/assets/modext/widgets/system/modx.grid.context.js#L46
  Because the name of the grid in the context, then it seems that this is some kind of grid within the context, although this is a grid of contextS (i.e. the number is important).

It also happens in files that the grid component is placed in front of the panel component, which is strange.

[Ruslan-Aleev]

And drastically improvement - rename files using real name of the component. Example: UserGroupNamespace.grid.js

I am confused by the .grid in the file name. If the section does not have a grid, then what is the name of the file, for example: ManagerComponent.panel.js? And if there is both a panel and a grid, how? If ManagerComponent.grid.js, then this is not logical, maybe ManagerComponent.js?

[smg6511]

… the big issue is for commercial Extras that touch 3PCs. Newer versions of ExtJS are incompatible.

A few questions on this point:

1. What commercial extras are out there that would be affected?
2. Of those extras, do any of them obfuscate their source code? If I'm understanding it correctly, the GPL simply requires the source be released. And if the revenue ceiling applies with GPLs (I think it's currently $10K U.S.), would that not be the responsibility of extras authors to comply with?
3. Wouldn't there be as much or even more disruption to the extras ecosystem if a different js framework was chosen to replace Ext JS?

I realize that the priority focus is on the upcoming 3.x release; I suppose I'm just wondering if putting effort into refactoring code based on an obsolete version of the Ext framework is really worth it.

[alroniks]

I am confused by the .grid in the file name. If the section does not have a grid, then what is the name of the file, for example: ManagerComponent.panel.js? And if there is both a panel and a grid, how? If ManagerComponent.grid.js, then this is not logical, maybe ManagerComponent.js?

Each component should be in an individual file. So, if current file contains a grid and panel, it should be splited into two files with grid and panel.

[alroniks]

1. What commercial extras are out there that would be affected?

All paid on modmore.com and modstore.pro (really big amount).

2. Of those extras, do any of them obfuscate their source code? If I'm understanding it correctly, the GPL simply requires the source be released. And if the revenue ceiling applies with GPLs (I think it's currently $10K U.S.), would that not be the responsibility of extras authors to comply with?

I don't know really how it works when the license was violated, but in any case, if the platform provides a framework, even with a known issue about a paid extension, and if any developer will have problems with Sencha about the license, it will bury the reputation of the system forever. It does not make sense. Any new frontend framework brings technical issues about compatibility, but pretty safe by the finances of 3rd authors.

[Ruslan-Aleev]

In my opinion, we can check directly with Sencha about the license. Perhaps @rthrash could help with that.
Modx components do not use ExtJS directly, and the component code is not proprietary, although not free.

[JoshuaLuckers]

In my opinion, we can check directly with Sencha about the license. Perhaps @rthrash could help with that.

Modx components do not use ExtJS directly, and the component code is not proprietary, although not free.

It also means that anything you make for a client needs to become open source:

Derived Works
When a software program calls code that is licensed under the GPLv3, then that software program becomes a derived work of the GPL’d code and hence subject to the GPLv3 copyright license. If the software program is then “conveyed” to a user, the GPLv3 requires that the source code to that software program also be “conveyed.” “Conveyance” for a web application is triggered when a user outside the legal entity that created the application uses the application.

[smg6511]

It seems to me, unless I'm overlooking something, that the non-commercial licensing for the currently-used 3.4 and 7.0 are the same (note that GPLv3 currently is applicable to major and first minor releases). So any licensing issues raised above already exist.

[Ibochkarev]

I wrote a request to the address [email protected] on April 27th

Good afternoon!

I wanted to know if it is possible to obtain a free license for the latest current version of ExtJS for use in the open source project CMS MODX Revolution.

Thanks in advance!

They answered me

Hi Ivan,
We are planning to make an announcement regarding a new GPLv3 release of Ext JS shortly. I'll report back once we have some details to share.

Thanks,
Dan gallo
Sales Engineer
E: daniel.[email protected]
M: [phone]

May 11 received an answer

Hi Ivan,
Last week we released Ext JS 7.0.0 under GPLv3 license. Please see the following page for more details: https://www.sencha.com/legal/gpl/.

Thanks,
Dan Gallo
Sales Engineer
E: daniel.[email protected]
M: [phone]

license.pdf

[Mark-H]

It's pretty clear that rebuilding the manager - wether that's to upgrade to ExtJS 7.x or to something else - is a massive undertaking that will not only take significant time to pull off, but also isn't something we'll be able to do every 2-3 years because libraries have breaking changes.

Given that also heavily impacts all third party extras that touch the manager, we need to think about how we can modernise the stack without getting us stuck in the same situation a few short years from now with an unsupported version that can't be easily upgraded.

I'd rather strongly oppose spending that effort on incorporating ExtJS 7.

[rthrash]

Fool me once … 

To me the things that make the most sense for a longer-term project, in no particular order:

• React
• Vanilla JS/HTML/CSS with selected key components that are well-supported, have a good history (many years) of being maintained and an MIT or Apache license. This would be for things like grids, date/time pickers, drag-and-drop sorting, etc.
• Vue

After 3.0 is released, we can begin exploring and planning on this subject.

Back to the original inquiry of this issue, though, I have no issue making all the views consistently formatted and think it'd be a net-positive for the eventual Manager refactor.

[sottwell]

Fool me once? I seem to recall some lone voices crying out in the wilderness against getting locked into another JS library after the hot mess that was MooTools. But no, Smarty + ExtJS was supposed to be the greatest thing since sliced bread. But then I remember when sliced bread first came out, and have never liked it.

[rthrash]

When ExtJS first came out it was both incredibly powerful and facilitated a lot of good things. Two people put the entire Manager together initially, and it worked well. The fact that it still holds up and looks and works as it does in both 2.x and 3.x is a pretty big compliment. Plenty of compromises and trade-offs, to be sure, as there always will be with any technology choice.

Almost a decade later, though, and it's time for a refresh. Unfortunately—or fortunately, depending on your stance and experience with ExtJS—Sencha's licensing change and corporate position of derivative works don't make it feasible to continue with newer versions of ExtJS.

[Ibochkarev]

@rthrash https://docs.google.com/forms/d/1czy8YXW5KCI-jvSxyhNHvrWjA7TzTvBZtxUj08IzpVk/edit#responses

[Oetzie]

I love ExtJS, yes the current version in MODx is very old. And the ExtJS layer/files from MODx are a mess, but ExtJS is very powerfull and clean (the newer versions).

If you remove ExtJS from MODx and don't replace it with another good Library the UX of MODx will be ruined. ExtJS creates the look/feeling/style of MODx, all the components/windows/style are the same in each page. Thats why I dislike extra's of modMore, theses extra's has his own components/windows/style and are different then the default MODx and have a bad UX. If you replace ExtJS with VueJS people will use there own HTML en CSS so the UX of the manager will be different in each page. It will be a mess.

[Ibochkarev]

can be used for example, vuejs and UI component library. And solve the problem of a diverse UI interface. For example:

• https://keenthemes.com/metronic/?page=docs&section=vue-overview

[Oetzie]

@Ibochkarev Yes, there are standard UI components. But people will still use their own stuff. People don't read manuals, they just do it in the easiest way and implement their own 'crap'. Implement VueJS in MODX is not an good idea, to much freedom.

[Ibochkarev]

@Oetzie but the same extjs is a big obstacle for most developers. Some do not want to study it only because in the future it will not be useful anywhere.

[Ibochkarev]

And the development of technology interprets the direction where we should be looking.

[Oetzie]

@Ibochkarev ExtJS is pretty easy, it is more easier to learn then VueJS (that is what I have experienced) :-)

[Ibochkarev]

i wrote the thoughts i heard in the community

[Mark-H]

Everything's pretty easy _after_ you've learned how it works. ;)

While ExtJS is not just the interaction but also the design of a thing, most modern UI frameworks don't force you into any particular design, instead letting you use plain ol' css. So for consistency in the UI (and I'm sorry to read you dislike modmore extras oetzie) what you need is a design system which can work regardless of what (if any!) javascript framework is used.

[Ibochkarev]

For example: https://storybook.js.org/

[Oetzie]

OFFTOPIC: @Mark-H It is not personal, you have good idea's for extras. And for example commerce, that is very good technical and modular build (impressive). But when you take a look at the UX, other style windows, other style buttons, other style fields.

And when you take a look at the UX of ContentBlocks, the style is different as the default MODX if you take a look at icons, button colors, buttons that are only visible on hover etc. The ImageCropper was nice, but could only be used in ContentBlocks and not in TV for example. Thats why https://github.com/Sterc/imagecropper is made.

This can be complicated for some customers.

When you create every thing with ExtJS all the grids/fields/windows etc will have the same style/UX.

So if you let people free with plain CSS, JavaScript and HTML you will get allot of different UX styles, allot different CSS etc.

[Mark-H]

I wasn't saying you weren't right that some of they're not all consistent with the core, just that I was disappointed you don't like the extras. :P

[smg6511]

Guys - I think we need to establish a clear distinction of where our "creative freedom" should lie. I think, from a back end UI standpoint, that freedom should be very limited, where customizations can be made/are encouraged at a global level (think theming in modern Ext JS and other frameworks). Every component, be it the core UI or any given extra, should adhere to the same design. On the back end, I really don't think it matters if you can tell it's an Ext app, Vue, or any other. This is not where the focus on individuality should be. Usability and consistency should be king.

The one area in the back end that should be pliable, without touching core files, is the actual functionality. For instance, I've used the ability to override/extend in Ext JS to add my own content transformations and validations to resources. I don't know how many devs get that deep into it when using modx, but it's really nice to be able to insert my own logic in such a way.

All that said, I hope that if the consensus ends up being to move away from Ext that there's _really_ good reason to do so. I'm not sold that the licensing of Ext is any more of an issue with 7 vs. the current 3.4, as both are GPLv3. I agree it has a pretty significant learning curve, which I've been hesitant to fully engage with 3.4. I'd be much more motivated with 7, as it's Ext in its contemporary form, using modern patterns, and the knowledge gained would likely be usable elsewhere. Somewhere between v4 and v6 (and Sencha's sale to Idera) there were rumblings about the death of Ext. However, it's been quite actively developed and seems to constantly be moving forward.