Some ideas for MODX3

1. user accessible lexicons

I think this is really more of a request for more granular control of lexicon editing, which could be accomplished now with an add-on.


2. Clustered ACLs: ACLs are just one big list. I would love to see the, structured in clusters of functional groups, like "editing resources" or "managing users" etc.

Good idea. In my MODX 3 ACL suggestion, the Manager permissions would be a separate system, which would help some.


3. Form customization synced for "create" and "update": A way to change settings for "create" AND "update" at the same time, like a third option for doing both at the same time. Minimizes the nagging work of keeping the user-interface in sync. And: FC should be "server side only", not a JS solution!

IMO, FC needs to go back to its original form, which allowed controlling any field of any form. At the least, it should have settings for read_only status, visibility, default value, and some kind of easy constraint system. Display order would also be nice, but difficult to implement properly.


4. Replacing "update" with "edit" in the core lexicon: "update" is for software/extras, "edit" is for values. Right? ;-)

Absolutely


5. A search for chunks/snippets in the elements tab: VERY helpful with looong element trees.

Fine with me.


6. Where did I use this chunk/snippet? I often wonder, if a chunk is used in a resource or any other place. So it would be great to get a list like "where is this chunk used (if at all)?" Same for snippets. This could be triggered my a menu or by a context menu link of an element.

This is devilish to implement and would probably be slow -- but nice to have.


7. A quickedit inside the code like "quickedit this tpl-chunk that the getResources call I am working on right now is using".

Nice, but I can't imagine how to implement it, since there's no easy way to identify an element named in a tag, unless we changed the property syntax to something like &tpl=`{$myTpl}` or &tpl=``#myTpl; or forced everyone to use standard property names. The first one would be cool if it was optional, but it would break almost all existing sites.



8. A better way to structure the resource editing page, like ordering TVs, repeating blocks of TVs (like "text, image, caption" as a block. Think MIGX here.). I would love to have a customized sequence of fields for every resource template.

I think this falls under Form Customization.


9. While we are here: Less "allways there fields", like "description", "longtitle" etc.

Same as above.


10. Content should be a TV or: "Every TV should be content."


I'm not sure what this means. Taking the content Resource Field out of the Resource and splitting it among the several TV tables in the DB seems like a bad idea. TVs carry a *lot* of baggage and you wouldn't want that baggage attached to a resource field.


11. No right clicks for quicke edit because I often kill my edits this way. This part is to be taken lightly and humorous although I realy curse on this a lot. Right click is cool and it's not at the same time.


No comment.


12. A media manager that is capeable of long filenames and remembers my last position in the file tree. When having long trees of files this is a lifesaver. I have trees of more than 100 folders and scolling to "You drive me crazy" (yep, the movie) about 20 times is really driving my crazy.

Long filenames +1. Better navigation and remembering where I was -- definitely.


13. Less frameworks like ExtJS in the manager, more plain HTML/CSS with a little help of a sleek JS framework. Talking jQuery here. Don't kill me!

I'm curious to see what happens with this, though I hate ExtJS as much as the next guy. Whatever the solution, some people aren't going to like it.



14. Extend the MODX tag-syntax for direct resource fields access like the extra "fastField" does. I see such an ultraflexible solution inside the core. Creative freedom, you know.

Do you mean something like [[*pagetitle? &id=`12`]] ? I think that would be relatively easy to implement, though it would slow down page loads somewhat, especially if it's extended to TVs. Or am I misunderstanding you?

6. Where did I use this chunk/snippet? I often wonder, if a chunk is used in a resource or any other place. So it would be great to get a list like "where is this chunk used (if at all)?" Same for snippets. This could be triggered my a menu or by a context menu link of an element.
This is devilish to implement and would probably be slow -- but nice to have.

7. A quickedit inside the code like "quickedit this tpl-chunk that the getResources call I am working on right now is using".
Nice, but I can't imagine how to implement it, since there's no easy way to identify an element named in a tag, unless we changed the property syntax to something like &tpl=`{$myTpl}` or &tpl=``#myTpl; or forced everyone to use standard property names. The first one would be cool if it was optional, but it would break almost all existing sites.

14. Extend the MODX tag-syntax for direct resource fields access like the extra "fastField" does. I see such an ultraflexible solution inside the core. Creative freedom, you know. [/li
Do you mean something like [[*pagetitle? &id=`12`]] ? I think that would be relatively easy to implement, though it would slow down page loads somewhat, especially if it's extended to TVs. Or am I misunderstanding you?

Thank you for adding your ideas to mine!
Quote from: BobRay at Apr 07, 2013, 08:37 PM

Quote from: BobRay at Apr 07, 2013, 08:37 PM

14. Extend the MODX tag-syntax for direct resource fields access like the extra "fastField" does. I see such an ultraflexible solution inside the core. Creative freedom, you know. [/li
Do you mean something like [[*pagetitle? &id=`12`]] ? I think that would be relatively easy to implement, though it would slow down page loads somewhat, especially if it's extended to TVs. Or am I misunderstanding you?

Yes, that would be an awesome extension for TVs, Bob! And it would not slow the system more down then it already happens when you use getResourceField or fastField.

The parser is already processing the tags to check for output modifiers, so the overhead might be minimal.

The existing syntax rules already cover that. All output modifiers go between the field name and the properties.

[[*introtext:default=`Introtext is empty`? &docId=`12`]]

prepareTV: &id=+13
processTV: &id=++13
This reads as "+ = do more" and "++ = do much more".

• Where did I use this chunk/snippet? I often wonder, if a chunk is used in a resource or any other place. So it would be great to get a list like "where is this chunk used (if at all)?" Same for snippets. This could be triggered my a menu or by a context menu link of an element.

This is devilish to implement and would probably be slow -- but nice to have.

Are you thinking of injecting a tag or code for the hit counter into the code of all snippets and chunks?