"Content-Type" Abstraction

mrdale · 2007-01-12 22:52:04

Epiphany
How about abstracting content types to the point that you could create your own combination of content: custom fields, standard fields, categories, sections, images, files and links as it’s own content type.

As you create custom content types they simply appear as siblings to the articles, images, links, files tabs. You can associate one content type with another in the same way that images are associated with articles.

Here’s a use-case.

TXP has to jump through hoops to make a directory of people. But let’s say you had content-type abstraction. You’d be able to create a new content type called ‘people’ then add text fields for name, address, city, state, zip, phone, fax, email, IM. You’d add a file field for the person’s resume. You’d add a picture field for the person’s image. That’s it.

Then you get a sibling tab to the articles tab, called ‘people’ and when you click write, you’d get a select that lists content types, and the fields displayed would vary according to your selection.

But you’d also be able to edit the ‘article’ content type to include people as a field.

So imagine you’re putting together an article about five people who wrote a book about TXP. Then you’d be able to use a multi-select to associate those ‘people’ with my article, then use article tags and forms as per usual, to specify how items in your ‘content type’ are to be displayed.

Not only would I be able to easily have an area of my site that is a people directory, but I’d be able to grab entries from ‘people’ to include in different content types.

Essentially, by placing images, files, links, articles and custom types on top of a layer of abstraction, you’d solve the current limitations of custom fields, make all kinds of new types of content possible and empower TXP. Imagine being able to create images, albums, movies, cars, events, books, products— all as content-types all with their own discreet place in the content tab.

You’d also be solving a lot of the redundancy, idiosyncrasies and limitations of current content types. for example, there’s been a lot of support for the idea of a more robust image tag. Under this scenario, the image tag would behave exactly like the article tag and direct to a form for display of a single image or image list.

You wouldn’t have to have multiple redundant category classes, they’d just apply to every content type. No more setting up ‘my_category’ in images and in articles.

So instead of:

<txp:article /> you might have <txp:content type='article' /> or…
<txp:image /> you might have <txp:content type='image' form='content-fruity-image' /> or…
<txp:content type='custom movie' form='big-list'/>

You’d change: <txp:if_individual_article> it’d be <txp:if_individual_content>
You could also add conditionals like <txp:if_content type="custom movie">
Article forms would become content forms. etc…

I’m curious to hear other people’s thoughts. Remember this is an idea and not a request, so assume I understand that this community and TXP itself moves forward as a result of the generous efforts of dedicated devs, etc… and that I’m just looking for feedback on the idea itself.

Here endeth the worlds longest post. Cheers!

Last edited by mrdale (2007-01-13 01:10:39)

wet · 2007-01-13 07:59:31

Hmm. Looks like you wanted drupal and their Content Construction Kit.

colak · 2007-01-13 10:07:00

Hi Dale
Although I like the idea(s) my main worry is the backword compatibility. I’ve been using txp for about 2 years now and my sites have 100s of posts parsed through a series of templates, forms, plugins etc. My main worry is that a major change like that would ‘disable’ most (maybe all) of the sites as we will all need to redesign in accordance to the new tags.

I am all for content types but maybe using a method which will not turn txp into another application.

I strongly believe that the strongest web applications are the ones which they add functions without breaking existing sites in the process.

mrdale · 2007-01-13 17:20:31

>wet

Aha, you guessed it. I do a couple of projects in Drupal, but I do prefer to build on TXP (no contest), but I was blown away by CCK and abstracted content types.

For the most part Drupal is extremely powerful and modular, but lacks the presentation flexibility, the clear content-presentation dichotomy and overall elegance of TXP (things I admired from first look.)

What has been a little frustrating, has been wanting to build a project (specifically a book project) in TXP but having to use Drupal because it handles that type of content vastly better. Now if I could code, I might build a ‘book’ plugin, a ‘revisions’ plugin and a content ‘diff’ plugin but sadly I can’t. A TXP CCK would allow a lot of users to quit asking for other people to code plugins and just build content types as they need.

>colak

I guess you are right. Sometimes though, in order to stretch past limitations you have to bite the bullet. OS9 / OSX is a good case in point. You could provide legacy support through deprecating tags but keeping them alive during a transition.

Not sure what you mean by …another application…

When I played with the CCK, I found myself wondering how insanely great a CMS, TXP would be if it had content-type abstraction. It would certainly provide simpler solutions to perennial discussins and plugin solutions such as directories, events calendars, image handling, etc…

So is it ever going to happen, no. Not unless someone a lot smarter and more connected to the dev team thinks it’s a good idea. I just saw a way for TXP to get MUCH stronger, so I thought I’d share. But it’s certainly worth discussing.

Cheers.

colak · 2007-01-14 08:35:49

@ mrdale

I am a mac user and the leap from OS9 to X was a huge one and not necessarily always a better one. In X for example some apple apps, work only if you have the latest revised system without any backward compatibility… Their support is disgusting. ~~Many~~ All of my emails to them were left unanswered… (but this is another discussion).

I am not against a content sensitive txp, I just think that the ‘method’ for that should be backward compatible. There could be an extra tab or extra fields in the existing database. There could also be a user friendly way to create extra text (or whatever) fields where these content types could be parsed…

I believe that the exiting tags should remain but new content sensitive tags could be created to allow for user controlled expansion…

Like you i’m not a programmer so i do find it easy to write like I just did as I do not know the implied work volume involved. I ~~would like to~~ believe that the dev team do not work with their connections but with this forum so if what us users discuss, they would implement if there is enough interest by the user community and it makes sense for txp.

Last edited by colak (2007-01-14 08:36:24)

Sencer · 2007-01-14 11:01:58

mrdale wrote:

So is it ever going to happen, no. Not unless someone a lot smarter and more connected to the dev team thinks it’s a good idea. I just saw a way for TXP to get MUCH stronger, so I thought I’d share. But it’s certainly worth discussing.

It has nothing to do with connectedness; It’s about costs and opportunity costs. When you have tight resources, you go (as a rough rule of thumb) for the ideas that are in high demand, yield high benefit and where the effort is, if not moderate, at least well plannable. There’s very many resources that are tight, but if there is one that’s not, then it’s ideas. Whenever we spend time doing for example subsections, we cannot spend that time doing any of the dozens of other cool things that are possible and that float around as ideas.
Also consider that we’ve been critized in the past for being too developer-oriented/-minded and not enough end-user-centric. Adding to the complexity and abstraction needed to use textpattern is certainly not going to help in that respect. Everybody knows what an article is, or what a link is. But start talking about content wigglets with content-types and you get question marks all over the place. (“Content-Type” also has a different, well established meaning already, and we’d be heading down the same road as with “form” already…).

You are arguing for consistency, that’s a good thing. Yes, tags should behave consistently. There’s different ways to achieve that. Is adding levels of abstraction for the end-user the best way to go about it? That’s debatable. Also: If the type attribute becomes obligatory, you have not gained anything, as you merely shuffled around syntax. And how often is there a use-case where you want to show a mixed list of articles, files and images. This idea also is perpendicular to the idea of being able to associate files and images with articles.

create your own combination of content:

That’s a seperate idea from the abstraction of content-types, which is why I will treat it seperately. You want to turn txp into a CRUD-type “application builder”, it’s programming without writing code. This is shifting the focus of what textpattern is tremendously. Of course custom fields are very limited currently, and yes it’ll see improvements over time to allow for more flexibility and power. But what you are suggesting goes well beyond that in scope, in terms of functionality, in terms of time/resources needed to make that happen., and in terms of focus of textpattern.

Jeremie · 2007-01-14 13:04:07

Yup they are right, it’s the the goal of Textpattern (as far as I understand it). You may want to look into Drupal, Typo3, Xaraya, or even pure frameworks such as Rails.

Hence, thread moved to General discussions.

Last edited by Jeremie (2007-01-14 13:04:54)

RussLipton · 2007-01-14 15:16:42

I guess this is all obvious (and has been stated regularly at different times before) but I have found this very helpful. I share Mr Dale’s wishes, but Sencer’s answer was an elegant description of the necessary distinctions between Textpattern and Drupal. Not being familiar with Drupal, I would substitute an emerging product like MODx.

MODx will (sort-of already does) blow Textpattern away re: raw power and flexibility, but it is inherently complex and support-heavy just because.

I should say: MODx is simple at the beginning, but its insistence on extreme flexibility ensures that designer and developer paths will quickly diverge from one another due to the very lack of constraints we all love in theory but find confusing in practice. (I mean large communities find confusing; thank goodness for developer-centered power tools). For those with the skills and mindset, MODx appears extraordinarily elegant, but I doubt it will ever appear so to a large community of helluva bright ‘other’ thoroughly professional designer-developer folks.

(I hope no one sees me as knocking MODx; just positioning it as an example with which I am modestly acquainted.)

It is going to be very dicey, if vital, to evolve Textpattern to support (somewhat) more complex applications without breaking its original design point (e.g., no longer being ‘Textpattern’). That is where any true community fears, should they exist, be focused.

Simplicity and consistency not a matter of backward compatibility per se, though it often includes it. What should the developers do if Textpattern needs to break backward compatibility to become more simple and extensible for the coming decade, rather than the coming year or two? It’s ‘living within one’s means’ architecturally as well as financially; perhaps the former even more than the latter.

I would find it fascinating someday (I mean, applicable, not empty verbalizing) if veteran Textpattern users would brainstorm how the next major version could simplify ‘Textpattern’ – Textpattern-plus-plugins. I’m not knowledgeable enough to say.

User-customization of the admin interface; ‘elements’; custom field limits/ flexibility enhanced – vital, I know. Please, yesterday ;-). But how can (even) those be integrated so simplicity is increased, not lessened? And how can the current platform be simplified – fewer core features – while the interface/management of plugins is strengthened (e.g., simplified). That kind of effort takes genius and the guts of a gambler.

I know. Obvious. Trite. Shallow restatement of things that have been said many times, including this thread. I’m not implying that Mr. Dale has a different objective. He seems to be a vital community pillar these days. Since I’m blissfully semi-retired, Textpattern is a fun hobby for small projects for me – my substitute for online gaming. My stake-holding is just past tire-kicking; I’m just a cheer-leader.

Textpattern is one of only a handful of interesting, open-source projects that keeps trucking forward against all odds …. passionate, demanding, contributing community meets passionate, demanding, contributing developers. I’m really just expressing my thanks – to Mr Dale as well as Sencer – for recentering my own expectations. Fantasies ;-).

Jeremie · 2007-01-14 19:15:55

Yup, elements will be interesting, once we will understand what they are, and how they can be used on a day-to-day site building.

However, to a software (Textpattern) that still can’t allow a non-geek to write a simple references from a item (an article) to another item (article, image, link) in an elegant way, I would say: don’t get ahead of ourselves. The fundamentals and basics need to be covered first.

mrdale · 2007-01-14 19:25:24

>colak

Sorry your experience with the X transition was a tough one. Mine too, but at this point there’s really no comparisson. I can simply do way more…

I think you are right about keeping existing tags active, while adding one new one.

>Sencer

First. Utmost respect. (Wondertag, google-sitemap and your cache. ‘nuf said)

It has nothing to do with connectedness

It wasn’t a veiled criticism, just a cheeful acknowlegement that a change as deep as this won’t happen unless Team Textpattern thinks it’s a good idea or the community indicates resoundingly that they need it prompting someone smarter than me to code it as a plugin.

Experience tells me that if something as universal as a ‘save as’ button on the write page has trouble making it into the core after numerous suggestions, a far-reaching architechtural change is simply not going to happen, no matter what I want for Xmas.

Adding to the complexity and abstraction needed to use textpattern is certainly not going to help…

On elegance and simplicity; I do think you can have your cake and eat it too. You could update the architecture, making very little change in the interface. You’d still have write-tabs, etc and no one would ever have to create a content-type unless they wanted/needed to.

“Content-Type” also has a different, well established meaning already, and we’d be heading down the same road as with “form” already…

I see ‘Form’ as a ‘presentation abstraction’, while ‘content-types’ would be a ‘content abstraction’. Semantically I think they have an extremely different, but analolous function. I think they are complementary not redundant.

s adding levels of abstraction for the end-user the best way to go about it? That’s debatable.
I’m not suggesting ‘layers’ but a ‘single layer’ of abstraction.

This idea also is perpendicular to the idea of being able to associate files and images with articles.

I disagree. It is, in fact, just a more flexible way to associate content with content. However, I do see that you’d have to watch out for circular logic and infinite loops.

If the type attribute becomes obligatory, you have not gained anything, as you merely shuffled around syntax. And how often is there a use-case where you want to show a mixed list of articles, files and images.

I think it’s obvious that the scope of a flexible content-type extends quite beyond simply shuffling around syntax without function. There is a perrenial need to present mixed lists of a variety of content types, and this is currently filled by very specific plugins.

You want to turn txp into a CRUD-type “application builder”, it’s programming without writing code. This is shifting the focus of what textpattern is tremendously.

Ok, so because I don’t know about CRUD, nor am I as well-aquainted with the scope and focus of TXP, I imagined that a rethinking of architechture might make TXP more powerful without sacrificing the simplicity of the interface that I have really enjoy working with.

>Jeremie

You may want to look into Drupal, Typo3, Xaraya, or even pure frameworks such as Rails. Hence, thread moved to General discussions.

Smack-down! You’ve arbitrarily decided that this is no longer a feaure idea, but a general discussion. And the whole point if you read the post is that I’ve been using Drupal because I can’t currently use TXP on several sites (which is far-and-away my first preference) because of it’s current limitations. So yes, I’ll keep working with Drupal. Typo3 makes me afraid, though, very afraid… :)

Redux

So I guess I’ll keep bringing up ideas that I feel passionate about, despite what I feel to be quite a bit of resistance. And who knows even if a complete revision of ‘content-types’ doesn’t make it perhaps eventually we’ll see a the revolutionary inclusion of a ‘save as’ button in the write tab of a core installation. ;)

Cheers.

Last edited by mrdale (2007-01-14 19:36:13)

Jeremie · 2007-01-14 19:54:21

The thread has been moved because it’s not a Feature idea, but a debate about shifting the whole point and focus of Textpattern.

Mary · 2007-01-15 06:39:29

…elements will be interesting, once we will understand what they are, and how they can be used on a day-to-day site building.

An element: think of the admin UI, urls and tags regarding files. That can be considered an element, and it already is, in crockery. You could, for example, make a completely customized file management system (complete with different tags) to replace the one that comes with Textpattern, without hacking anything. It’s better than a really big plugin, in that it would be more efficient (running native PHP rather than storing it in the db and eval-ing it) and wouldn’t require hacking or strange workarounds. It has the potential to be as simple or as complicated as you want.

Ok, so because I don’t know about CRUD, nor am I as well-aquainted with the scope and focus of TXP, I imagined that a rethinking of architechture might make TXP more powerful without sacrificing the simplicity of the interface that I have really enjoy working with.

Wikipedia: CRUD

Typically when you use this word, you’re referring to something that is more of a framework (Rails, CakePHP…) than a cms (Textpattern), or at least a cms built upon a framework (Drupal, ezPublish). Textpattern has never, to my knowledge, been intended to work that way, and so it is not it’s own framework. It has some framework-ishness to it, but it’s internally a vastly different approach and methodology. “A change as deep as this” would be a new application. It’s not a stupid or bad idea, it is, in fact, a common one. It’s just the reality it won’t particularly mesh well with Textpattern.

Please remember each of us has a million and one things to do. You manage your personal life, your hobbies, your work, etc. So do we. We also have to support lots of people, AND develop an open source application. It’s not like we sit around on our asses saying, “Ha! We will never add a “simple” Save as button! Ahahahahahahah!”

In the end, every feature request gets read and evaluated. Some get integrated, some don’t. Txp will never be the do-all, be-all application, just like every other application out there is not. You use what works best for the project at hand.

Textpattern CMS

Textpattern CMS support forum

#1 2007-01-12 22:52:04