Initial Tattoo commit

Alright folks, the initial Tattoo code was committed to my branch in SVN around 9pm CST last night (http://svn1.cvsdude.com/rethrash/tattoo/tattoo/branches/jason/trunk), if you are interested at getting an early peek at some of the things we have in store. Please note, all the code under /system/manager is temporarily there for reference until we finish implementation of all current MODx features -- it does not work as a manager, so don’t expect it to, and any remaining web resources will be moved out of there, especially the /system/manager/media directory

Lot’s of debugging and implementation work left before this will be usuable by an average MODx user, so I’d like to start soliciting for PHP developers who are interested in contributing to the initial Tattoo release, which I expect to have ready in no more than 3 months time (hopefully a lot sooner if I get enough quality contributors interested in pitching in quickly).

Here are some specific areas that need to be addressed:

[*] Finish re-implementation of Friendly URLs
[*] Finish implementation of PermissionElement and all Resource-derived classes to make use of PermissionElements and remove the UserGroup and ResourceGroup-based security tables/classes as PermissionElements will replace these.
[*] Add hierarchical Element relationship implementation, so any Element can be attached to any other Element. For instance a PermissionElement can be attached to a ScriptElement or PluginElement for adding security. Or a MetaElement can be attached to an Element to add additional functionality or information to the element.
[*] Convert core resources to native Tattoo Elements (I’m doing some examples now and will be posting SQL dumps of this initial data, which will also be useful for testing -- I’m sure there are bugs). ModuleElements still needs to be worked out (if we even need them, since Resources and Elements can be used anywhere, even to build/customize the manager), and I’ll definitely need help reimplementing the QuickEdit stuff (hint, hint Adam).
[*] Create Manager Resources -- that’s right, all manager pages will be Resources just like any other page and can be built in the same way. By default, you’ll have the web and mgr Contexts to work with, similar to MODx, to isolate the Resources. Contexts load their own configuration settings which overwrite the default system settings and can add any other context specific data for use by these Resources. Elements can also be isolated by Context.
[*] Complete the base CacheManager implementation and add configuration options to allow alternate CacheManagers to extend the base CacheManager and handle the caching in any way imaginable.
[*] Refactor the Propel BaseClass and BasePeerClass templates to reduce the amount of code in each BaseClass and BasePeerClass in the object model. This is based on recent changes to Propel itself; efforts to reduce the memory footprint and expensive include time for these large class files. The files are currently ridiculously large and full of methods that can easily be replaced with generic methods using PHP 5’s new Reflection capabilities (as used in the tattoo.ContentManager class).
[*] Write DeploymentPackage installer and complete implementation of the classes in tattoo.deployment
[*] Add configuration options for /assets and /system directory, so the locations can be changed

There’s more that I can’t think of right now, but I will leave the rest alone for now; I want to start getting other contributors involved in this before too much more is decided.

Speaking of that, I plan on sending out invitations to a variety of talented PHP OO coders I’d like to have contribute to the project’s early stages (let me know if you have any suggestions, or want an invitation to contribute in the early stages via [email protected]), and I believe we’ll be offering an Early Access program at some point for those interested in paying for, well, early access to the project without being expected to contribute in some other way.

NOTE: All the classes are in /system/classes/, and specifically, all the CMS code is under /system/classes/tattoo/*. Don’t expect to see much in the tattoo.ContentManager class; all the methods associated with Resources and Elements (like parsing ElementTags) have been moved to the appropriate classes. See the collectElementTags() method in the tattoo.ElementPeer class to see the simple tag parser implementation, or /parsetags.php for a simple demonstration of what it does (not much), how it does it, and how quickly. Uncomment the echo’s as appropriate to see it interactively instead of how quickly it runs...

Lot’s more to come, including a tutorial for setting up a complete development environment for core coding on Tattoo using the latest Eclipse IDE with the latest PHPEclipse and Subclipse add-ons.

Now, give me some feedback or ask me some questions (please?)

Awesome! Thanks Jason, I have a feeling I won’t be making much progress on the things I planned to work on tomorrow I’ll definitely rework QE in any way needed to make it work with Tattoo.

I’m planning a pretty major reworking, using a lot more Javascript and AJAX and allowing for a lot more customization. I’ll probably try to get it working with Tattoo at the same time.

Can’t wait to play around with this. I’ll definitely be giving you some feedback soon.

Quote from: aNoble at Feb 05, 2006, 01:17 AM

Awesome! Thanks Jason, I have a feeling I won’t be making much progress on the things I planned to work on tomorrow I’ll definitely rework QE in any way needed to make it work with Tattoo.
...

Can’t wait to play around with this. I’ll definitely be giving you some feedback soon.

Let me just stress again, this is by no means ready for end-users; it’s just the new engine written from scratch in OO; the code base I want to start collaborating with. I’m diligently converting snippets and the default MODx content to native Tattoo as quickly as I can and will post SQL scripts for testing as soon as I can.

At Ryan’s suggestion, I’m also going to setup a very simple form for adding/editing/removing resources and elements in a generic way, until we get some manager stuff built. So we can at least enter our own site content without dealing with the complex new data structures that will support versioning of any Element content.

Also, I’m removing ModuleElement for now; I really don’t think it will represent anything useful. But I’m thinking of adding a DynamicScriptElement that will check for tags in the code and replace them before evaluation, so you can dynamically construct scripts on the fly (using a slightly different notation, so as to still allow regular element tags to be used in the script output).

I finally got a chance to look into this a bit more and it’s looking really good so far. The database schema is a definite improvement. I’ll probably need to run through a bit more of the propel documentation before I can understand how to tap into the objects, some test SQL and that form Ryan suggested would definitely come in handy.

I’ll wait ’till I’ve had some time to see some examples before giving too much input. At this point I’m not really sure what is has been redone and what is still just leftover from MODx.

Here are a couple of quick questons: How finalized is the database schema? And what level of backwards compatability / cross-compatability with MODx are we aiming for.

Quote from: aNoble at Feb 07, 2006, 10:05 PM

Here are a couple of quick questons: How finalized is the database schema? And what level of backwards compatability / cross-compatability with MODx are we aiming for.

Nothing’s finalized, and I can re-engineer the entire data model based on schema changes in, oh, however long it takes to edit the schema + 5 seconds of regeneration by Propel.

As for backwards compatibility, I’m striving for 100%, but haven’t decided on the best approach yet. There are many to think about and choose from; I think best might be to create extensions of the PageResource class, called EtomitePageResource and/or ModxPageResource in conjunction with extensions of the other Elements that can handle the previous tag formats and introduce an $etomite or $modx object as appropriate for the Etomite/ModxScriptElements to to use. Might also be done using a PluginElement, even isolating Resources that execute the plugin (via Contexts) to save performance degradation on pages that don’t need it.

Sounds good.

I will throw one thing out that I’d like to see happen. I’ve never liked the fact that there is so much temporary data stored alongside real data. For instance hasmetatags, haskeywords, privateweb, privatemgr, and isfolder. None of this data is really authoritative but is really just thrown in for performance reasons because, I assume. I don’t mind that but I’d like to see it all separated into a different table with a one-to-one relationship so that the whole table could be easily cleared out and regenerated, or if we could achieve this same structure with a view witohut sacrificing too much in performance, that would be great. Or maybe propel would allow us to create a cached "table" that’s really not a table at all but just an object that would behave like one.

I would also like to see us get rid of things in the core that are there only for snippets and such that may or may not exist. For instance, menus, searching, logging, etc. I noticed that you changed menuindex to something like sort_index which is good. I know it’s just semntics but I like the train of thought.

I’d like to see menuhide and searchable combined into a more generic "hidden" field. (I have a feeling hidden and searchable go hand-in-hand almost all of the time and if not the search snippet should provide the necessary TVs or whatever to handle it differently). I also think that menu_title should be pulled out (three titles is too many if you ask me, again if this is needed the menu snippet should provide it).

I think that dont_hit should also be pulled out and the logging module should handle this itself if it’s needed at all.

I don’t have the tattoo stuff right in front of me now so some of this may already be done but I thought I’d throw it out there anyway. My overall thought is MODx needs to break some ties to traditional website methods like menus and such and be more flexible in general. And I think moving to some broader concepts like sort_index is a great move.

Sort index works for me for sure. Don’t log I have no strong opinions of.

I’m slightly in disagreement with hidemenu and searchable. For instance, if you want to create a category folder for a menu (a page with no real content), you’ll want the page to show in the menu, but there’s no real reason to have it be included in searches. Then again, you’d have to search for just the menu to get any real results... just a thought that really shouldn’t weight in for changing the behavior vs. the newfound simplicity.

I do disagree on having three "title" fields, although I think semantically they could possibly be changed: browser_title, page_title, menu_title. I use all three on sites regularly. The browser_title is most likely more search oriented and might be a bit goofy. While we’re on the subject of semantics, how about URL_alias instead as well?

I’m not against having a menu title field at all and I can see that it has it’s place. I just think that’s the job of the menu and not the core. Some menus will use a separate menu title field and some won’t (I’ve never used menu_title and turn it off in QE for all of my sites because pagetitle works fine for me). Some menus may want a menu_icon field or or target, or any other number of fields and they should be able to provide that on their own.

I’m also thinking of pushing MODx beyond the typical website into areas that might not use things like a menu. Wiki’s for instance often times don’t have conventional menus.

Searchable and don’t log are the same thing. If you want to use a search snippet that offers a seachabel flag it should provide that (some people will want to use Google search or have no search and won’t have any use for it). The search snippet might also want to have a weight field, or any number of other custom fields it could use. Some people will want to use built-in stats and some will want to have none or use awstas or google analytics.

This concept is very much in line with the OO philosophy of encapsulation. Everything realeted to searching should be handled and contained within the searching "object." Every bit of code should be responsible for it’s own resources. Basically, if the core needs it, put it in the core. If a snippet needs it, put it in the snippet.

P.S. url_alias sounds great with me.

Got it now and agree. I believe the way Jason is going is to make all metadata as TVs, anyway. So we can all have ’em the way we want ’em.

Quote from: rthrash at Feb 08, 2006, 09:31 AM

I believe the way Jason is going is to make all metadata as TVs, anyway.

Really? I hadn’t heard that, that’ll be great. It could be that a lot of the stuff that I’m looking at in the db is actually just for backwards compatability, I’m not sure.