Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#13 2007-05-19 17:09:48
- lee
- Member
- From: Normandy, France
- Registered: 2004-06-17
- Posts: 831
Re: Introducing "xPattern" Workgroup
This is good news, well done for putting it all together.
Offline
Re: Introducing "xPattern" Workgroup
Thanks lee, hopefully we will be posting regular updates, starting soon.
Offline
Re: Introducing "xPattern" Workgroup
Like the idea.
Will xpattern content-types for example ‘event’ have the facility or flexibility to output the data as a microformat hCalendar?
Forever learning.
Offline
#16 2007-05-20 20:02:25
- guiguibonbon
- Member
- Registered: 2006-02-20
- Posts: 296
Re: Introducing "xPattern" Workgroup
Er… good to see a working group. Very good. Nice dynamic.
But.
Building on crockery won’t get you far. Not seeing a plausible release date coming would, at least that’s what I think, discourage many of you very soon. Or might push you into releasing crockery too early. Anyway, all around, having two dev teams working on the same app is not right.
I had been thinking about another solution to pretty similar options. Have you noticed txp now has XML-RPC? Which means, you could now build a parallel cms, only for editors, that acts solely through XML-RPC, and totally independently form txp. Basicly, the architecture would be :
- txp release
- plugin that let’s you define “content-types”
- independant interface that allows users to insert content in txp through XML-RPC, in any fashion that was submitted through the plugin.
Do note XML-RPC might need some improvements in order for this to work perfectly. But, you keep txp just as it is, without adding any possible bugs to it, not to mention way too many plugin incompabilities.
Another advantage to this is the total freedom it gives regarding how one inserts content in txp. Think for instance : finally allowing images to be uploaded from the same page as the one you’re writing articles from.
This would, in my opinion, be a much more efficient way of working. And might anticipate the release date of xpattern a lot.
Count me in if you like this idea. But as it is being presented right now, I rather work on things that fix bigger problems with less efforts.
Offline
#17 2007-05-20 20:44:37
- guiguibonbon
- Member
- Registered: 2006-02-20
- Posts: 296
Re: Introducing "xPattern" Workgroup
Ok, just realising it needs a few more explanations. Basically, consider textpattern as allowing already to input content with :
- one numerical id that identifies it
- one string that identifies it (title)
- one string that says what kind of content it is (section)
- two strings that allow the items to be grouped, browsed and searched (categories) – plugins to transform that to two lists already exist (infinite number of strings)
- two text fields
- one list of images
- ten absolutely versatile fields (custom fields – can be absolutely anything)
- two time strings (published and last modified – one can already be used for anyting other time data – plugin could do the same to the latter)
- two strings that relate to accounts or people (author and “last modified by”)
I’d have a hard time finding any type of content that wouldn’t fit inside that. Conclusion : changing that would have you rewriting txp almost entirely for only a very small gain. Therefore, I say : just make an interface that allows to label those fields differently, XML-RPC can help a long way. If you are bothered with still using tags like “body” and “excerpt”, a small plug-in can do some trickery for you. Overall conclusion : no hacking/forch needed.
Last edited by guiguibonbon (2007-05-20 21:33:57)
Offline
Re: Introducing "xPattern" Workgroup
@guiguibonbon:
To tell you the truth, i’d never thought of that approach, I’ll give it some thought, and let others think about/comment on your approach. Thanks for your idea.
I do think that what we’re suggesting is vastly more powerful at it’s core and a much cleaner/more modular/more elegant platform to move forward with than the rather limited way TXP is currently set up. Just my 2c.
@anthonybooth
I don’t see why some kind of hCalendar microformat would not be possible. It’s definitely something to look into.
Offline
Re: Introducing "xPattern" Workgroup
@guiguibonbon,
It can be done that way but it’s kind of kludgy, since you are still bound by the limits of the article table. What happens if you need something with 3 textareas, or 4 date fields? Plus you still have Links, Images and Files which live in their own little world. The goal of this is to make them all behave uniformly.
Shoving is the answer – pusher robot
Offline
#20 2007-05-23 14:44:42
- guiguibonbon
- Member
- Registered: 2006-02-20
- Posts: 296
Re: Introducing "xPattern" Workgroup
4 dates : 2 extra custom fields
3 textareas : special syntax (e.g. ===== breaks textarea in two) or transform a custom field column to text.
It just needs a bit of ingenuity and a cool plugin that would easily allow this kind of data tweaking.
I’ve been thinking. Part of what makes txp what it is, is its simplicity. It comes with a model (articles > sections / forms > pages) that makes it easy to understand from the first time, and it has the flexibility that allows it to go much further with the needed ingenuity. It’s a cool mix somewhere between a cms, a php library and almost a language of its own. What is being suggested here is something entirely different, that requires much more understanding for a beginner. It’s basically RoR, only not as elegant or flexible, and with a bunch of unneeded layers — since it really just becomes a way of creating tables with a “handy” way of inserting and displaying content.
What do you actually intend to keep from txp? I guess the section/category urls won’t really cut it any more. I’m even guessing comments will also be thrown in the “content-type” pool. It seems to me this will only be a “halfway there” thing.
So, basicaly, what i’m saying is : better solutions are out there already if you want true modularity. You’re loosing a vital thing (simplicity/clarity) in exchange of a pretty small gain (modularity for its own sake yet not in the best way there is). I would rather keep the simplicity and improve the extendibility.
This being said, I’m open to surprise. Maybe this will be awesome, and maybe I will end up finding that xPattern achieves what I want faster than Textpattern.
My main regret is that much more significant and sustainable progress could be made for the same amount of time and work.
Offline
Re: Introducing "xPattern" Workgroup
@guiguibonbon: Thanks for your thoughts.
You’re right. TXP’s simplicity and elegance is why we’re all devotees.
How well we’ll do with retaining that flavor, I can’t say, but we’re aiming high. There are some experienced people involved, we all respect TXP’s existing setup and we’ll be keeping in close contact with the core devs along the way
We won’t lose simplicity at all, and in some regards I think we are actually simplifying existing methods further- No more is required from a beginner. A user could build with xPattern in exactly the same way as he does now, same tags, same methods
- We’re augmenting TXP to allow a mere few more tags that open up a whole range of custom content possibilities.
- xPattern will use the same method (content-tag + forms) across the board for all content types, rather than different methods for different content-types (images, links, files). To me this is inelegant as it stands, forcing a beginner user to learn different rules for images, articles, etc.
- We’re aiming to address a few things that have been perennial requests (unlimited categories, categories not tied to content types) that will also simplify.
Don’t worry, I don’t think we’re diverting any energy from the core development, just exploring a useful “what if” scenario. Our participants are motivated. I don’t think it will be a waste of time. Instead I think we’ll flesh out some features that will allow TXP to breathe a little easier as it moves far beyond it’s blog engine roots.
Thanks, I appreciate your thoughts despite the fact that I disagree.
Last edited by mrdale (2007-05-23 15:35:04)
Offline
Re: Introducing "xPattern" Workgroup
I like the sound of this and it’s similar to something I’ve been thinking about.
As an example to help me understand the concept, with xPattern posting a “Link” would essentially involve selecting a “Link” content type from the Write tab and then filling out the same fields you’d get from the “Links” tab in the current version of Textpattern? And categories are accessible across all content types, rather than content specific?
Last edited by Christopher (2007-05-23 19:52:03)
Offline
Re: Introducing "xPattern" Workgroup
@Christopher: Your avatar freaks me right out.
Yep, you understand the concept 100%. However, for backward compatability purposes, the links tab (and the standard content-type) will likely stick around.
BUT… with xPattern, You could create your own super-dooper-link content-type with whatever fields you’d like to add.
Make sense?
Offline
#24 2007-05-23 16:09:47
- guiguibonbon
- Member
- Registered: 2006-02-20
- Posts: 296
Re: Introducing "xPattern" Workgroup
mrdale: I’m not saying there’s a waste of time nor that it would divert any energy anywhere. Just wondering how interesting this is in terms of a gain/investment ratio, for you guys. I can see tons of things that could be done to significantly improve and strengthen TXP with far less efforts.
Is the number of times people needed 4 time fields and three textareas really significant enough to fork? In this consideration, isn’t a plug-in of the kind I mentioned simply the smartest way to go? Although I understand it’s not as pleasant a thing to develop.
In what I would consider to be easy stuff that brings great advantages without forking: split dev & editor platforms entirely, building the latter on XML-RPC. Make the dev side more dev-friendly (save at least two versions of pages/styles/forms when saved, make textarea-inputs friendlier – i’m tired of copy-pasting tabs, easier plugin creation,…), make the editor side more writing-friendly (image-uploads on write page, different input fields depending on section selected, nicer UI, …). All just examples, to illustrate.
Is that Aphex on that scary avatar?
Last edited by guiguibonbon (2007-05-23 16:17:42)
Offline