Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: The direction of Textpattern 5
hcgtv wrote:
Think about it, if TXP5 is going to deviate substantially from what we’ve become accustomed to, and it may take a year to see the light of day, why not cut to the chase and start using Escher today?
Our intention is to preserve Textpattern’s unique character – the “secret sauce” that makes Txp what it is. Any changes we consider will take that goal into account. (I for one do not see eliminating such Textpattern concepts as front page, template-per-section, etc.)
Escher does not share this goal, and as a result, does some things quite differently. That said, it does have some features that Txp users have been demanding for some time. Many of these features will eventually find their way into Txp 5. If you need them now, or if you just want a taste of things to come in Txp 5 (feature-wise – not model-wise or UI-wise) I suggest giving Escher a spin.
Offline
Re: The direction of Textpattern 5
ruud wrote:
Is that a recommendation to switch to using Escher or is this something that is planned for TXP5 as well? :)
Neither. It is my personal preference, but the devs have not discussed it specifically.
ruud wrote:
Can this be extended even further. For example if an author ‘zem’ has multiple plugins, one of them being ‘contact’, could a user do this (taking ZCR as an example):
<txp:ns:zem:contact>
<txp:form>
<txp:email />
<txp:textarea />
<txp:submit />
</txp:form>
</txp:ns:zem:contact>Certainly. I made a decision to not support nested namespaces in Escher 1.0 for simplicity of implementation. But there’s no reason it could be supported.
ruud wrote:
And what rules are set to avoid namespace collisions between TXP core and plugins? TXP4 has registered 3-char prefixes for plugin authors.
None. Conventions and/or registry will need to be created.
ruud wrote:
Thanks.
Last edited by artagesw (2011-01-21 18:46:37)
Offline
Re: The direction of Textpattern 5
Bloke wrote:
I see groups as a nice way to logically subdivide your Forms into more manageable chunks, however I don’t agree with having fixed names for the groups. The default install should contain one or two groups to house the scant few default forms that we actually need, and you should be able to add / rename as many groups as you see fit to suit your site. Since the groups offer no functional distinction this is not a major issue, especially if the useless ‘Preview’ button is removed from the Forms tab.
That’s what I’ve campaigning for, but waiting for TXP5 to see it happen does make one wonder why such a small change has to wait for an MVC paradigm shift. Right now, these types are hard coded in /include/txp_form.php, as in no plugin can change or add to them.
artagesw wrote:
Our intention is to preserve Textpattern’s unique character – the “secret sauce” that makes Txp what it is. Any changes we consider will take that goal into account. (I for one do not see eliminating such Textpattern concepts as front page, template-per-section, etc.)
Well until we see a roadmap, I don’t know what’s in store. As for Escher, I like the concepts you’ve programmed into it, the same way I like MODx. It’s just the amount of years I’ve dedicated to learning Textpattern that I don’t want to give up.
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
Re: The direction of Textpattern 5
hcgtv wrote:
It’s just the amount of years I’ve dedicated to learning Textpattern that I don’t want to give up.
If you’ve dedicated years to learning Txp, you should be able to adjust to Escher in a matter of days, if not hours. It’s different. But it’s not that different. ;)
Offline
Re: The direction of Textpattern 5
So Happy! about this direction I feel like a teenager again. Posted happy thoughts on the blog.
Since we are re-factoring a lot of shizzle under the hood. How’s about my triplet of pet ideas.
- Unlimited categories (heck call em tags if you like)
- Custom content types (possibly with associations and nesting).
- glz-ish style custom fields
Awesome News!
Offline
Re: The direction of Textpattern 5
mrdale wrote:
So Happy! about this direction I feel like a teenager again. Posted happy thoughts on the blog.
Since we are re-factoring a lot of shizzle under the hood. How’s about my triplet of pet ideas.
- Unlimited categories (heck call em tags if you like)
- Custom content types (possibly with associations and nesting).
- glz-ish style custom fields
Awesome News!
Escher has all of the above (well, not nested content types). Read into that what you may.
Offline
Re: The direction of Textpattern 5
Bloke wrote:
The default install should contain one or two groups to house the scant few default forms that we actually need, and you should be able to add / rename as many groups as you see fit to suit your site.
That would be awesome. I could split that “always miles too long” Miscellaneous block into smaller, meaningful blocks.
Stuart
In a Time of Universal Deceit
Telling the Truth is Revolutionary.
Offline
Re: The direction of Textpattern 5
thebombsite wrote:
That would be awesome. I could split that “always miles too long” Miscellaneous block into smaller, meaningful blocks.
Here you go, a how-to for adding more form types.
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
#33 2011-01-22 00:41:42
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: The direction of Textpattern 5
“One click” TXP software upgrade would be great.
Built-in database backup & restore too.
Offline
#34 2011-01-22 00:49:48
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: The direction of Textpattern 5
and, please, no more:
- Add article
- List articles to get new ID
- Memorise ID
- Go to another tab
- Forget ID
- Go back to article list
- Memorise ID again
- Go to that other tab somewhere
- Type in ID
Drag & drop? Multiple admin panes – Articles on one side, Forms on the other?
Offline
Re: The direction of Textpattern 5
ruud wrote:
Combine “forms” and “pages” into “templates”. There’s really no reason to separate the two (or differentiate between various types of forms) and calling it a “template” is less confusing.
hcgtv wrote:
Personally, I like the distinction of Page and Form.
Lot of things could change in TXP5 paradigm, making current concepts/workflow to become obsolete.
I like ruud’s suggestion on “merging” both Pages and Forms under the same tab (personally, I don’t use those tabs any more, cnk_versioning has been my ally since long ago), although I would keep some kind of categorization.
Currently, in TXP4, categorizing a chunk of code as “page” serves, at least, one purpose: to be able to select that chunk of code as the rendering template for a particular section. In other words: a section must be assigned-to/matched-with a page template (that’s the built-in way, which currently can be bypassed with a plugin like gbp_permanent_links).
Combining “forms” and “pages” without keeping some categorization could break this section-to-page-template paradigm, and users could make the mistake of trying to do section-to-any-chunk-of-txp-code, which, in current TXP4 paradigm won’t work (unless the “form” contains the full code for a template).
hcgtv wrote:
I would eliminate Form Types though, they serve no purpose other than to confuse at first.
It confuses because newcomers believe that categorizing a form would make it work differently depending of the selected type. If it could be stated in a little tooltip that the type of a form doesn’t interfere with its functionality, that would be enough to avoid the confusion.
That being said, I like categorization of forms, and I’d suggest to keep it, and even letting the user (or a plugin) to create their own categories.
Bert, I saw your post on how to add form types.
I posted some ideas about new form types in the past.
I think new form types could play nice with plugins that would let end-user freely edit them, without having access to forms & templates.
For example, a “microcopy” form type, for managing short text & copy (widget headings, footer text, meta data, etc) that wouldn’t fit the “article” model. A current way to manage “microcopy” in TXP4 is possible using adi_variables.
Other topic:
Devs already mentioned that, in TXP5, there may be more flexible/custom URL schemes.
Not sure what they have in mind regarding this, but I would suggest them to look at:
- gbp_permanent_links, the current “standard” for custom URL schemes in TXP.
- Django’s MTV (Model-Template-View, Django’s own interpretation of MVC), and its urls.py way of matching an URL to a “view”.
gbp_p_l provides an UI to create custom URL schemes, and saves them in database. This makes it a bit cumbersome when having to move from development environment to production environment. If there could be a plain-text file with a super-cool syntax to define URL schemes… that would be awesome.
That’s all. By now :)
Offline
Re: The direction of Textpattern 5
gomedia wrote:
Drag & drop? Multiple admin panes – Articles on one side, Forms on the other?
That could work. Actually, the navigation tabs could respond to dragging, so that items could be freely dragged from one pane to other, like you could do in Finder (or Explorer on Windows).
DnD images, links, code blocks. Would be pretty awesome. Oh, and if plugins could freely extend what the even does, and spits out. Could actually make the forms/pages web interface usable, w/o the need of an external editor. But thing is, how many are used to DnD interfaces, and how many would even use it. I know I would, but what about the rest.
Just like Julián, I neither use the form/pages interface at all. Because it handles code, the design should be similiar to an editor. Not a tiny little field at the middle of the page. And the tag builder… the idea behind it is good, but the execution is bad.
Offline