The direction of Textpattern 5

ruud · 2011-01-21 08:08:29

Wishlist:

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.
Turn the section page into a table similar to the article list (or the list of categories if you plan on doing subsections) where you would click the section name and then be able to edit all the options, instead of showing it for all sections on a single page.
Make plugin tags 1th class citizens by allowing: <abc:plugin_tag /> instead of having to write <txp:abc_plugin_tag /> (only for plugins that adhere to the 3-char prefix policy!) and at the same time add a “txp_” prefix to all built in TXP handlers.

Licensing
S/P has a GPL3 (or later) license. TXP has a GPL2 (without the “or later” part) license. GPL2 and GPL3 are not compatible as far as I know. I have no objections to relicensing whatever I contributed to a GPL3 (or later) license. This affects plugins as well.

Bloke wrote:

… but S/P itself will by its nature have a different set of overheads than the current code base. Some places it’ll do things faster, other places it might do things slower. But the key thing that S/P offers is built-in cacheing (when we get to that bit) and the results are impressive.

That’s comparing S/P to S/P+caching. More interesting is comparing S/P to TXP 4 ;)

… we can take advantage of PHP 5’s on-demand class loader which means that only the plugins that are required to do the job of displaying the current page are loaded. […] Compare that to TXP where every plugin (of a particular type: 0=public side, 1=public+admin, 3=admin) loads on every page request and you can see that it often adversely affects the rendering time of the page as you add plugins.

People that really care about performance probably use an opcode cache like APC or Xcache. If plugins weren’t “eval-ed” but simply “included” you’d see probably see an even bigger performance increase.

artagesw · 2011-01-21 09:11:43

ruud wrote:

Wishlist:

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.

This is the approach Escher takes.

ruud wrote:

Make plugin tags 1th class citizens by allowing: <abc:plugin_tag /> instead of having to write <txp:abc_plugin_tag /> (only for plugins that adhere to the 3-char prefix policy!) and at the same time add a “txp_” prefix to all built in TXP handlers.

See Escher namespaces. An “abc” namespaced plugin tag would be evoked as <txp:abc:plugin_tag />, for example.

ruud wrote:

S/P has a GPL3 (or later) license. TXP has a GPL2 (without the “or later” part) license. GPL2 and GPL3 are not compatible as far as I know. I have no objections to relicensing whatever I contributed to a GPL3 (or later) license. This affects plugins as well.

I was under the impression that GPL3 and GPL2 are compatible. Could be wrong though.

ruud wrote:

People that really care about performance probably use an opcode cache like APC or Xcache. If plugins weren’t “eval-ed” but simply “included” you’d see probably see an even bigger performance increase.

I am one of the those people, which is why Spark/Plug’s code cache ensures that all plugin code can be “included” instead of “evaled.”

hcgtv · 2011-01-21 15:48:13

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.

Personally, I like the distinction of Page and Form. I would eliminate Form Types though, they serve no purpose other than to confuse at first.

I’m all for moving forward so the dev team can add all those things users have been clamoring for, but doing wholesale changes to the way of Textpattern would alienate a vast majority of loyal users.

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?

joebaich · 2011-01-21 16:50:36

Will TXP5 generate HTML5?

johnstephens · 2011-01-21 16:58:22

joebaich wrote:

Will TXP5 generate HTML5?

The only barrier to using HTML5 with TXP 4.X is the acronym element generated by Textile. Textpattern gives me such fine-grain control over markup that I use HTML5 anyway— peppering the articles with abbr instead of depending on Textile’s ABC(Always Be Closing) pattern is a small price to pay.

Edit: Use an apostrophe to indicate possessive. Oops! [HT to Strunk & White]

Last edited by johnstephens (2011-01-21 16:59:45)

Bloke · 2011-01-21 17:00:29

hcgtv wrote:

I would eliminate Form Types though, they serve no purpose

I disagree up to a point. Without types, you are doomed to one loooong list of Forms. Scroll city. There’d be no mechanism for tucking away groups that you’re not working on, and the only way you could move them about would be by renaming them, which is a pain unless you’re super anal about a naming convention.

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.

jsoo · 2011-01-21 17:03:38

hcgtv wrote:

Personally, I like the distinction of Page and Form. I would eliminate Form Types though, they serve no purpose other than to confuse at first.

I’d like to go the other direction and add more power to form types.

johnstephens · 2011-01-21 17:04:07

Custom form types would be awesome. Right now, I use the aforementioned anal naming convention to handle this.

net-carver · 2011-01-21 17:08:31

John

re: Textile’s acronym tag — there are changes afoot (it won’t take place immediately though) to allow a certain amount of customisation in textile. The first step — allowing an extendible block markup scheme is already a feature candidate.

abbr support is now on the repo issue tracker as issue 15. Please add to the issue if you have specific examples of how you want abbr markup to work and the output it should produce.

joebaich · 2011-01-21 17:10:20

johnstephens wrote:

joebaich wrote:

Will TXP5 generate HTML5?

The only barrier to using HTML5 with TXP 4.X is the acronym element generated by Textile. Textpattern gives me such fine-grain control over markup that I use HTML5 anyway— peppering the articles with abbr instead of depending on Textile’s ABC(Always Be Closing) pattern is a small price to pay.

Edit: Use an apostrophe to indicate possessive. Oops! [HT to Strunk & White]

Thanks John, I was thinking more along the lines of having the self closing / not present in the generated html tags (or an option to do that). Phil Wareham outlined the requirement quite well recently.

ruud · 2011-01-21 17:13:30

artagesw wrote:

This is the approach Escher takes.

Is that a recommendation to switch to using Escher or is this something that is planned for TXP5 as well? :)

See Escher namespaces. An “abc” namespaced plugin tag would be evoked as <txp:abc:plugin_tag />, for example.

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>

And what rules are set to avoid namespace collisions between TXP core and plugins? TXP4 has registered 3-char prefixes for plugin authors.

I was under the impression that GPL3 and GPL2 are compatible. Could be wrong though.

Is GPLv3 compatible with GPLv2?

No. Some of the requirements in GPLv3, such as the requirement to provide Installation Information, do not exist in GPLv2. As a result, the licenses are not compatible: if you tried to combine code released under both these licenses, you would violate section 6 of GPLv2.

However, if code is released under GPL “version 2 or later,” that is compatible with GPLv3 because GPLv3 is one of the options it permits.

Personally, I’d go for GPL3 or later if possible.

I am one of the those people, which is why Spark/Plug’s code cache ensures that all plugin code can be “included” instead of “evaled.”

Nice!

ruud · 2011-01-21 17:25:31

joebaich wrote:

Thanks John, I was thinking more along the lines of having the self closing / not present in the generated html tags (or an option to do that). Phil Wareham outlined the requirement quite well recently.

As I understand, using the / for self-closing tags is allowed in HTML5:

W3C HTML5 spec, 8.1.2.1 Start tags

Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/). This character has no effect on void elements, but on foreign elements it marks the start tag as self-closing.

Textpattern CMS

Textpattern CMS support forum

#13 2011-01-21 08:08:29

Re: The direction of Textpattern 5

#14 2011-01-21 09:11:43

Re: The direction of Textpattern 5

#15 2011-01-21 15:48:13

Re: The direction of Textpattern 5

#16 2011-01-21 16:50:36

Re: The direction of Textpattern 5

#17 2011-01-21 16:58:22

Re: The direction of Textpattern 5

#18 2011-01-21 17:00:29

Re: The direction of Textpattern 5

#19 2011-01-21 17:03:38

Re: The direction of Textpattern 5

#20 2011-01-21 17:04:07

Re: The direction of Textpattern 5

#21 2011-01-21 17:08:31

Re: The direction of Textpattern 5

#22 2011-01-21 17:10:20

Re: The direction of Textpattern 5

#23 2011-01-21 17:13:30

Re: The direction of Textpattern 5

#24 2011-01-21 17:25:31

Re: The direction of Textpattern 5

Board footer