Namespaces

Quote from: BobRay at Aug 24, 2009, 06:24 PM

I’ve been wresting with how to describe namespaces, expecially with respect to lexicons, and am wondering if the archictecture is confused or if (as usual) I am.
We don’t seem to be using namespaces for much when it comes to the lexicon. Maybe there are some plans for future use, but at the moment they seem to be mainly for slowing things down slightly and making life difficult for book authors.

Namespaces were added later; they serve primarily a few main focuses in Revo, which we hope to expand in later versions:

1) They separate language strings for each 3PC environment.
2) They allow 3PCs to specify a "path" by which to load; this allows you to have custom manager pages that load their controllers from a directory outside the MODx controllers directory.
3) They can filter Settings (system/context/user) as well.

Eventually we’re going to adapt them to allow for "build paths" as well for 3PCs, which would allow users to specify where to build their 3PC via a Package Builder UI (which has been pushed to 2.0.1 or later).

That said, Namespaces are here to stay. They’re very similar in concept to the idea of a Namespace in C++ or PHP6 terminology; see Wikipedia’s article on it:

http://en.wikipedia.org/wiki/Namespace_(computer_science)

- When you use "Export Lexicon" the namespace information is lost.

Why would it be stored? If it is necessary, how should it be stored? In comments?

- When you use "Import Lexicon" you have to manually specify the namespace (and could easily get it wrong).

This UI could be enhanced; what improvement would you envision there?

- Since you can create namespaces easily in Lexicon Management, the only use for System | Namespaces is to delete them. That’s kind of thin for a main menu item.

Agreed; but we’re not sure just *where* to move them, since they encompass much more than just Lexicons.

I had envisioned a hierarchical relationship (lang->namespace->topic) that mapped to physical files but no such luck. There are only topic files and nothing in the file system contains any information about the namespaces. /core contains the core namespace files but beyond that, namespaces seem to be ethereal as far as the file system is concerned. And it seems wrong to say that namespaces are divided into topics when topics can exist outside of namespaces and can be loaded into more than one namespace.

Also, Namespaces can have more than one Topic (or Language, for that matter).

3. Put PHP comment tags in the topic files that identify namespace sections.

Definitely doable. Could you JIRA it?

Just my $.02.

Thanks, as always, Bob.

Quote from: splittingred at Aug 26, 2009, 11:34 PM

Quote from: BobRay at Aug 26, 2009, 02:16 AM

Second, am I correct in saying that if I wanted to show both English and French language strings on the same page, (say, for a Canadian site), I’d have to load both languages manually into the database with "Import Lexicon" and then, either have no duplicate keys between the two, or switch back and forth using lexicon->load() for each string?

Ugh, you’ve exposed the main problem of the Lexicon structure to date. The answer is that you’d have to switch, and let me explain why:

I kind of thought so, but since I’m so often wrong, I hesitated to say it.

It’s pretty easy to imagine that for a form done with SPForm or eForm on a site in Canada, Spain, Ireland, and a bunch of other places, you’d want to have every form field’s caption in two languages (English/French, Spanish/Catalonian, Irish/English).

1) There’s no separate array for each language. Now that I think about it, that could easily be fixable; just nest the topics inside a language-specific array. That would fix your switching problem. You would, however, have to manually load the language (if by tags, using the &lang=``) attribute for each secondary language entry you want.

I’m not crazy about any of the solutions here.

Having to reload the whole language set multiple times on a single page to avoid collisions seems wrong, especially since we have the information in the lexicon_entries table to avoid it.

I guess we could just suggest that developers use a language prefix on the keys: lexicion(’fr-firstName’) but then I’d have to change all the language-string keys in SPForm to en-spf-key which would annoy over 90% of the users for no reason.

We could add methods: lexicon->setNamespace() and lexicon->setLanguage(), but that creates unacceptable side-effect issues.

We could make lexicon->load() preserve the language, namespace, and topic, but that would probably mean a performance and memory hit.

We could get language strings straight from the DB rather than the lexicon with the ability to specify lang, namespace, and topic. Maybe xPDO caching would protect us from the performance hit -- we’d gain memory.

This is my favorite solution, I think:

We could create a new object called, say, "minilexicon" with its own load() and get() methods, both of which allowed the use of lang, namespace, and topic.

It would solve the problem of collisions with dual languages -- you could just instantiate two minilexicons. It separates 3PC lexicons from the core lexicon, which should speed up the manager. I think it would mean some memory savings when these go out of scope. It should solve the issue of collisions with core entries also, which I think could be a serious problem, though 3PC developers should really be using a prefix on their keys. It also fits nicely with the language directory structure I mentioned in the other thread since minilexicon->load() should know where to find things if they weren’t in the database and the minilexicon->get() method could optionally perform a minilexicon->load() of a topic (or the whole namespace) whenever the key wasn’t found.

I’m not crazy about the term "minilexicon," but I couldn’t come up with anything better.

I think you guys are overanalyzing now. (Ha, talk about pot calling kettle black) But seriously, I do not consider this a problem, you simply use the language in the tags if you are creating a multi-lingual page and have it switch as needed. Hopefully, you employ page caching and it only happens when there are changes to the site, otherwise, it’s cached and no issue.

Most of the time, you are not creating pages with multiple languages, so, I think the overhead of switching will be fine in those cases.

Quote from: BobRay at Aug 27, 2009, 03:26 AM

Having to reload the whole language set multiple times on a single page to avoid collisions seems wrong, especially since we have the information in the lexicon_entries table to avoid it.

Oh, no, it wouldn’t "reload" it. Just store it in a separate array. And when you put &lang=`fr` into the tag, it just points it to the fr array, rather than the en one. There wouldn’t be a performance hit.

Quote from: splittingred at Aug 27, 2009, 11:22 AM

Quote from: BobRay at Aug 27, 2009, 03:26 AM

Having to reload the whole language set multiple times on a single page to avoid collisions seems wrong, especially since we have the information in the lexicon_entries table to avoid it.

Oh, no, it wouldn’t "reload" it. Just store it in a separate array. And when you put &lang=`fr` into the tag, it just points it to the fr array, rather than the en one. There wouldn’t be a performance hit.

Too bad. I was kind of getting to like my "minilexicion" idea. Maybe I’ll create it as a 3PC someday.

Seems to me that could get kind of heavy on the server if you have several languages and each one has a big array.

Quote from: sottwell at Aug 28, 2009, 04:26 AM

Seems to me that could get kind of heavy on the server if you have several languages and each one has a big array.

Well, only on whatever pages you wanted to render with multiple languages, and hopefully, you would only load small topics from the namespace for this purpose. It really shouldn’t be any heavier, and caching should be employed so it doesn’t happen on every visit.

It occurred to me that you’d probably do a dual-language page with language tags using the &language parameter rather than in a snippet.

I tried it with SPForm, creating a second language (fr) in Lexicon Management and adding entries with the spform namespace and default topic (and same-named keys).



The code above still gets me the English language string. If I specify the namespace, it works:



I notice that once I specify the namespace and language in a language tag, language tags below that will work with just the &language parameter. I assume that’s because the first tag loads the namespace and default topic into the lexicon. Is that right?

It looks like once the two languages are loaded, all you need to alternate languages is:



Can this behavior be relied on and would it be faster not to specify the namespace in every tag?

IOW, is it safe to specify the namespace in just the first tag on any page that uses language tags in that namespace?