MODX 2 manager development, yours likes and dislikes

It's great. Personally I rather like that it's not opening a popup window; although I rather imagine somebody will add the Javascript/AJAX to do that eventually.

I just began to realize how much of a difference this is going to make in a large development project I'm involved in! No more digging through the extensive Tree to figure out where to put a new resource! Just go to the parent page (or maybe that should be a sibling page?) in question and click "Create Here".
[ed. note: sottwell last edited this post 11 years, 5 months ago.]

Why MODx did not create an OOP javascript framework from the start? It will be a better choice.

Ah, not really from the start. Maybe we only need to use prototypeJS (without Scriptaculous) or jQuery (without jQuery-UI), and extend it as OOP framework.

PrototypeJS will be a better choice because it's more native, and every advanced javascript programmer will be familiar with. jQuery more easy to learn, but it's encapsulate (almost) any domElement as object array.

[ed. note: lokamaya last edited this post 11 years, 5 months ago.]

Isn't that what MODext is?

Quote from: sottwell at Nov 21, 2012, 09:01 AM

It's great. Personally I rather like that it's not opening a popup window; although I rather imagine somebody will add the Javascript/AJAX to do that eventually.

I just began to realize how much of a difference this is going to make in a large development project I'm involved in! No more digging through the extensive Tree to figure out where to put a new resource! Just go to the parent page in question and click "Create Here".

I'm working on a new round of features. I'll put down a System Setting, that maybe can be overridden in the Snippet call to control whether, that controls if it opens in a new window or not.

Quote from: sottwell at Nov 21, 2012, 09:07 AM

Isn't that what MODext is?

Yes, it is, but its based on ExtJS. Maybe we can create more lightweight OOP framework based on either prototypeJS or jQuery.

No, I meant that the QM+ in Evo opened a part of the relevant Manager page in a pop-up overlay. I actually prefer that I'm getting sent to the Manager, as I frequently need to check something such as the ID of another resource I want to link to, or the exact name of a snippet I want to insert. This way, I have all the benefits of working with the full Manager without having to sift through the Resource Tree and right-click and choose "Create -> Create Document Here". I wonder why I haven't heard about this before? As far as I'm concerned, it's a game-changer - well, game improver, anyway.

(I think we ought to retire this to its own thread - I didn't find one existing already for it) [ed. note: sottwell last edited this post 11 years, 5 months ago.]

Ah, but one of the three great virtues of a good programmer is laziness. Never re-invent the wheel! If somebody else had done it already, use his code.

The truth is, while I do prefer jQuery, it wouldn't matter what library was used, or even if a new one was built from javascript scratch, there would be those who like it and those who don't. Better to make a decision, stick with it and make it work as well as you can, than to dither around trying to please everybody. http://www.aesopfables.com/cgi/aesop1.cgi?sel&TheMantheBoyandtheDonkey

Quote from: danya_postfactum at Nov 21, 2012, 08:53 AM

I would like to see DOM+canvas implementation. For now, we need many extra-divs for decoration (visual) purpose. But we can use only one div + canvas for each semantic element of widget.

One key thing to understand about canvas is that it runs in an immediate drawing more, whereas things like Flash, Silverlight, or SVG run very differently in what's called retained mode.

In retrained mode, a display list of objects is kept by the graphics renderer and objects are displayed on the screen according to attributes set in code.. This keeps the programmer away from the low-level operations, but gives her less control over the final rendering of the bitmapped screen. - HTML5 Canvas

Basically what that means is in Flash you can do something like "create ball" and then however many frames later "move ball" and ball still exists.

Canvas, the exact opposite.

HTML5 Canvas is an immediate mode bitmapped area of the screen that can be manipulated with JavaScript. Immediate mode refers to the way the canvas renders pixels on the screen. HTML5 Canvas completely redraws the bitmapped screen on every frame using Canvas API calls from JavaScript. As a programmer, your job is to set up the screen display before each frame is rendered so that the correct pixels will be shown. - HTML5 Canvas

So in canvas its "create ball" and then a few frames later there is no ball, unless you recreate one.

Being immediate mode, canvas caters towards animation but creating any sort of UI elements with it would seem like a nightmare, and require a lot more JS than the occasional extra few divs.
[ed. note: dinocorn last edited this post 11 years, 5 months ago.]

Quote from: dinocorn at Nov 21, 2012, 08:54 AM

One interesting idea that was brought up during Ryan Thrash's open mic discussion at MODXpo this year was on the ability for your code editor, such as CodeMirror or Ace, to recognize element tags and turn them into hyperlinks that when clicked open that element for editing in say a new tab.

Sounds interesting.. Ace now highlights MODx tags. I played with parsing of tags. For example, I have implemented opening of properties editor window (same as Insert Element window, when you drop a dragged Element) using shortcut.


It is very bad that modext components uses id's. It means that you can not open for example two Chunk panels in tabs. Sadly, because tabs would be good improvement of AjaxManager plugin...