The direction of Textpattern 5

aswihart · 2011-08-11 16:11:50

philwareham said

To keep things in a logical order and grouping and stop my head exploding. I get that pages and forms are essentially one and the same, but the concept seems to work fine as it currently is.

We are not all uber developers, most of us users are designers looking for a tool that is pretty flexible but not too difficult to comprehend and learn. If I needed user-customisable XML tags, ruby, compass, SASS etc to install and run a Textpattern site I’d probably be using a more enterprise-level CMS.

I hear you, Txp is made for a particular audience and it shouldn’t alienate them by making things more difficult. My point is I think it simplifies things further. Just replace <txp:form /> with <txp:include /> and lessen the distinction between pages and forms.

I think we are in agreement that there should be some simple way of organizing templates you are using as “pages” and “forms”, and maybe we also agree that they are a bit too rigidly separated currently.

<txp:extends /> (which would introduce the concept of “blocks”, copying Django’s) would be completely optional — not using it (or implementing it in Txp to begin with) would be exactly the way Pages + Forms currently work: includes only. Admittedly, block inheritance would not be trivial to implement, and may be a bridge too far.

BTW, I think you might be referencing my post in the Txp 5 admin ideas thread where I mentioned those Ruby tools. Those are just tools for building CSS rules, nothing more. No one would need to install anything. I really just wanted to raise awareness of them, like I said I wish I’d found them sooner, maybe everyone already knows.

Last edited by aswihart (2011-08-12 00:45:53)

tye · 2011-08-11 23:13:40

merz1 wrote:

bq. Can you explain this a limitation a little more? I’m not sure I understand what you’re saying.

Basically a relational database relies on defined grid(s) of linked data.
XML is based on data objects which can be extended by sub objects.
You need to dive into the depth of ‘What is XML good for (, DTD, XSS, etc.)’ and compare that with the model of a relational database and how to access the data silo (SQL).

That seems to rule out what I’m talking about then :(

aswihart · 2011-08-12 00:22:45

merz1 said

Note: There is a principal database problem with the integration of XML data sets/models. The underlying SQL database for Textpattern is not capable of offering a performant coverage of extensive XML data sets. The XML approach will always be restricted to a predefined data set (or the SQL database will explode :).

Merz – - What I think you’re saying is that the dynamic creation of custom tags will lead to too many tables for the database to handle? I don’t understand how the changes would be so dramatic. What is the weakest link? I understand you would create additional tables in the database other than for articles, links, files, images, etc.., but not sure why that would make the database explode.

Another thing mentioned early in this thread is the ability to make tags that start with the plugin author’s initials, e.g. <smd:slimbox />. Pretty cool idea I think, any reason not to do it?

renobird · 2011-08-12 02:03:00

artagesw wrote:

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.

Bingo!

:)

Last edited by renobird (2011-08-12 02:03:58)

artagesw · 2011-08-12 02:26:40

aswihart wrote:

Another thing mentioned early in this thread is the ability to make tags that start with the plugin author’s initials, e.g. <smd:slimbox />. Pretty cool idea I think, any reason not to do it?

Another feature of Escher (tag namespaces) allows this.

renobird · 2011-08-12 02:49:17

Hey Sam,

Can these features (Page Parts, Tag namespaces) be easily ported over to TXP5?
I’ve been making that assumption because of TXP using Spark/Plug, but figured I should ask outright to clarify. :)

artagesw · 2011-08-12 03:45:46

renobird wrote:

Can these features (Page Parts, Tag namespaces) be easily ported over to TXP5?
I’ve been making that assumption because of TXP using Spark/Plug, but figured I should ask outright to clarify. :)

Likely, yes. Depending on what it means for backward-compatibility with database schema and existing plugins. But these features have nothing to do with Spark/Plug. They are pure Escher.

frickinmuck · 2011-08-12 23:40:23

philwareham wrote:

I’d still prefer to keep ‘pages’ and ‘forms’ separate myself

Maybe I’m just being a Luddite and a new all-in-one system would have advantages I can’t yet see, but based on my limited understanding of what’s being discussed here I have to agree – I like them separate.

The separation of pages (or templates, as some people think of them) and forms (or includes, as I think of them), for me, is one of the things I like best about Textpattern. The flexibility and level of control that system provides is fabulous. I hate the way other CMS basically force one to put “all eggs in one basket.” People THINK it’s simpler because everything is in one place, but it’s really much more complicated because it forces workarounds to deal with the inflexibility of such a system.

I can only speak to the process I like, and I have to say, being able to separate bits and pieces and swap them in and out of a template depending on various factors – I think that’s like, an essential element of what makes me love TXP.

Although, I admit I don’t know enough about the inner workings of TXP and the new stuff you are working on/discussing to know if my comment is even relevant to what’s being said here. :^)

EDIT: Also, I like the idea of managing them all through one page, and I agree that form types seem pointless. And I agree that a rename of those items, if they remain, is long overdue. “Forms” is confusing for a lot of people.

Last edited by frickinmuck (2011-08-12 23:42:52)

aswihart · 2011-08-13 00:41:36

I think we all basically agree on a couple things:

1) Txp places arbitrary limitations on both forms and pages to separate their functions, and it seems a little silly because they are otherwise essentially just generic ‘templates’.

2) Whether you call it a ‘form’ or an ‘include’ (more logical if you come from anywhere but Txp), it is nice to be able to manage your forms separate from your pages. The interface for doing so could be consolidated to one page, in a consistent editing environment.

But does this blow anyone’s mind: You could save a page as a form and vice versa.

maruchan · 2011-08-13 01:53:23

“Partial” is becoming a really common term for our form functionality, in the CMS world anyway. I like it better than module, snippet, chunk, include, and widget. :-)

I think it would be cool to have pages show up in the forms editor and vice-versa, but that’s more of a plugin thing to do.

philwareham · 2011-08-13 09:33:19

‘Partials’ or ‘Includes’ is much more logical labelling than the current ‘Forms’. I’d also be quite happy for the pages/includes to all be housed in a single editor page as long as you could differentiate between the two if you wanted to.

Last edited by philwareham (2011-08-13 09:34:06)

gaekwad · 2011-08-13 09:56:06

Forgive me for speaking out of turn, and please do ignore this if it’s already been covered, but I’ve skimmed 17+ pages of this thread and I couldn’t find an answer.

What are the current plans for a pre-release and production release for Textpattern 5?

I fully understand it’s at an early stage right now, so it’s a stinker of a question, but are we talking 1H2012, 2H2012, 2013 or beyond?

Thanks – and don’t hate me for asking :)

Edit: to clarify, I know about (and have a local copy of) the current Textpattern 5 repo.

Last edited by gaekwad (2011-08-13 09:58:57)

Textpattern CMS

Textpattern CMS support forum

#169 2011-08-11 16:11:50

Re: The direction of Textpattern 5

#170 2011-08-11 23:13:40

Re: The direction of Textpattern 5

#171 2011-08-12 00:22:45

Re: The direction of Textpattern 5

#172 2011-08-12 02:03:00

Re: The direction of Textpattern 5

#173 2011-08-12 02:26:40

Re: The direction of Textpattern 5

#174 2011-08-12 02:49:17

Re: The direction of Textpattern 5

#175 2011-08-12 03:45:46

Re: The direction of Textpattern 5

#176 2011-08-12 23:40:23

Re: The direction of Textpattern 5

#177 2011-08-13 00:41:36

Re: The direction of Textpattern 5

#178 2011-08-13 01:53:23

Re: The direction of Textpattern 5

#179 2011-08-13 09:33:19

Re: The direction of Textpattern 5

#180 2011-08-13 09:56:06

Re: The direction of Textpattern 5

Board footer