[Revo Terms] Context

Is it simpler or more complicated if the pages are on the same host?  Can I switch contexts based on the document ID?

Quote from: BobRay at Oct 09, 2008, 04:56 PM

Is is simpler or more complicated if the pages are on the same host? Can I switch contexts based on the document ID?

You can use whatever criteria will execute in a plugin on an appropriate event (or in a snippet on a page even) to decide how/when to switch. Same principle will apply to multi-lingual sites divided into a context per culture (i.e. language + locale, e.g. en-UK). You can use session data or request headers and/or just about any information you can get access to and switch to the appropriate context.

Thx Jason for taking the time to explain these things. Back to the multi-lingual train of thought if we could. We’re building a site with 4-6 languages and 4-6+ "countries". I know how I’d do it in Evolution so I’ll sketch that out as a point of comparison:

- Create a ton of extra TVs for alternate language pagetitles, contents, and maybe even aliases (though that’s not a big deal).
- Create an extra TV or two to allow selection of "country" (or countries, as a single content element might apply to more than one country).
- Use some GeoIP location and a plugin to check visitor location, set a cookie, and serve up the appropriate language.
- Use the country TV and Ditto filtering to display the appropriate content based on location / selection.

I know I could do something like this in 2.0, but how would _you_ do it? Not asking for a step by step; just the idea.

Another potentially interesting requirement would be to restrict users to _only_ access their own language TVs (or whatever), so the Spanish translator can’t edit the English translation, can’t delete a document they didn’t create, can’t change pub_date or published status or anything other than modify their own language TVs. (I’ve looked at the access permissions in 2.0 but I haven’t played enough to know if that’d be possible or if I’d have to modify the manager templates, which might be the best option.)

I know no two multilingual sites will have the same requirements, but would contexts help with this type of multilingual site?

Quote from: OpenGeek at Oct 09, 2008, 08:04 PM

Quote from: BobRay at Oct 09, 2008, 04:56 PM

Is is simpler or more complicated if the pages are on the same host? Can I switch contexts based on the document ID?

You can use whatever criteria will execute in a plugin on an appropriate event (or in a snippet on a page even) to decide how/when to switch. Same principle will apply to multi-lingual sites divided into a context per culture (i.e. language + locale, e.g. en-UK). You can use session data or request headers and/or just about any information you can get access to and switch to the appropriate context.

Does it automatically switch back to the default context when the user goes back to a page in that context, or do I have to explicitly reset the context?

Quote from: BobRay at Oct 10, 2008, 12:15 AM

Does it automatically switch back to the default context when the user goes back to a page in that context, or do I have to explicitly reset the context?

The gateway index.php determines the initial context, so that completely depends on the scenario. Once you’re in and a context is initialized, when and where that context changes is completely up to you.

Quote from: The at Oct 09, 2008, 11:55 PM

I know no two multilingual sites will have the same requirements, but would contexts help with this type of multilingual site?

I create a context per language, and would never use a single Resource to represent the same content in different languages.  Each context can be secured with it’s own permissions, and served on unique subdomains or under unique containers (folders) under the site root.  I may have a few international pages in the default context to handle users that potentially haven’t selected a preference yet, but otherwise, Resources would be specific to a language or culture, and I would simply duplicate them in each language for the translators.  Automating that workflow could be easily accomplished by building some plugins to auto create pages in other languages and maybe notify the translators.

I create a context per language, and would never use a single Resource to represent the same content in different languages

Sorry, I have an another opinion. There are a lot of ressources that should be possible to share, e.g. images, flash movies, TVs for categorization and so on. If it would be possible to "connect" ressources/contexts in the manager editing view (I think of a tab for each language) so that you can easily switch between languages and change the ressource you like I’m fine with it. But duplicating (parts of) ressources which are actually the same is unneccessary imho. But perhaps I haven`t understood the principle of contexts at all ;-)

Quote from: OpenGeek at Oct 10, 2008, 09:37 AM

Quote from: BobRay at Oct 10, 2008, 12:15 AM

Does it automatically switch back to the default context when the user goes back to a page in that context, or do I have to explicitly reset the context?

The gateway index.php determines the initial context, so that completely depends on the scenario. Once you’re in and a context is initialized, when and where that context changes is completely up to you.

So, if I’m understanding you . . .

If the pages are all on the same site, the plugin can change the context for a particular page and set the System Setting. Snippets on that page will see the reset System Setting. Then, when the user navigates or is sent to another page on the site where the plugin’s context change code won’t be triggered, index.php will change the context back and the original System Setting will be in effect?

Quote from: MadeMyDay at Oct 10, 2008, 02:08 PM

I create a context per language, and would never use a single Resource to represent the same content in different languages

Sorry, I have an another opinion. There are a lot of ressources that should be possible to share, e.g. images, flash movies, TVs for categorization and so on. If it would be possible to "connect" ressources/contexts in the manager editing view (I think of a tab for each language) so that you can easily switch between languages and change the ressource you like I’m fine with it. But duplicating (parts of) ressources which are actually the same is unneccessary imho. But perhaps I haven`t understood the principle of contexts at all ;-)

A Resource in Revolution is what you would refer to as a Document or Page in the old MODx. The first release of Revolution (2.0) will not have a single Resource with content fields for multiple languages, and IMHO, it is not good practice to deliver content in different languages from the same URL.

But a future release (maybe 2.1 or 2.2) will support this behavior by allowing Elements (like Chunks/Snippets/TVs/etc.) to be directly related to a Resource, as well as the ability to then save Element content by Language, and Versioned. This will be possible because all Element content will be represented by a new set of classes I designed to handle allowing multiple instances of any Element’s source content, stored by language and with the ability to track and revert changes to each.

Why can’t we do this now even though I’ve already designed the data structures you ask? Because we have to have logical ways to get those who’ve invested in the legacy way of doing things to Revolution in the first place. Then, once they’ve gone through that, we can then worry about changing the underlying data structures on which hundreds of 3rd party add-ons for MODx are directly dependent upon to function. This is why the abstraction layer xPDO provides for Revolution is so important; it provides a way to isolate any SQL dependencies to an easily upgradeable model that implements the behavior. Once this is in place and people have had time to re-engineer their components to not use SQL that references the MODx core tables, the sky’s the limit on improving that model and making it easier to bring everyone along for the ride, without having to change every component with every upgrade.

Quote from: BobRay at Oct 10, 2008, 02:24 PM

So, if I’m understanding you . . .

If the pages are all on the same site, the plugin can change the context for a particular page and set the System Setting. Snippets on that page will see the reset System Setting. Then, when the user navigates or is sent to another page on the site where the plugin’s context change code won’t be triggered, index.php will change the context back and the original System Setting will be in effect?

Almost correct; there’s just no changing it back if the page requested is in the default context initialized by the index.php. It always starts out in the web context, according to the call $modx->initialize(’web’) you see in the default index.php we distribute. And in my example plugin, it only ever switches to the test context if I request a page via 127.0.0.1 vs. localhost.