WTF do we need form types for?

hcgtv · 2015-07-30 11:26:42

“New beginnings are often disguised as painful endings.” ~ Lao Tzu

Textpattern forms

Last week, Stef and I carried on an email thread related to Themes, no conclusion was arrived at.

While testing Stef’s new Themes branch on GitHub, I came to the conclusion that it just ads another layer of complexity that we don’t really need. The way Stef’s branch works is that you pick a Theme and then the Pages, Forms & _Styles are populated from said Theme. But what if I want to copy/paste some code from another theme? – Open up another browser tab to the other theme? .or. Pick the theme to copy from, copy the code, then go back to the one I was working on? Quite a lot of steps to copy/paste code between layouts.

What is a Theme?

1 or 2 Pages
Assorted Forms – head, footer, etc.
1 Style

My thinking is that a Theme is 1 page, with an associated Style of the same name. From the example above you can see that I’m working on the 2-col-portfolio Theme. So I have a 2-col-portfolio Page and a 2-col-portfolio Style, but in the Forms tab, I have to preface each form with the Theme name.

Why not use Form type to denote Theme?

Back to the screenshot, I changed the gTxt language record for Articles to Default and Section to 2-col-portfolio just to make this point.

Let’s install this new Themes related branch, for those that want to take the plunge:

All forms are placed under a Default Theme(Form type), this Theme cannot be deleted nor the list of protected forms that reside under this Theme.
This new Default Theme is just the bare essentials, not Phil’s new Theme, that can be installed afterwards.

Let’s upgrade to this new Themes related branch

All your current forms are grouped under the Default Theme – some forms have protection status, you can change them but they can’t be deleted, like the default article form.
Don’t like everything under Default, then clone the Default Theme into My Theme and go from there – but you’ll have to adjust your Pages and Forms to use My Theme, wherever a form is called, or else leave them all under Default and your site keeps serving pages without a hiccup.

How do we accomplish this?

Any Textpattern tag that uses a form would have to take into account the Theme, if no Theme attribute is given, the default Theme is Default.

<txp:article form="default, 2-col-portfolio" />

or

<txp:article form="default" theme="2-col-portfolio" />

Where’s the payoff?

Now’s the time for all you web developers, who live in your text editors and copy/paste your immaculately indented code into the Textpattern Presentation tabs for rendering purposes, to leave the room, this doesn’t concern you.

The payoff is that we, the Textpattern end users, can freely share Themes and we can install them in our Textpattern sites and use them or learn from them.

New beginnings

This post is not a can we do this? Let’s discuss, ad nauseum. No. This post is my intention, my direction.

Please visit txp:tag, that’s my new home, that’s where I’m hanging out at.

bert@jessie:~$ shutdown -h now

colak · 2015-07-30 11:50:24

I guess – we need form types so as to give some control on what appears in the ‘write’ page. Only article form types appear there. Having said that, it might be a good idea to extend them so as to include templates/themes (call them what you want) is a good idea!

zero · 2015-07-30 12:47:40

Do your themes need Bootstrap or is that optional? In other words what has Bootstrap got to do with it?

jakob · 2015-07-30 13:57:55

Not sure if I’ve properly understood the ins and outs of every last detail. Is your concern that it’s hard to port code across from one theme to the other because you can’t see them both on the page? If so, I think the idea of having collapsable trees of forms for themes sounds like a good one.

Whether these need to be additionally subdivided into articles / misc / links / comments is a second aspect. I rather suspect that if that layer of subdivision is not there that people will end up naming their forms (as you have with your “2-col-portfolio”) to group them for better findability, so there’s an organisational argument for that, even if there is no difference to them functionally (plus your form attributes can be shorter).

What I don’t get is the tag. Won’t the introduction of the theme attribute break the idea of theme switching by anchoring the output to a specific theme. As a user you’d switch to another theme, but the tag in the code, requests the form from the old theme because by adding the theme attribute, you’ve effectively hard-coded it to a specific theme.

If you can do that, you could end up with sites that use different themes for different sections, and while that may be an interesting idea in itself, it kind of undermines the idea of what a theme is (as distinct from page layouts or presentation of a page module). FWIW: I see portfolio as a content layout type and 2-col as a presentational means and a theme as a collection of co-ordinated layouts and modules.

To come back to the problem: what about having an attribute for designating a fallback theme(-form combo) for an output form, so that if a corresponding form does not exist in another theme, or in the default theme, a fallback exists. In essence, that would also give you the option in reverse of building themes on other themes in an “extend” pattern. The programmers among us will have a better idea of how that could work. Just a half-formed idea not thought through.

Notation-wise, the comma-list notation is used differently elsewhere in txp, so I think that’s less good. An extra tag would be better, or else a theme:form or theme->form notation.

[ Perhaps add a label to your screenshot, that it’s your proposal/vision. Currently it’s slightly misleading: my first thought on seeing the picture and before reading your post, is that is how themes branch looks. It’s not, it’s how you think it should look. ]

Bloke · 2015-07-30 14:27:21

hcgtv wrote #293825:

what if I want to copy/paste some code from another theme?

I haven’t finished yet. Options are:

For Pages/Styles, prefix them like jakob suggests using a colon, dot or something prior to hitting Duplicate. That’ll then copy the item to the named Theme and if it doesn’t exists, will create it.
For Forms: same as above, with the additional option of multi-edit to clone the selected Forms.

I have a 2-col-portfolio Page and a 2-col-portfolio Style, but in the Forms tab, I have to preface each form with the Theme name.

Why? Each Theme is entirely separate. There’s a dropdown selector on the Pages, Forms and Styles panels, which is remembered from panel to panel. If you change to theme 2-col-portfolio then you only get to see those assets.

Further, if you only have Article and Misc forms defined for 2-col-portfolio those are the only groups you’d see. Well, when I figure out what to do with the essential forms, as we discussed.

Bloke · 2015-07-30 14:31:02

jakob wrote #293830:

If you can do that, you could end up with sites that use different themes for different sections

That’s actually the plan. You can install as many themes as you like but remain in control of which are assigned to Sections. So your blog could look different to the rest of the site.

Bloke · 2015-07-30 14:32:21

colak wrote #293827:

I guess – we need form types so as to give some control on what appears in the ‘write’ page

Not any more. That’s gone. There’s now no distinction whatsoever between types.

The bigger question is one that Ruud has been postulating for years: do we need Forms at all :-p

colak · 2015-07-30 14:51:32

Bloke wrote #293833:

Not any more. That’s gone. There’s now no distinction whatsoever between types.

The bigger question is one that Ruud has been postulating for years: do we need Forms at all :-p

In my sites I don’t use the override form functions but I understand that there are people who might. If there are no form types this means that all form names will appear in the write tab which might be confusing to some.

I do use forms for code snippets which run across sections so I guess for me forms is a time saver. i guess that the problems at this stage are the inherent semantics of the words Dean used in txp versus what non-txp users actually understand when they hear those terms. The one problem we are trying to fix is the sections v templates problem. The second which is discussed in other threads is that of modular content which is partly addressed with forms.

Regarding the templates v themes, the more I think about it I would go for templates as themes are more rightly linked with subject in the off line world. I know that blogging platforms use the term but maybe this is one of the reasons we should not.

Bloke · 2015-07-30 15:03:01

colak wrote #293834:

If there are no form types this means that all form names will appear in the write tab which might be confusing to some.

A very valid point.

zero · 2015-07-30 15:05:27

I just found a new word: motif. It’s new to me anyway, short, sweet, but not really on-topic for this thread.

colak · 2015-07-30 15:40:31

zero wrote #293836:

I just found a new word: motif. It’s new to me anyway, short, sweet, but not really on-topic for this thread.

I think that it comes from the French and it is used a lot in architecture but (for some of us architects at least), it sometimes have negative connotations as it can refer to the decorative elements of the design many of us loath.

maverick · 2015-07-30 15:56:30

Do we need forms?

Thinking
I don’t do it often, but aren’t there use cases where forms are used to process one set of tags, etc. before processing them in the page? What would be alternate approaches?

I use forms as txp’s version of php includes. What would alternate approaches?

Textpattern CMS

Textpattern CMS support forum

#1 2015-07-30 11:26:42