The direction of Textpattern 5

artagesw · 2011-08-11 05:40:26

aswihart wrote:

Give the lack of documentation, I can’t say for sure, but is the et:pages:each tag the equivalent of txp:article?

Not quite. Escher’s context model is a bit different from Textpattern’s. Escher tags essentially either (a) set the current context to a specific object, or (b) operate on that object. By default, the current context is always the page object for the page identified by the current URL (in the address bar). The <et:content> tag, for example, pulls page parts out of the current page. By default, it will pull the “body” part, but you can pull any page part by naming it (eg. <et:content part=“sidebar” />).

<et:pages:each> will loop over arbitrary pages (specified via search attributes), and and set the context to each in turn. Then, you can use other tags (such as <et:content>) to pull content from those pages.

All Escher tags use this model, and consistent naming conventions make it easy to learn the tag system. (Want to pull the title form a page? Call <et:title> in a page context. Want to pull the title of a category? Use <et:title> in a category context. Etc.)

aswihart wrote:

And just curious, how are Escher’s “Pages” stored in the database, separate tables or all in one dumping ground a la Txp’s Article? Obviously, depending on how you use Pages, it would be better to have separate tables for different models. I realize the database implications of this are daunting, but is it possible?

Pages are stored in a single pages table. Parts are stored in a separate parts table.

tye · 2011-08-11 05:52:26

Take a look at umbraco for ideas on client/end users integration for txp5 or Escher.

I’ve had to use this CMS (runs on asp .NET ) for a couple of clients, and believe me – the admin area is amazingly intuitive, – you can create custom content types for each section, associate multiple templates to each custom content type (you choose on creation), then the whole UI is pretty much editable to suit your needs.

Clients just seem to understand get how it works – I think because it is laid out the exact same way their site is, and obviously each custom content type is crafted to their sites needs.

I think the layout could be improved – but its all there. Llike I mentioned before, I’m not sure if the same system is doable in php/mysql (I’m sure it is) – but if anyone wants to take look in a staging site I have online, just pm or email me – they don’t have a test site.

maruchan · 2011-08-11 07:40:00

TXP 6.0b1

<txp:canvas width="600" height="400" form="game_setup">
  <txp:smd_game_loop>
    <txp:smd_update_position object="player1"/>
    <txp:smd_update_position object="player2"/>
    <txp:smd_update_position object="enemy"/>
    <txp:smd_play_sound object="engine_noise"/>
  </txp:smd_game_loop>
</txp:canvas>

Oooh, fun one that would be…

You have a total of 2,344 plugins installed. Your last Textpattern upgrade was 1.2 years ago. You should update now.

runs around screaming

Last edited by maruchan (2011-08-11 07:53:03)

merz1 · 2011-08-11 13:54:10

IMHO what aswihart said above is really worth a deeper thought. Maybe not exactly a feature for TXP 5 but maybe for future versions.

… imagine if the currently predefined models (article, image, link, comment, file) were converted to default model templates. You would select a template or start from scratch and customize your content type (let’s call it a model).

Abstract: I am wondering if this is not reinventing the wheel because the whole issue is what XML was invented for. Not sure what ‘XML for TXP’ could mean for the future of TXP :)
Basics: Is the creation of more content types a plug-in issue?
Type: Aren’t we talking about a meta level structure for sets of n custom fields +/and/or presets of TXP:tags? (like well formed XML with all consequences)
Name: custom content type?
Name: content role model?
Name: custom field set?

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 :).

Last edited by merz1 (2011-08-11 14:00:55)

aswihart · 2011-08-11 14:08:01

artagesw wrote:

Pages are stored in a single pages table. Parts are stored in a separate parts table.

You know, on second thought, this really works great for most cases. Textpattern / most websites in general tend to be “relatively” small. They can be beautiful and have highly customized layouts and url schemas, but they are usually not monstrous sites with tens of thousands of database rows. A single table for multiple different content types may not make sense intuitively, but it’s obviously worked out and may be even faster for small sites. I honestly don’t know enough about SQL to speak intelligently about it though, so I’ll shut up now.

aswihart · 2011-08-11 14:31:58

merz1 wrote:

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 :).

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

aswihart · 2011-08-11 14:58:50

ruud wrote: (from page 2)

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. I would eliminate Form Types though, they serve no purpose other than to confuse at first.

I agree with ruud that consolidating Pages and Forms is for the best, renaming them as templates. Take a look at the Django templating language, which spawned many copy-cats: jinja (python), liquid templates (ruby), jangod (java), twig (php), dotiac (perl) and others.

Of course, we’ll keep using txp: tags for template logic, but the {% extends “base.html” } and { include “snippet.html” %} concepts make a lot of sense. Replace that markup with <txp:extends template=“base” /> and <txp:include template=“snippet” /> perhaps?

Last edited by aswihart (2011-08-12 00:01:48)

merz1 · 2011-08-11 15:09:16

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).

philwareham · 2011-08-11 15:17:36

I’d still prefer to keep ‘pages’ and ‘forms’ separate myself, even if they were consolidated into a single admin page – though I think ‘forms’ is way to confusing to new users who expect that to be HTML forms – this needs to be relabelled as ‘Clips’ or ‘Snippets’ or something.

aswihart · 2011-08-11 15:20:51

merz1 wrote:

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).

But are you saying you don’t think txp:song tags are possible, for example, and that we’ll need to use something like txp:article model=“song” instead? I’m just not sure if this is what you are referring to.

I don’t understand why you couldn’t separate the way template tags are written from how things are stored on the database side. I.E. even if you had to keep storing custom content types in a big txp.article table (probably not ideal, but practical), the txp:song tag would still perform lookups on that table e.g. FROM txp.article SELECT * WHERE model=“song” (sorry I don’t know SQL).

Last edited by aswihart (2011-08-12 00:38:19)

aswihart · 2011-08-11 15:28:17

philwareham wrote:

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

For what reason?

philwareham · 2011-08-11 15:38:53

For what reason?

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.

Textpattern CMS

Textpattern CMS support forum

#157 2011-08-11 05:40:26

Re: The direction of Textpattern 5

#158 2011-08-11 05:52:26

Re: The direction of Textpattern 5

#159 2011-08-11 07:40:00

Re: The direction of Textpattern 5

#160 2011-08-11 13:54:10

Re: The direction of Textpattern 5

#161 2011-08-11 14:08:01

Re: The direction of Textpattern 5

#162 2011-08-11 14:31:58

Re: The direction of Textpattern 5

#163 2011-08-11 14:58:50

Re: The direction of Textpattern 5

#164 2011-08-11 15:09:16

Re: The direction of Textpattern 5

#165 2011-08-11 15:17:36

Re: The direction of Textpattern 5

#166 2011-08-11 15:20:51

Re: The direction of Textpattern 5

#167 2011-08-11 15:28:17

Re: The direction of Textpattern 5

#168 2011-08-11 15:38:53

Re: The direction of Textpattern 5

Board footer