Re:The Tattoo Path

Hi Guys,

Is there is a path already outlined for Tattoo?

Victor and I will be working on a standard development environment that will feature auto generation of API documentation, most likely using PHPdocumentor, as well as automated unit testing using phpunit; automation provided by Phing. BTW, if you don’t use Eclipse and PHPeclipse for your development, it really is worth the learning curve, especially if you are interested in the Tattoo path of development; just a quick plug for what I consider an indispensable tool in my arsenal.

http://modxcms.com/forums/index.php/topic,2276.msg15469.html#msg15469

Sorry Raymond, must have missed this post originally...

I’d say we are working on the Tattoo path, so I guess you’d say we are working on that path of development. Once I have my new design prototype completed, we can start formally documenting development environment requirements, etc. In the meantime, I’m considering everything being discussed or published regarding upcoming features in the MODx line of development, for inclusion in Tattoo, as well as publishing some of my thoughts and experiences so far...

To introduce the path I’ve been taking, I’ll offer some resources:

* Here is a preliminary data model as generated from the Propel schema definition I’m working with currently:
http://opengeek.com/assets/images/dbd_model.png

* Here’s a quick look at the current filesystem structure I’m considering: Following this structure, each site context could have it’s own assets and/or system directory, or share the assets and/or system directories between local site contexts (remote site contexts--those contained on remote servers--would require their own assets and system directories), based on the context configuration, allowing sub-sites, multi-sites, and even management sites to be located wherever most appropriate. And these context-specific sites could be managed locally (e.g. as a subdirectory) or remotely (e.g. another server) from a single manager instance.

Other features/ideas I’m working through
* Lexicon -- this idea from BlueWater I want to take a step further, so we can define in addition to static or dynamic translations, the ability to define filters for lexicon entries. For example, wrapping lexicon elements in HTML tags for generating automatic links to WikiPedia or Dictionary.com, or generating acronym or abbreviation tags. Consider it a class representing a word and all the lexical elements that might be useful when working with these reusable items in the content.
* DBAbstraction -- via Propel
* ObjectModel -- via Propel
* Context-specific Resources, Elements, and Events -- allowing certain events, resources, elements, or resource customizations of elements to be restricted by context
* Multi-lingual content -- all Elements (be they scripts, HTML, or otherwise) can have alternate content by culture (which can be more specific than just a simple language)
* Revisioning -- all Elements can keep multiple revisions of content, and each revision is also culture specific
* Contextual session management -- individual users can login/logout of individual context-specific sessions without affecting other contexts (or they can login/logout of multiple contexts simultaneously)
* Generic permissions and roles (groups of permissions) -- these can be attached to anything, so you can define and implement custom component-level security schemes
* Generic metadata -- in a similar fashion, any kind of metadata can be attached to any persistent object so that custom functionality and data can be stored without affecting the core; could be anything from storing Dublin Core metadata information on Resources, to attaching a web service/AJAX function definition for a script Element, to providing workflow attributes for a Resource

That’s a lot to digest, but that is the scope of what I’m concentrating on at the moment. I haven’t had much time the past week to work more on this, but this should summarize a lot of what has gone on since I started the Propel proof-of-concept project just before Christmas.

Ok, the path that I’m taking is a little different from the one you’ve outlined. But at some point in time I guess some of the features will cross paths.

I really don’t think that’s a good approach to this; the time for ad hoc solutions in this project of increasing popularity is over IMO. I plan on keeping the Tattoo path 100% compatible with the MODx path. So could you please illuminate these differences before I complete any more work?

Quote from: OpenGeek at Jan 17, 2006, 06:28 PM

I really don’t think that’s a good approach to this; the time for ad hoc solutions in this project of increasing popularity is over IMO.  I plan on keeping the Tattoo path 100% compatible with the MODx path.  So could you please illuminate these differences before I complete any more work?

Most of the things planned for BlueWater I have already mentioned in this forum. From what I’ve seen it would appear that your planned path would require a complete database make over, correct? It also include several layers of abstraction along with strict OO designs and patterns, correct?

As discussed in a previous thread you will be the one mainly responsible for developing this branch/path to work with Propel as a proof-of-concept. Some of these concepts will make it into the final product while some might not. Your branch will focus primarily on PHP5 tweaks and features while the current branch will continue along a PHP4/5 MySQL path until the popularity of PHP5 has increased.

PS. If the plan is to make Tattoo 100% compatible with MODx then I don’t thing there will be any difference, correct?

Quote from: xwisdom at Jan 17, 2006, 11:55 PM

Most of the things planned for BlueWater I have already mentioned in this forum.

All I’m asking for is a little formality in design and planning so we waste as little effort as possible, since we are doing this without pay.

Quote from: xwisdom at Jan 17, 2006, 11:55 PM

From what I’ve seen it would appear that your planned path would require a complete database make over, correct? It also include several layers of abstraction along with strict OO designs and patterns, correct?

Yes, the database structures will be completely different. But there is only one layer of abstraction, as you put it, which is represented by the object model.

Quote from: xwisdom at Jan 17, 2006, 11:55 PM

As discussed in a previous thread you will be the one mainly responsible for developing this branch/path to work with Propel as a proof-of-concept. Some of these concepts will make it into the final product while some might not. Your branch will focus primarily on PHP5 tweaks and features while the current branch will continue along a PHP4/5 MySQL path until the popularity of PHP5 has increased.

Agreed for now, although one of the major points of the design, beyond just PHP5 tweaks and features, is to make the core easier to contribute to, more modular, reducing the redundancy and footprint of the code that must be loaded on any one request, normalizing the database structures to increase query efficiency, as well as introduce additional capabilities and scalability to make it more attractive to larger, enterprise-level organizations.

Quote from: xwisdom at Jan 17, 2006, 11:55 PM

PS. If the plan is to make Tattoo 100% compatible with MODx then I don’t thing there will be any difference, correct?

It will be 100% compatible with MODx site definitions -- there will most definitely be differences, but I plan to handle legacy code with optional PluginElements, so the code necessary to handle legacy calls will not be required on every request.