UI (and other) changes in Revolution?

[Guest]

Welcome, Guest. Please login or register.
Did you miss your activation email?

1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[icubyx]

Hi,
I have been hearing a lot about the upcoming Revolution release. while major changes in the code are apparent, I am not sure what changes are to be expected in the UI and terminology. Can anybody throw some light on this? Are we about to see a major departure from the 0.9.6 interface?
By the way is there any plan for getting rid of the & and ` in the parameters?
Thanks
icubyx

Admin note: topic moved and title expanded.

[rthrash]

Start here:
http://modxcms.com/transforming-modx-oo-mvc-orm.html
http://modxcms.com/roadmap.html

Read them now? Good and carry on. If not go back!

There are lots of subtle (and not so subtle) changes in store with MODx. The good news is that you can still use it in a very familiar way after a short adjustment to a couple of things. The better news is that you will be able to do a whole lot more.

More on that in a second ... for now I'm going to move this topic and sticky it as a quick intro for other folks. (And updating the title for all to benefit ... thanks for asking a good question).

[rthrash]

You will not see changes in the tokens/delimiters (& and `); they're critical for making the parser work in the way we've chosen. Lots of people wonder why we use the funny "backtick" character instead of single-quotes. Backticks, while possibly confusing, are necessary because they're used so infrequently in the course of "normal" typing chores. Single-quotes are used all the time (in content and in code) and would require an extra level of escaping, potentially slowing things down. Backticks are your friend, even if you don't know it!

Even though the token delimiters will stay the same, the tag syntax is being unified and simplified. Everything is now enclosed with double-brackets ([[ ... ]]), with the character(s) immediately following the opening determining what type of "element" it is. An "element", by the way, is how to collectively refer to snippets, chunks, placeholders, plugins, templates, etc.

Content Elements

Code:

[[*TemplateVariable]]
[[$chunk]]
[[snippet]]
(Plugins and Modules still don't have tags)

Content Tags

Code:

[[+placeholder]]
[[~link]]
[[++system_setting]]
[[%language_string_key]] (new in 097)

Cache Control
Anything can be cached by simply adding a ! after the opening double-bracket:

Code:

[[!snippet]]
[[!$chunk]]
[[!*tplvar]]

Further, with 097 we get rid of using eval() in the parser altogether, allow for nested calls no matter if they're cached or not, allow HTML inside parameters, and allow snippets to break across multiple lines. Really interesting things start to open up with this ... feeding conditional changes into the other parameters, including short html templates directly in snippet parameters instead of referencing chunks, etc. ... a whole new layer of flexibility:

Code:

[[SnippetWithWhitespace?
&param1=`value1`
&param2=`
<div id="nav">
    <h3>Navigation &mdash; MySite</h3>
    [[+wf.wrapper]]
</div>
`
&param3=`[[AnotherCachedSnippet]]`
]]

[[!$aNonCacheableChunkWithProperties? &replaceme=`withthis` &replacethat=`[[WithThis? &param=`[[!++site_url]]`]]`]]

097 will also allow developers to apply PHx syntax to any element, as PHx will extend the core parser class by default. If you don't understand that today, that's OK, but if you have a gut feeling that that is cool, well it is! For example, you could recreate the functionality found in the member check snippet in a single call. PHx will also ultimately gain basic looping mechanisms so you can do some simple smarty-like things in your templates. (Hopefully Armand (bS) will chime in with an example soon...)

There will be new concepts introduced with the next major code release, which we expect to be final and wrapped up in the first half of the year, with a public preview coming much sooner. The UI will completely overhauled for the better and definitely much more powerful for developers—imagine dynamically loading custom menu items or rearranging things to suit your preferences. It will take some adjustment and time to reset your brain, but we think and hope it will be worth it. If not, 096 will be around and supported for a long time.

Finally, in case you're wondering, 097 should automatically convert all your tags for you in any element when you upgrade a site to help you along.

We're excited about getting the public preview out and revealing all that MODx is going to become. I think Packt got the award title right for sure!

[icubyx]

Hi Ryan,
Thanks for the detailed reply. It really helps. If I am thinking right from reading the explanation, the new changes will definitely address many 'why like this' questions while developing a site. I come from a WP, TxP background and the re-orientation to MODx takes a little while...
Now the million dollar question when is the public preview slated for? Can't wait to get my hands dirty hehe
regards,
icubyx

[rthrash]

Definitely before my daughter's first birthday. She's 3 weeks old. Almost.

[icubyx]

11 months max...for a newborn's parent that's not a long time at all So much I can tell from my own experience.
Congratulations!
By the way - how does one contribute to the UI of the product? Not yet sure how much time I can commit, but would like to, and wish to make a start...

[smashingred]

icubyx,

From my limited experience playing with the manager in the alpha release, it is going to be possible to customize the UI of the back end. One of the default behaviours (at the time I downloaded it) caused the Preview to open in the same window and I wanted to change it to open in a new window; I simply changed the DOM behavior from within the manager. It works like a charm.

From my understanding of the way MODx is to be packaged it will be possible to create custom packages for deployment. So if you had developed a standard eCommerce system with MODx that you wanted to deploy to client sites you could package it and install it without having to do what you currently do now which is install plugins, snippets and modules one at a time everytime and to reimplement customizations. This packaging should also enable you to do all this without modding the core at all.

It is possible that I am in error or vague on some of these points but that is certainly what I get from the docs and my playing with the 0.9.7 as it stands.

Cheers,

Jay

[rthrash]

icubyx,

We'd love some assistance on the UI. Making a custom ExtJS theme is next on my list of things to do and any help here would be more than appreciated.

[pixelchutes]

...
Even though the token delimiters will stay the same, the tag syntax is being unified and simplified.
...

Awesome summary, Ryan. These are some really exciting parser enhancements.

Thank you for reigniting my 097 flame!

[carlholmberg]

Hi,

Played around with the alpha a bit yesterday and it really looks good!

I have one concern though and that is the size of the install. One of my clients have limited space on their web host - reached the limit a few months back while doing an update - and if the install stays at the current size (about double that of 0.9.6) I'll have to either try to talk them into changing hosts (not that easy) or remove a lot of images from their image gallery (not popular)...

What is the projected size for the 0.9.7 release? What is "packages" for in the "core" folder – is it deleteable?

Kind regards and keep up the good work – 0.9.7 is going to be great!

[OpenGeek]

Regarding the package sizes, it will be much smaller in the distributions, this is just a consequence of working with the source code directly.  Once the distribution builds are completed, there will be a traditional style package with all files in the legacy locations and without all the duplicated content in the core package (the contents of the core/packages/ directory).  Following installation, you can remove the contents of the core/packages/ dir, but make sure it remains writable and if you plan to rerun setup again, you'll need it back.

[SeanPH]

I have a hard time understanding the progress of 0.9.7.  For example, if there were X development threads, where would I be able to see a summary of status (or est. % of completion) for each?  Or, if there is another way you track development progress, please point me in the right direction.

I'm an IT manager, not a developer.  I am, however, trying to assess the development timeline of 0.9.7 and how that impacts my plans.  I hope to determine where I may be able to assign developer resources to contribute.

[rthrash]

We would love to see additional contributors to 097. The best thing to do is to grab the latest SVN and start testing/filing bugs and fixing them by submitting patches at the Trac site for 097 (see my or Jason/Opengeek's signature for details).

The hard part about gauging progress is that we are funding development on 097 by doing client projects. Client work has to take precedence so that food can also make it to the table. Giving a remotely accurate predictor of progress is about a likely to be accurate as predicting who will win the Superbowl in 10 years. We'd love to talk more about this with you and find out more about what type of resources you have available.

[pixelchutes]

Content Tags

Code:

[[%language_string_key]] (new in 097)

I was curious about the new language content tags and didn't fully understand what they were or how they could potentially be used.

For anyone interested, Jason informed me that particular content tag would be the equivalent of the following:

Code:

<?php
echo $_lang['lang_string_key'];
?>

[pixelchutes]

What would the 0.9.7 equivalent be for 0.9.6's Timing Tags:

Code:

MySQL: [^qt], [^q] request(s), PHP: [^p], total: [^t], document retrieved from [^s]

I tried [[^qt]] (and even [[++qt]]), etc, but those didn't to work... Will timing tags still be present 0.9.7+ ?

Update:
In reviewing the 0.9.7 DBAPI class, I do see where the values in question get set (as attributes of the xpdo object), however I am still tracking down whether or not these values get declared as timing tags or the like.

Code:

//<?php
        $this->xpdo->queryTime= $this->xpdo->queryTime + $totaltime;
        $this->xpdo->executedQueries= $this->xpdo->executedQueries + 1;

In modresponse.class.php (Line # 96) it appears timing tags are being set in the Legacy tag format! :x

            $this->modx->resource->_output= str_replace("[^q^]", $queries, $this->modx->resource->_output);
            $this->modx->resource->_output= str_replace("[^qt^]", $queryTime, $this->modx->resource->_output);
            $this->modx->resource->_output= str_replace("[^p^]", $phpTime, $this->modx->resource->_output);
            $this->modx->resource->_output= str_replace("[^t^]", $totalTime, $this->modx->resource->_output);
            $this->modx->resource->_output= str_replace("[^s^]", $source, $this->modx->resource->_output);

Updating to the following should correct the issue upon building a case '^': statement in the parser:

Code:

            $this->modx->resource->_output= str_replace("[[^q]]", $queries, $this->modx->resource->_output);
            $this->modx->resource->_output= str_replace("[[^qt]]", $queryTime, $this->modx->resource->_output);
            $this->modx->resource->_output= str_replace("[[^p]]", $phpTime, $this->modx->resource->_output);
            $this->modx->resource->_output= str_replace("[[^t]]", $totalTime, $this->modx->resource->_output);
            $this->modx->resource->_output= str_replace("[[^s]]", $source, $this->modx->resource->_output);

Should I will update the SVN with these changes, or did we have another idea in mind?