Usabilitiy Improvements

I've had about 8 years of object-oriented programming experience, and I think in objects all the time (even when not programming).

Of course, coming from a fairly extensive OO background myself, something I am sure you realize is that even in version 5, OO in PHP remains little more than a kludge.

In addition, because so many people still are on 4, whatever we do with OO must also work in that version, where OO is nothing more than fancy arrays.

So far everytime I've gotten very far into real OO work with PHP I've ended up struggling more in getting PHP to do what it should than I have writing the application itself.

Just something to keep in mind...

Absolutely my primary concern! And something I've been researching, brainstorming on, and whiteboarding in-depth over the past last week. And my answer is fairly simple. Without the reflection capabilities of Java or other OO languages, my object definitions would all have to be external. This is the object taxonomy or tree, which we would provide a manager interface for and a set of core objects (e.g. documents, chunks, snippets, users, etc.). This tree would serve at least four purposes:

1. to give a visual, wizard-based object management interface for all core and user-defined objects
2. to use as a source of reflection on objects -- e.g. if we saved the taxonomy in XML, we could get the properties, methods, rules, relationships, etc. without need internal reflection
3. object generation - we could easily automatically generate PHP class files from the object taxonomy definitions
4. automated persistence - this is based on reflection as well, where all the persistence manager needs is the object definition to manage the data container; we could start out by writing actual class implementations for persistence and eventually abstracting this kind of thing down to where just the object definition could automatically direct all persistence actions based on a set of data container specific classes for dealing with types, relationships, etc.

I know this sounds like a major project, but the more I think about it, the less intense it is appearing in my head, as far as the code required to make it happen. I could be crazy though; my experience with PHP is limited, but I've done all these types of things before in other languages. I don't see specific limitations that would prevent this from working, just unknown challenges as there always are when going from conception to reality. ;-)

(sees things flying over his head...)

Sounds very cool. Especially the wizard part.

:D

Well, if I'm understanding correctly, you and I both agree that the standard people floating around here and on Etomite.org don't necessarily need to be exposed to this.

So I guess we are looking at a three layer approach:

1. The underlying OO abstracted whatever-you-want-to-call-it interface that you want to develop.
2. The easy to understand programmer's API that keeps things as simple as they are now and that provides base services built ontop of your OO magic (just like any sort of wizards or such could be).
3. The actual backend manager where OO and API turns into things like snippets and forms that the end user can fill out.

If we are both in agreement on this, then it seems to me that I could still go ahead and build the abstracted forms, permissions, and config functions that the "middleware" layer, if you will, would use. Once your OO plan is fully realized, these could be adapted to rely on your OO base services without upsetting the snippets and other things constructed on the extended Etomite class.

From that point on, I guess, power developers would have the ability to deal with your OO interfaces directly (assuming they could detect things like underlying storage systems and the like to ensure that what they are doing is supported on that system-- i.e., XML parser is available), or they could write against the middleware which would always work and handle the OO complexities for them.

Is that making any sense?

Simultaneous submits... heh

I really like the thought of a super-charged underpinnings with a wizardlike interface on top for folks like me.

I agree fully here and for what it's worth this is what the best of breed commercial players do. RedDot for example, is really just a toolkit for building out your site in the CMS. It has tremendous power but bolted on top of that is this toolkit which makes it possible for someone with only HTML skills to build out an entire solution. There is an underlying API called RQL (Reddoot Query Language) that basically has access to everything to modify built in behavior but it's aimed squarely at programmers. I built some very complex sites and never personally had to use the API, for example - http://www.ciena.com uses nothing but the built in tools to accomlish nested linking, breadcrumbs, popups, content reuse and syndication, etc. Anytime you question their tech support people about creating non-standard CMS behavior they just tell you to use the API, that's it. I'd personally rather see more effort behind strengthening things such as wizards/tools and content relationships than bulking up APIs no one will use and frameworks that will just get increasing complicated. Ryan's point about Eto's simplicity is perfect, I chose it for that very reason. I know practically zero PHP but got a site up with a couple hundred pages. Now of course it isn't as flexible as it could be (see my post about content reuse. no, really, someone please take a look at it.) and with increased power comes greater responsibility (er...wait...).

I've said it before, the "C" in CMS is there for a reason. It really should be all about the content and making it easier and more flexible for developers to build out solutions for Sally in marketing to post news and product info, etc.
OK I'm done preaching :wink:

Simultaneous submits... heh

I really like the thought of a super-charged underpinnings with a wizardlike interface on top for folks like me.

I agree fully here and for what it's worth this is what the best of breed commercial players do. RedDot for example, is really just a toolkit for building out your site in the CMS. It has tremendous power but bolted on top of that is this toolkit which makes it possible for someone with only HTML skills to build out an entire solution. There is an underlying API called RQL (Reddoot Query Language) that basically has access to everything to modify built in behavior but it's aimed squarely at programmers. I built some very complex sites and never personally had to use the API, for example - http://www.ciena.com uses nothing but the built in tools to accomlish nested linking, breadcrumbs, popups, content reuse and syndication, etc. Anytime you question their tech support people about creating non-standard CMS behavior they just tell you to use the API, that's it. I'd personally rather see more effort behind strengthening things such as wizards/tools and content relationships than bulking up APIs no one will use and frameworks that will just get increasing complicated. Ryan's point about Eto's simplicity is perfect, I chose it for that very reason. I know practically zero PHP but got a site up with a couple hundred pages. Now of course it isn't as flexible as it could be (see my post about content reuse. no, really, someone please take a look at it.) and with increased power comes greater responsibility (er...wait...).

I've said it before, the "C" in CMS is there for a reason. It really should be all about the content and making it easier and more flexible for developers to build out solutions for Sally in marketing to post news and product info, etc.
OK I'm done preaching :wink:

In my opinion, 90% of this email should be considered a "mission statement" for our future.

There are tons of CMSes out there allow developers to have all sorts of flexibility. Our product should be just about seperating the content (which could be little more than Word Documents posted into a WYSIWYG interface) from the code (which for the most part, if it is as dificult to implement as PHP, then why not just write the PHP itself or use a Snippet?).

The best example I can make for you to understand my love of the product is this: I had to design a quick website for a sitting member of the Minnesota House of Represenatives when she was campaigning last year. I designed the entire website using Photoshop to create the Header, navigation and body. I then exported the slices using Imageready's "Save to Web" feature. All I did with Etomite was simply add TITLE, MENU, and CONTENT tags.

Bam. Site done. Her campaign manager added the content himself and I hadn't heard a peep out of them after the fact.

THAT is the power of this product.

All I did with Etomite was simply add TITLE, MENU, and CONTENT tags.

Bam. Site done. Her campaign manager added the content himself and I hadn't heard a peep out of them after the fact.

THAT is the power of this product.

You speach mucher better than meself ( ) but all kidding aside, that is exactly the point I was trying to make earlier.

Quote from: infoclipper at Apr 06, 2005, 01:56 PM

All I did with Etomite was simply add TITLE, MENU, and CONTENT tags.

Bam. Site done. Her campaign manager added the content himself and I hadn’t heard a peep out of them after the fact.

THAT is the power of this product.

You speach mucher better than meself ( ) but all kidding aside, that is exactly the point I was trying to make earlier.

I wanted to resurrect this topic. I am currently uploading MODx to replace .6RC2 to a site that is used by older folks. You know, those that didn’t get a cell phone until just recently...thinking they would only use it for "emergencies only"

I trained them to use Eto because it was easier to teach them than teaching them FrontPage or Dreamweaver.

While I think it would be cool to get the techedge people, our bread and butter are going to be those that have no clue how to use anything more technical than a word editor.