Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Introducing "xPattern" Workgroup
@guiguibonbon:
The whole reason why the idea occurred to me in the first place was that I was running into situations a lot that required custom-content types. Maybe not 4 date fields, specifically, but types that were fundamentally unsuited to the standard TXP “article”. Using all manner of plugins to coerce the article to fit other needs, I finally thought “why not just make content flexible and stop doing backflips”.
Not that backflips aren’t exhilarating!
Offline
Re: Introducing "xPattern" Workgroup
For me this originally came out of thinking about building a plugin that would display a different set of custom fields per section. The more I thought about it the more I realized that was I was trying to accomplish was creating different content tied to different sections. That completely breaks the TXP semantic model. Sections don’t define your content. They define the presentation of your content.
As far as forking or whatever. If this works out I would be ecstatic if the changes we had to put into place became core, however it diverges from TXP’s original vision as a web publishing platform, which is why I think for now the approach of a different product is desirable. Not everyone might want the extra features, and it allows the core team to continue fine tuning the great publishing platform that TXP already is. The hope is that this will benefit both sides.
In the end we all decided to do this over using other systems because we love Textpattern. There is just something about it. It wraps itself around you.
Last edited by hakjoon (2007-05-23 16:41:58)
Shoving is the answer – pusher robot
Offline
Re: Introducing "xPattern" Workgroup
hakjoon wrote:
It wraps itself around you.
Eek, I’ve got TXP stuck on my shoe.
Offline
Re: Introducing "xPattern" Workgroup
guiguibonbon wrote:
Is the number of times people needed 4 time fields and three textareas really significant enough to fork?
It might be semantics and maybe I’ve not seen the bigger picture yet, but I envisage this more as a bolt-on extension (like MLP is for languages) rather than a new product per se.
TXP can – and will – continue to cater for the 80% of people (me included) who love its simplicity and flexibilty. But for the 20% of people who find themselves in situations that require “just that little bit more”, xPattern will hopefully augment the existing capabilities without sacrificing what we all love about TextPattern. It might not work, but we’re sure as hell gonna give it our best shot.
‘Fork’ is such a dirty word.
Not as dirty as ‘crevice’ though…
Last edited by Bloke (2007-05-23 18:43:48)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
#29 2007-05-23 19:37:49
- guiguibonbon
- Member
- Registered: 2006-02-20
- Posts: 296
Re: Introducing "xPattern" Workgroup
I agree on the dirtiness of the word. Yet, although the intention is not to “fork apart”, I can easily imagine it will have the same consequences (a new or at least sub-community, plug-in incompatibilities which in term will lead to two separate plug-in “platforms”, two bugtracking teams and systems, etc. etc.)
I really understand the need to be able to do more which I am very very very often confronted with, but I eventually always got there pretty fast. And seriously, getting the needed content to fit in the article-constraint has not even remotely been the most challenging. Pay-pal integration was far more. And, I must admit, I personally do enjoy these kind of challenges a lot. I could imagine that at one stage I could have a project where it would become impossible. But that would probably mean it’s time to try RoR.
Anyway, I sincerely wish you all the best of luck with it, and am looking forward to seeing it, and trying it out.
hakjoon wrote:
[…] creating different content tied to different sections. […]. Sections don’t define your content. They define the presentation of your content.
That I find a bit far stretched. That’s css you’re talking about ;) No, seriously, look at any magazine, or whatever, different sections do have different kinds of content, that therefore need to be presented differently. Categories don’t/shouldn’t, but then again, who ever said so and why would anyone?
Offline
Re: Introducing "xPattern" Workgroup
guiguibonbon wrote:
But that would probably mean it’s time to try RoR.
But then you have to write the templating layer, the admin interface (Well I guess you can go with Django and skip this step), the plugin system, etc etc.
There is a lot that goes into getting something at the level TXP is now. Alot more then how the content is stored. When the system does 85% of what you want, do you really need to rewrite 100% of it to get the extra 15%?
I agree on the dirtiness of the word. Yet, although the intention is not to “fork apart”, I can easily imagine it will have the same consequences (a new or at least sub-community, plug-in incompatibilities which in term will lead to two separate plug-in “platforms”, two bugtracking teams and systems, etc. etc.)
Pie in the sky dreaming: If things go well we could perhaps shape some implementation details for crockery that could allow this to simply be a drop in class replacement, or and extension of a base article class, or who knows. At the end of the day no one of us want to go anywhere else or we would have just jumped ship to something that was already built.
Last edited by hakjoon (2007-05-23 19:53:08)
Shoving is the answer – pusher robot
Offline
Re: Introducing "xPattern" Workgroup
guiguibonbon wrote:
I really understand the need to be able to do more … getting the needed content to fit in the article-constraint has not even remotely been the most challenging. Pay-pal integration was far more.
Agreed! Hacking a shopping cart system with PayPal for one of my sites was a serious challenge, but a few (very) late nights and I cracked a workable system. At the expense of some more hair…
The problem, however, was not with me. I’m a hacker, so to me TXP is a dream. It was my Frontpage-loving business partner that struggled. Specifically:
- The custom fields for Price, Quantity, Size, etc appeared on every article Write page and I had to explain they should only be filled in if he was creating something to go in the ‘products’ section, not the ‘news’ section. To me it’s obvious; to him in his mid-50s it’s not.
- He had to remember to add all the product images first then associate them via article_image. Ok, that’s a TXP workflow issue (and there are now some cool plugins from bas_* and Mary that help) but xPattern may ease this even further when images become ‘just another type’ of content.
- The ‘Summary’ custom field was for use as meta_description; the excerpt was for a brief description of the item that the customer would see on article list pages. I explained that the Summary was “the bit that Google shows” (yeah I simplified it!) Looking back I could have auto-generated the meta_description for products from the excerpt (not sure if I’m penalised on SEO grounds for duplicating content verbatim…) but either way I couldn’t remove the Summary tag from the screen so again had to explain under what circumstances that should be filled in.
There were other “issues” he brought up, but it was a long time ago and I’ve slept since then. The upshot was he gave up and I now maintain the site. The whole point of me researching CMS solutions until I eventually stumbled upon TXP and fell in love was to shift the load off me. That backfired! To him, if it takes more than 3 clicks to accomplish, or if there are more than 3 boxes on-screen he gets lost or assumes it’s too difficult. If something’s spread across more than one page, forget it, he goes back to Frontpage (spit)!
Maybe TXP just doesn’t fit at all with people like that because, after extolling its virtues, when I came to actually explain how to use it I realised it wasn’t all that easy for people that aren’t willing to put the time in, or those that are ingrained in a particular mindset.
To me, the fun of a system is bending it to breaking point and making it do what it isn’t supposed to do. Hence my love of Linux/UNIX and my loathe of “you can’t do that, you might hurt me” Windoze. In some sick way I suppose the draw of xPattern is in making TXP do something it ain’t supposed to!
My hope for xPattern is that the underlying database structure will allow us to simplify the tags and clean up the interface at the same time, showing only those bits that are relevant. It may still be too complicated for my business partner to grasp but I feel I’ve gotta try…
Last edited by Bloke (2007-05-23 20:57:48)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Introducing "xPattern" Workgroup
mrdale wrote:
@Christopher: Your avatar freaks me right out.
Yep, you understand the concept 100%. However, for backward compatability purposes, the links tab (and the standard bq. 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?
Makes perfect sense. Hmmm, maybe time to change my avatar?
Last edited by Christopher (2007-05-23 22:10:41)
Offline
Re: Introducing "xPattern" Workgroup
Offline
#34 2007-05-24 01:43:59
- nardo
- Member
- From: tuvalahiti
- Registered: 2004-04-22
- Posts: 743
Re: Introducing "xPattern" Workgroup
Bloke – those type of client situations – LOL – I hear ya!! even when clients are regular internet users and have experience with hosted blogs, flickr, etc, it can still get sticky… personally I would like to be able to offer the client a completely detached interface for adding content, and customise that to label the fields exactly how they appear on the site (I guess this is XML-RPC, SOAP, I never really paid much attention to these previously!)… or using Manfre’s plugins
I don’t have guiguibonbon’s chops but from experience find that abstracting right out creates a lot of work & costs a lot of hours; the return on that investment is not guaranteed, as websites often need significant changes within 2-4 years, or the client ends up delegating content input to you… Textpattern as a publishing tool offers a good compromise, altho I am talking more about abstracting out sites to allow clients ultimate flexibility in adding sections/categories etc… often clients prefer a clearly-defined set of ‘rules’ for adding content (agoraphobia)
not knocking the project tho, and this is just some tangenital ramblings; all power to u!
Offline
Re: Introducing "xPattern" Workgroup
Bloke wrote:
Hence my love of Linux/UNIX and my loathe of “you can’t do that, you might hurt me” Windoze.
Linux is one big forking party :)
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
Re: Introducing "xPattern" Workgroup
Man, I must be busy, I haven’t kept up on this thread at all, I’ve been too busy xpatterning.
I don’t know about the rest of you, but this stuff is exhilirating to me.
The dev group is thinking about good stuff too. There is good movement in TXP.
I for one am psyched.
M
- I am Squared Eye and I
am launchinghave launched Pattern Tap
Offline