The modx backend. A living nightmare?

Quote from: OpenGeek at Feb 25, 2009, 08:49 AM

But isn’t there already a setting for the preview stuff?

There is a setting to enable/disable previews ("Show Preview Window") in the document overview. pepebe is talking about adding a setting to enable/disable the Preview tab in the Edit view as well. A lot of people never use that preview, and loading a page preview in a hidden tab seems like it could slow things down quite a bit.

Switching to jQuery will impact some of the default plugins and a lot of the manager functionality.
Not sure if it’s worth the extra work.

Since I am familiar with both frameworks(more with jQuery) I will be glad to help any ay I can.
Probably an update to the manager is more important than the work to my plugin(TemplateManager) so let me know how can I help.

Quote from: xpix at Feb 25, 2009, 09:25 AM

Switching to jQuery will impact some of the default plugins and a lot of the manager functionality.
Not sure if it’s worth the extra work.

Although I’m a jQuery fan, I’m inclined to agree. A whole lot of work went into porting the Manager to mootools, and I don’t think that all of that work is going to be redone in jQuery any time soon. I think that the most graceful option would be to continue to use mootools unless and until the Manager is completely rewritten to use jQuery (which I personally don’t think is necessary, although I would prefer it if it could be accomplished magically with no effort); a less graceful but functional option would be to use jQuery in compatibility mode as well as mootools, which would mean additional overhead (loading of two JS libraries) but probably not cause any real disruption.

Quote from: ZAP at Feb 25, 2009, 09:38 AM

Although I’m a jQuery fan, I’m inclined to agree. A whole lot of work went into porting the Manager to mootools, and I don’t think that all of that work is going to be redone in jQuery any time soon. I think that the most graceful option would be to continue to use mootools unless and until the Manager is completely rewritten to use jQuery (which I personally don’t think is necessary, although I would prefer it if it could be accomplished magically with no effort); a less graceful but functional option would be to use jQuery in compatibility mode as well as mootools, which would mean additional overhead (loading of two JS libraries) but probably not cause any real disruption.

We are talking only about Evo / .96 here right? Is mootools already in evo backend. Most of it looks like handmade js to me.

in Revo, we wont have any of these problems. the manager has a BEAUTIFUL mvc architecture to modify the templates/designs how we’d like. (once this part is finished)

Quote from: ChuckTrukk at Feb 25, 2009, 11:11 AM

We are talking only about Evo / .96 here right? Is mootools already in evo backend. Most of it looks like handmade js to me.

There’s a whole lot of mootools in there as well.

Quote from: ZAP at Feb 25, 2009, 08:59 AM

Quote from: OpenGeek at Feb 25, 2009, 08:49 AM

But isn’t there already a setting for the preview stuff?

There is a setting to enable/disable previews ("Show Preview Window") in the document overview. pepebe is talking about adding a setting to enable/disable the Preview tab in the Edit view as well. A lot of people never use that preview, and loading a page preview in a hidden tab seems like it could slow things down quite a bit.

The idea was something like this.

Create a managermanager like profile and store it as a chunk. Lock the file, so other users can’t change it’s contents.

$hide_content_from_usergroup[usergrouID] = array (
array ( /*array containing the ids of hidden tabs*/ ),
array ( /*array containing the classes of hidden fields*/)
);

During page render fetch the values and show/hide individual content dependent on the current usergroup and its profile.

Question: How do I parse the chunk from mutate_content.dynamic.php?

For situations like this I usually create a module for the settings and use parameter sharing with plugins and snippets to pass those values on, but I think that OpenGeek’s suggestion of adding them to the core system settings makes more sense for non-custom configurations. These settings could probably be rolled into ManagerManager as well. That would make them an add-on rather than part of the core, which has advantages and disadvantages of course.

Is there a road map for Evolution(?)(next version for 0.9.6.3)?
Thx

Quote from: xpix at Feb 28, 2009, 12:14 PM

Is there a road map for Evolution(?)(next version for 0.9.6.3)?

Not at this time, though you can view the "roadmap" of issues currently submitted and due for consideration to be included in Evolution-1.0.0-beta via our Jira issue tracking system...

I don’t believe a formal roadmap is necessary right now for Evolution, because, although the community will still support it’s use and continued bugfixes/improvements within the current features of the 0.9.6.x releases, we will not be adding new features or making any significant changes that would complicate the 0.9.6.x/Evolution1.0-to-Revolution2.0 migration paths any more than necessary. Once both Evolution 1.0 and Revolution 1.0 are out the door, then we’ll relax this constraint on the Evolution branch, allowing it to continue to evolve in it’s own way.

Just to keep you up to date...

Recent changes and "improvements"

Added some <legend> tags to the form field descriptions. Don’t know if this is way to much, because a <dt> by it’s definition already describes the content of a <dd> element.

Had to change a few lines of datetimepicker plugin (by Phize) to solve issues with a modified tmplvars.inc.php. This problem showed up only recently, so I don’t expect it to be a problem with the version already posted.

Added some additional changes to tmplvars.nic.php to get rid of table elements and other "unnecessary stuff". The less tags, the better (in my opinion).

Right now I’m tinkering with the idea to use tmplvars.inc.php to create the whole form (MODx core variables included). This will make it much easier to add or remove variables from an individual form output depending on it’s context. Expect a proof of concept by wednesday or thursday.

pepebe