Lexicon and Namespace questions

I’m still struggling with the Revolution lexicon and namespace taxonomy and usage. I thought I’d ask some dumb questions in case there are others in a similar bind but too shy to speak up.

First of all, I haven’t been able to figure out exactly what "namespace" means in MODx.

Also, foci can be separated into namespaces, when added as directories prior (from Shaun’s directory explanation page)

.

The fact the ’core’ is the only current namespace, made me think that it was a pretty high-level classification. Shaun’s quote, OTOH, puts it below the level of foci which is a pretty mico level. So maybe it’s a generic way of subdividing taxonomic units that is independent of level? But that seems not to fit with my conception of Revolution’s arhcitecture. Since all namespaces come with a path, maybe it’s just a way of specifying where things are.

Put another, more practical, way.

Say I’m creating an add-on to add CAPTCHA capability to the manager login. I can do it the old-fashioned way and create core/lexicon/en/captcha.inc.php and just load that file in my plugins. I’d create a namespace for the add-on but I’m not sure it would be used for anything.

I could also create

core/lexicon/en/captcha/login.inc.php
core/lexicon/en/captcha/process.inc.php

then make captcha a namespace and use load(captcha:login.inc.php) and load(captcha:process.inc.php) in the appropriate locations. That would be overkill in my case since I only have a handful of lexicon entries in all but I can see where it would be useful.

If I’m understanding things correctly, I can also create the lexicon entries in the manager where they go into the db and get packaged in Package Builder (assuming that I’ve done it right). But then how are the translations accomplished?

It’s been suggested that I not use ’core’ as the namespace for the addon so my main questions are:

1. What’s a logical namespace name for this add-on (captcha?).
2. What would the suggested path for that namespace be?
3. Do I need a namespace and a focus for such a small lexicon (6 entries)?
4. If so, what would be suggested focus be?
5. Is one method of creating the lexicon entries (files VS Manager tool) preferred over the other?

And, more generally,

6. Which MODx elements/components can have a namespace and which can’t? If everything had a namespace, Package Building could get really easy for add-on developers (and harder for the MODx core developers).

I hope at least some of these questions make sense.

Quote from: BobRay at Aug 19, 2008, 01:46 PM

I’m still struggling with the Revolution lexicon and namespace taxonomy and usage. I thought I’d ask some dumb questions in case there are others in a similar bind but too shy to speak up.

This is one of the many reasons I like you, BobRay.

First of all, I haven’t been able to figure out exactly what "namespace" means in MODx.

The fact the ’core’ is the only current namespace, made me think that it was a pretty high-level classification. Shaun’s quote, OTOH, puts it below the level of foci which is a pretty mico level. So maybe it’s a generic way of subdividing taxonomic units that is independent of level? But that seems not to fit with my conception of Revolution’s arhcitecture. Since all namespaces come with a path, maybe it’s just a way of specifying where things are.

Namespaces in MODx have been undergoing a "development" of sorts in the past week, as we (core team) discovered their practical usage across the framework as opposed to just in the lexicon.

A namespace in MODx is a generic, high-level "tag" (so to speak) that groups parts of a component. It groups packages, their resources, vehicles, lexicon information, and system/context settings (and maybe more later).

Put another, more practical, way.

Say I’m creating an add-on to add CAPTCHA capability to the manager login. I can do it the old-fashioned way and create core/lexicon/en/captcha.inc.php and just load that file in my plugins. I’d create a namespace for the add-on but I’m not sure it would be used for anything.

Well, lexicon->addDirectory is gone in SVN, as we’re deprecating it since it represents an old method, so no you couldn’t, technically.

I could also create
core/lexicon/en/captcha/login.inc.php
core/lexicon/en/captcha/process.inc.php

then make captcha a namespace and use load(captcha:login.inc.php) and load(captcha:process.inc.php) in the appropriate locations. That would be overkill in my case since I only have a handful of lexicon entries in all but I can see where it would be useful.

Actually you’d do load(’captcha:process’). (no .inc.php).

If I’m understanding things correctly, I can also create the lexicon entries in the manager where they go into the db and get packaged in Package Builder (assuming that I’ve done it right). But then how are the translations accomplished?

You are correct. Lexicon management is done via the Lexicon Management page in the manager now. You create your namespace (ie, ’ditto’ for a Ditto namespace), create the necessary foci, and then load them up with strings.

Translations are simple - you simply select the language. Currently it’s only english, but very soon we’ll add a way to add more languages.

1. What’s a logical namespace name for this add-on (captcha?).

captcha.

2. What would the suggested path for that namespace be?

Path? Well, it’s up to you. You can put it whereever you want, for that matter. We’re totally not sure how we’ll utilize "path" yet, but I’m willing to bet it will be used with the vehicles as a "base target" path for installing the component.

3. Do I need a namespace and a focus for such a small lexicon (6 entries)?

Yes. You will need a namespace ’captcha’ and a ’default’ focus to load from. Namespaces do more than group things, as well, since they are becoming crucial in the transport install/uninstall process (this is how vehicles are identified in their metadata).

4. If so, what would be suggested focus be?

I’d do ’default’ or something similar.

5. Is one method of creating the lexicon entries (files VS Manager tool) preferred over the other?

Loading up a lexicon directory is your option, but lexicons are no longer loaded via files - it’s all done via the DB and a cache now, to streamline the process and allow for in-manager editing.

If you’d still like to create lexicon files via the file way, you can - just you’ll have to import them using the Import Lexicon feature on the lexicon grid, which will parse the file and import all the strings into the specified focus. This is a way to still do editing of lexicon strings via file, and then just update it by importing whenever you want.

6. Which MODx elements/components can have a namespace and which can’t? If everything had a namespace, Package Building could get really easy for add-on developers (and harder for the MODx core developers).

Everything that is not core should have its own namespace. This is by design by the core team, as we’re moving away from integrating 3rd party stuff into the core and having strong core/component separation.

It also makes it easier for transport packaging.

I hope at least some of these questions make sense.

They were great questions. Feel free to ask more or give suggestions to the process.

And some excellent (and very fast) answers, which is one of the many reasons I like *you*  Splittingred. 

When I asked about translations, I wasn’t clear. I meant what will replace the old process of just creating a translated whatever.inc.php file and saving it in a new language directory. It sounds like there will be a Manager tool for doing the same thing. It also looks like you could export to a lexicon file, do the translation, and import it.

Well, lexicon->addDirectory is gone in SVN, as we’re deprecating it since it represents an old method, so no you couldn’t, technically.

$modx->lexicion->load("captcha") would still load a captcha.inc.php file as of yesterday   , at least I think it did, but I get your point.

Is there a way to assign a namespace to a plugin or is that something that’s in the works?

Path? Well, it’s up to you. You can put it wherever you want, for that matter. We’re totally not sure how we’ll utilize "path" yet, but I’m willing to bet it will be used with the vehicles as a "base target" path for installing the component.

That makes me feel better about my inability to figure out what it was for. 

I’m not sure about the "base target" idea. For example, I’ve currently got one directory of files that I’m putting in
manager/assets/captcha

and a processor:
core/model/modx/processors/security/captcha.php

I just realized that I was putting them in those locations because that’s where they were when captcha was in the core and that’s no longer appropriate. The question is, where would they go?

I know we don’t want to put restrictions on anyone, but it would sure make life a lot easier for both developers and users if there were "suggestions" about where to put things. Even very sophisticated new users spend ungodly amounts of time looking for stuff when they want to understand what’s going on, alter a tpl file, or make a minor code modification. Developers spend unnecessary time trying to figure out where to put things and can make very bad choices due to their inexperience. If we had a suggested structure, however mildly suggested, people would be free to ignore it for whatever reason but it would be immensely helpful, IMO.

My add-on has two plugins, a couple of classes, a processor, and a bunch of assets (fonts and images).  I could put them all together in one directory or have a captcha directory with classes, processors, and assets under it. Either way, where would be a logical place them (bearing in mind that other add-on developers might want to make use of the classes and maybe even the processor)?

You could make a case for putting the classes in modx/assets/classes and the processor in modx/assets/processors but then the namespace path doesn’t work like it should. Using modx/assets/classes/captcha and modx/assets/processors/captcha would be even worse.

Everything could go in assets/plugins/captcha but the add-on isn’t really a plugin.

The following seems to make the most sense to me and fit the best with namespace->path , but there may be something I’m not thinking of:

assets/captcha
   assets
      font and image files here
   classes
      veriword.class.php
      mathstring.class.php
   processors
       captcha.php 


It would be great if I could retrieve the namespace path and use it in the code.

Responses, thoughts, musings, advice, etc. invited. 

BobRay,

I’ll reply more in depth later, but you might want to see these articles for suggestions on how to create your directory/file structure, and how to package it.

And for grabbing the namespace path, well:

Quote from: splittingred at Aug 19, 2008, 04:52 PM

BobRay,

I’ll reply more in depth later, but you might want to see these articles for suggestions on how to create your directory/file structure, and how to package it.

And for grabbing the namespace path, well:

$namespace = $modx->getObject('modNamespace','captcha');
$path = $namespace->get('path');

Thanks, but looking at the articles just made me more confused since I couldn’t find and suggestion for where does the Doodles directory goes.

I hadn’t thought of having a ’core’ folder.

Quote from: BobRay at Aug 19, 2008, 05:15 PM

Thanks, but looking at the articles just made me more confused since I couldn’t find and suggestion for where does the Doodles directory goes. 

I hadn’t thought of having a ’core’ folder.

The doodles (or captcha) directory goes wherever you want it to go. It doesn’t get installed and put in (say, in doodles case, modx/assets/doodles/) until you specify that target in the vehicle target, built by the package builder, and then finally - installed, where the moving of the files happens. You can do your development work wherever.

I do mine in a separate folder called /modxcomp/ (components) where I house a few different 3rd party components.

Right, I understand that the location it’s *developed* in has no effect -- sorry I wasn’t clearer about that. I meant where would be the most logical target for the install. It sounds like site_root/assets/captcha would be it.

Now if I could just get the syntax right in the resolvers.

It would be great if you could add a support file and a support directory to the Doodles example and show how to have a resolver for them.

Quote from: BobRay at Aug 19, 2008, 07:59 PM

It would be great if you could add a support file and a support directory to the Doodles example and show how to have a resolver for them.

Sure, I definitely can. One question, what do you mean by a ’support file’ and ’support directory’?

One question, what do you mean by a ’support file’ and ’support directory’?

I knew you’d ask that. I couldn’t think of a better name.

I just meant to create some physical files (e.g. font files, images, or the like) that would be needed to support the component so readers could see an example of a single-file resolver and a directory-moving resolver.

And, while I have your attention, what I’d really, really like is an import button and an export button on the Package Builder pre-build page. If package details could be serialized in human-readable form and saved to a file and re-loaded from that file (maybe in the namespace path/_build directory) I would definitely buy you a beer.

Packages could be built again without going through all the steps and simple mistakes could be found and corrected by editing the build file.

Now, I have to log in to MODx, build the package (entering all the long paths for the resolvers), copy it to my test install of MODx, log in there, delete the debris from the last package install, clear the cache, install it, test it, and then go through all those steps over and over again because of minor typos and omissions during the package build or errors in any of the component files. :’(

Ultimately, I guess you’d want that functionality in the Manager with a full package-build editor, but it would be a nice first step just to be able to save and load the build, even if the file weren’t human-readable. It would help get components on-line a lot faster.

I know I could use an old-fashioned build script but I’ve had a really hard time making that work for some reason since I want to get some parts from the db and others from files and am not sure how to handle system setting keys, lexicon items, and the namespace. A really comprehensive example build script that would run outside of MODx might be a good intermediate step.

Quote from: BobRay at Aug 20, 2008, 12:42 AM

And, while I have your attention, what I’d really, really like is an import button and an export button on the Package Builder pre-build page. If package details could be serialized in human-readable form and saved to a file and re-loaded from that file (maybe in the namespace path/_build directory) I would definitely buy you a beer.

Good points, all of them.

Import (rather, build from XML) can be done. How would a XML-based build file feel? That could be done fairly easily. (committed in SVN)