[API] cleanDocumentIdentifier() - How to use it?

Just a couple of important notes on this thread:

1. cleanDocumentIdentifier() is an internal function (would be private or protected method in a true object-oriented class model), as is getDocumentObject(). The only functions that should be used by snippet/module/plugin developers are within the comments which identify the set of API functions. I almost guarantee these functions will not be available in future versions of the MODx core and thus I highly recommend not depending on any of these functions; they will change or go away!

2. You should NEVER have to determine a document’s alias manually. This is the job of the SEF infrastructure which includes mod_rewrite (or IIS’s error redirection capabilities). These tools translate the actual URL’s (e.g. index.php?id=3) into the appropriate output formats as needed and back to the appropriate actual URL when requests to specific SEF URL’s are made. I never reference an SEF URL in my sites, opting instead for referencing all documents by ID. This is the only way sites will be fully functional with or without SEF URLs enabled.

3. You would use $modx->documentIdentifier to get the ID of the current document (or [~[*id*]~] can be used in content meant to be parsed). And remember, the [~[*id*]~] will not return the full URL (it actually returns index.php?id=4 or whatever the current id is, which is then translated to the full URL by mod_rewrite (or the appropriate SEF controller for the platform).

That’s a shocking news to me.

My current solution is to solve it by hierarchical view of the document which it’s really to achieve it by virtual dir. I think I have to find another solution to this.

Do you know any other API that are able to return a full path from a given document id, and vice versa? If I have this function, I will be able to achieve my target, if not, then I have to make my own API.

Thanks OpenGeek


Regards,
Wendy Novianto

Quote from: wendy at Dec 06, 2005, 02:38 PM

That’s a shocking news to me.

My current solution is to solve it by hierarchical view of the document which it’s really to achieve it by virtual dir. I think I have to find another solution to this.

Do you know any other API that are able to return a full path from a given document id, and vice versa? If I have this function, I will be able to achieve my target, if not, then I have to make my own API.

This definitely needs to be addressed in the core Wendy (and is exposed in a defect in the WebLogin snippet when using alias paths -- see http://modxcms.com/bugs/task/136), but your best bet for now is achieving this through a snippet or plugin with it’s own method for achieving your virtual path building. You can definitely use the implementation of our existing internal methods for designing your functionality, if that helps, but I do want to stress that moving forward, their is a very good chance parts of the architecture involved in this functionality will be relocated to other places, and though keeping backwards compatibility with public API methods will definitely be done, methods which were never exposed as being part of that API may be relocated or modified in ways that would render them useless to your component.

Thank for addressing that to me. That’s one of my concern asl well, to be able to use this whole implementation in the next release as well.

So how about the database, will it have the same format, or will there be any changes to the current database? If not, I will use dbAPI from MODx and fetch it directly into the database, instead of using some other API inside the core system.

Another thing, is there any plan in implementing MultiSite and MultiLingual to the new release of MODx? I believe this one of the major approach that need to be done internally inside the core system, instead of externally using module, plugin and snippet. When building multilingual website, the localization part can be achieved by implementing a localization snippet, which will accept the localization key for certain image or text and outputing them in the right format acoording the local setup that was set using either session or cookie. But in terms of outputing the right document translation is really hard to achieved. There is no way I can tell the relation between each document id 1 and coument id 4 for example, even though from our point of view, document id 4 is suppose to be a translation for document id 1.

Several thought than run through my mind is when the requested translation document has not been translated yet, and it’s still empty, there is no way we can tell with the current structure of MODx, unless if we are using the virtualdir path approach to this problem.

My suggestion is, having a built multi lingual document out of the package, without having to implement it with plugin or etc. This approach can be achieved, even though it’s going to be total remodification in the backend site. I believe the most affected things that people use the most and they do really like it is the quickedit module that need to be remodified. The other thing is, it will not be backward compatible with the old version.

(Moderator, please help me move this into internationalization thread, and sorry for posting in the wrong forum)

I’m hoping feedback from other user.

Thanks


Regards,
Wendy Novianto

Quote from: wendy at Dec 06, 2005, 04:14 PM

So how about the database, will it have the same format, or will there be any changes to the current database? If not, I will use dbAPI from MODx and fetch it directly into the database, instead of using some other API inside the core system.

Another thing, is there any plan in implementing MultiSite and MultiLingual to the new release of MODx?

Well, re: database, it will definitely be changing, so you cannot totally rely on the structures, but until we have a proper object model with which to offer the appropriate alternate methods, this is going to be your best bet. Just be aware that your interim solutions may have to be modified when upgrading in the future, and I’ll bet you’ll be able to manage the upgrades easily.

As for MultiSite/MultiLingual features, these are both definitely on the to-do lists. Specifically regarding MultiLingual capabilities, there are a lot of approaches and capabilities that need to be reviewed and addressed by whatever solution we decide to implement, but we are definitely planning and designing this missing functionality as we speak.

Nice, right now I will implement a quick way t solve this then.

Is it possible for me to participate in designing the system. I have quite a bunch of idea that I think it might help the development of the current system.


Sincerely,
Wendy Novianto

Is there any possibilities to send newsletter to selected subscribers?