Usage of modext supplied widgets etc.

1,336 Posts

shamblett Reply #1, 17 years ago

The modext toolset is invaluable in the construction of 3PC’s, its implementation of widgets for example MODx.combo.ComboBox allows these to be used by 3PCs easily giving the same functionality and ’look and feel’ as the manger.

However, the manager seems to own this layer.

I think these widgets need to be pushed down a level to allow a better abstraction and also allow different manager implementations.

What I mean is I often need to implement stuff like this , call my component 3PC, ’3PC.MODx.combo.ComboBox’ because I need to tweak it slightly or change its URL etc.

I think the manager should do something like this ’Manager.MODx.combo.ComboBox’ , ie raise it up a layer.

This would allow people to implement other manager GUI’s like ’MyManager.MODx.combo.ComboBox’ and also you would know that changing MODx.combo.ComboBox changes it for everyone, not just the manager.

Just a thought.

Use MODx, or the cat gets it!

4,149 Posts

splittingred Reply #2, 17 years ago

I don’t understand; why cant you just use Ext.extend() to override the MODx.combo.ComboBox class?

My.combo.ComboBox = function(config) {
    config = config || {};
    Ext.applyIf(config,{
        /* custom overrides here */
    });
    My.combo.ComboBox.superclass.constructor.call(this,config);
};
Ext.extend(My.combo.ComboBox,MODx.combo.ComboBox,{
      /* override functions here */
});
Ext.reg('my-combo',My.combo.ComboBox);

Adding another layer would nearly double the number of JS files in the manager, and double the JS load time - no bueno. I’d just recommend extending the classes, since that’s not difficult as-is.

shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com

1,336 Posts

shamblett Reply #3, 17 years ago

Why would it double the load time just prefix things with ’Manager.’ Why is load time valuable here?

I can extend and do this in my 3PC’s, that’s what I’m saying, the Manger is just a 3PC to me, Ok a core one but i don’t need see why it should be so integrated above others.
Its just a GUI like any other.

Use MODx, or the cat gets it!

4,149 Posts

splittingred Reply #4, 17 years ago

Quote from: shamblett at Oct 20, 2009, 10:14 AM

Why would it double the load time just prefix things with ’Manager.’ Why is load time valuable here?
I can extend and do this in my 3PC’s, that’s what I’m saying, the Manger is just a 3PC to me, Ok a core one but i don’t need see why it should be so integrated above others.
Its just a GUI like any other.

I guess I’m not sure what you’re asking; are you saying to just prefix all the MODx.* classes with Manager. ? Or to add a MODx.* layer, and then a Manager.* layer implementation upon that?

shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com

1,336 Posts

shamblett Reply #5, 17 years ago

Yes, what I mean is have the core that we already have and raise manager above it, so manager just becomes a 3PC if you like, that sits on modext, obviously named manager to distinguish it from other components but it becomes a component just the same and thus more readily changeable. Then we can have ’myManger’, YourManager’ built on the modext core in there own namespaces.

Art the moment modext itself seems to be the ’manager’, not a toolbox of components that can be generally used.

Manager is just one manifestation of the modext layer, not the layer in itself.

Use MODx, or the cat gets it!