Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#145 2011-08-10 21:08:12

renobird
Member
From: Gainesville, Florida
Registered: 2005-03-02
Posts: 786
Website

Re: The direction of Textpattern 5

aswihart — that pretty much sums it up.

Devs — any chance this is being pursued?

Offline

#146 2011-08-10 22:04:38

artagesw
Member
From: Seattle, WA
Registered: 2007-04-29
Posts: 227
Website

Re: The direction of Textpattern 5

Please take a look at Escher, specifically pages with custom page parts and custom metadata, and models to capture recurring combinations of page parts/metadata.

In Escher, I can easily imagine setting up a page model for a “song” page type with custom page parts (and/or metadata – you choose) for artist, album, length, rating, etc. Querying for songs would be done via Escher tags, just like any other page. Since songs are modeled as pages, they each have a unique URL, and so are proper RESTful resources as well.

If this type of approach meets your needs, then yes, I would say it is possible. If not, then I can’t say anything more definitive at this point, but Stef, Jeff and Robert may have other ideas.

Offline

#147 2011-08-10 22:17:42

maruchan
Member
From: Ukiah, California
Registered: 2010-06-12
Posts: 590
Website

Re: The direction of Textpattern 5

Sam, thanks for all your work on Escher. I love the way you can do just the things people are asking about here. I also like the staging/testing functionality.

However Escher is a major WIP right now. I for one would hate to see potential new directions for TXP watered down because they exist in Escher already. Escher isn’t really an option yet for many of us, as there is a laundry list of required functionality that either represents a lot of work or a lot of waiting.

For example, at this point it would be much easier for me to move all TXP sites to e.g. ProcessWire in search of native custom content types than it would to go from TXP to Escher. ProcessWire already has a few choices of admin theme, quite a few community contributions and a level of polish that really shines in a demo.

However, I’m excited to see Escher grow and look forward to seeing new developments there. I just hope that Escher++ doesn’t imply TXP5—.

Offline

#148 2011-08-10 22:44:18

aswihart
Member
From: Pittsburgh, PA
Registered: 2006-07-22
Posts: 345
Website

Re: The direction of Textpattern 5

Sam — Thanks for your response, I apologize I’m not very familiar with Escher, but it sounds like it supports custom content types in the way you described. Surely, there is no reason Txp 5 couldn’t do something similar, with its own conventions, the question is will it happen?

I’d like to give Escher a try sometime, I’ve just briefly poked around the demo admin, looks powerful! But to be honest I’m currently on a Django binge that I don’t see ending any time soon. The learning curve is steep compared to any CMS (save perhaps Drupal?), but now that I’m comfortable with it, I’m addicted to the unparalleled flexibility a web framework provides, not to mention the fact that you can build web apps with it.

Still keeping a keen eye on Txp though and have high hopes for its future!

Offline

#149 2011-08-10 23:22:16

artagesw
Member
From: Seattle, WA
Registered: 2007-04-29
Posts: 227
Website

Re: The direction of Textpattern 5

maruchan wrote:

However Escher is a major WIP right now. I for one would hate to see potential new directions for TXP watered down because they exist in Escher already. Escher isn’t really an option yet for many of us, as there is a laundry list of required functionality that either represents a lot of work or a lot of waiting.

I’m not proposing you switch to Escher. Simply that you look at the way it solves some of these problems, because if they are reasonable solutions within the context of Textpattern, then they might be ported to Textpattern more quickly than devising entirely different solutions.

I’d like to hear the items on your laundry list, because that can only help me to improve Escher. For my part, I can’t imagine any kind of site that I could build in Textpattern that I could not also build quite easily in Escher. Lack of themes is a legitimate issue, but one that will be resolved in time as more people begin using it. Still, that’s not related to the software’s core functionality, which is already quite strong.

Offline

#150 2011-08-10 23:44:44

maruchan
Member
From: Ukiah, California
Registered: 2010-06-12
Posts: 590
Website

Re: The direction of Textpattern 5

I’m not proposing you switch to Escher. Simply that you look at the way it solves some of these problems, because if they are reasonable solutions within the context of Textpattern, then they might be ported to Textpattern more quickly than devising entirely different solutions.

Ah, that makes a lot of sense to me. Re-reading my post I think I came off a bit critical, apologies for that. But I think I had been reading an “Escher already has…and TXP5 wants to stay true to TXP, so…” stance into some TXP5 discussions and was a bit concerned that my hopes and dreams would not be coming to TXP5. ;-)

I’d like to hear the items on your laundry list, because that can only help me to improve Escher. For my part, I can’t imagine any kind of site that I could build in Textpattern that I could not also build quite easily in Escher. Lack of themes is a legitimate issue, but one that will be resolved in time as more people begin using it. Still, that’s not related to the software’s core functionality, which is already quite strong.

I don’t know if I agree about what is or isn’t core functionality, but I’m really happy to see that you’re actively improving the software.

I mentioned this to you on Twitter but I think that working with assets is a bit rough right now. Drop-down menus for choosing images are fine for a demo site, but I know my clients with 100+ images would want a sortable list + search functionality. Ditto with files.

That is not what you would call core functionality, but to me this is a vital area to cover for even an average user experience. For users who are only using Escher for personal projects, maybe not so much.

Anyway, end of derail…

Offline

#151 2011-08-11 00:35:38

tye
Member
From: Pottsville, NSW
Registered: 2005-07-06
Posts: 859
Website

Re: The direction of Textpattern 5

aswihart, renobird, Mr Dale & anyone else who agrees – Custom Content Types +10000000000

This is what I was eluding to in this post – but didn’t know the correct terminology and didn’t explain it too well

Offline

#152 2011-08-11 00:35:39

aswihart
Member
From: Pittsburgh, PA
Registered: 2006-07-22
Posts: 345
Website

Re: The direction of Textpattern 5

Sam — I am watching the video for your 0.9.2 release, great stuff, really impressive. So, although I’m just scraping the surface, it seems like you’ve got a really nice, working solution to the custom content types problem, implemented in a way similar to what I would expect in Txp. I still need to learn more about how Models work with Pages and the other pre-defined content models, but I’m liking it. I’d say the devs should take a look at your methods for inspiration if not copy them.

Give the lack of documentation, I can’t say for sure, but is the et:pages:each tag the equivalent of txp:article? It would be amazing if you could use a new tag on the fly like txp:song, as I described earlier, rather than <txp:article model=“song” />. Think that’s feasible?

And just curious, how are Escher’s “Pages” stored in the database, separate tables or all in one dumping ground a la Txp’s Article? Obviously, depending on how you use Pages, it would be better to have separate tables for different models. I realize the database implications of this are daunting, but is it possible?

Last edited by aswihart (2011-08-11 01:32:22)

Offline

#153 2011-08-11 01:21:28

aswihart
Member
From: Pittsburgh, PA
Registered: 2006-07-22
Posts: 345
Website

Re: The direction of Textpattern 5

Also, this might be controversial, imagine if the currently predefined models (article, image, link, comment, file) were converted to default model templates. You would select a template or start from scratch and customize your content type (let’s call it a model). You could have two image models, for example, but they wouldn’t even really have to be called image models, they’re models with an image field. One could be txp:coverart and another txp:avatar.

Would this be a fundamental shift away from Txp as we know it? What do other people think? The database implications of this aren’t clear to me, but I’m guessing it would have a good chance of breaking backwards compatibility.

Offline

#154 2011-08-11 01:32:29

johnstephens
Plugin Author
From: Woodbridge, VA
Registered: 2008-06-01
Posts: 999
Website

Re: The direction of Textpattern 5

Would this be a fundamental shift away from Txp as we know it? What do other people think? The database implications of this aren’t clear to me, but I’m guessing it would have a good chance of breaking backwards compatibility.

I have to say that I’d be a lot happier with something like <txp:article model="song"/> than <txp:song/>. Making any kind of custom content type its own txp:tag seems like too much potential for namespace collisions.

Offline

#155 2011-08-11 01:44:32

aswihart
Member
From: Pittsburgh, PA
Registered: 2006-07-22
Posts: 345
Website

Re: The direction of Textpattern 5

johnstephens wrote:

I have to say that I’d be a lot happier with something like <txp:article model="song"/> than <txp:song/>. Making any kind of custom content type its own txp:tag seems like too much potential for namespace collisions.

I appreciate that if it is an issue, I don’t know. It adds up to quite a bit of extra markup after a while and is harder to read, but the functionality is the most important thing.

Offline

#156 2011-08-11 05:27:07

artagesw
Member
From: Seattle, WA
Registered: 2007-04-29
Posts: 227
Website

Re: The direction of Textpattern 5

maruchan wrote:

I mentioned this to you on Twitter but I think that working with assets is a bit rough right now. Drop-down menus for choosing images are fine for a demo site, but I know my clients with 100+ images would want a sortable list + search functionality. Ditto with files.

I agree – this is a completely valid criticism. Escher 1.0 is all about the site developer/designer and giving him/her a powerful set of site creation tools. It’s much less about the client/end user. That will be the focus of Escher 2.0.

Offline

Board footer

Powered by FluxBB