WTF do we need form types for?

mrdale · 2015-07-30 16:27:55

Bloke wrote #293833:

do we need Forms at all :-p

Yes. How else would you acheive modular code? I sometimes use the same form in 20 places on a site, and only have to edit it once.

Call them snippets, baby elephants or trouser snakes, I don’t care, they’ve got to be one of the most useful components of textpattern.

I would further like to be able to edit form types as a mere grouping mechanism… as it is I tend to namespace my forms.

michaelkpate · 2015-07-30 16:38:18

If I were the God of Textpattern I would decree…

1) Forms would be called “Snippets” – I have hated the term Forms since 2004 because I think it is confusing for anyone trying to get started. I used to prefer Modules (Movable Type called them Template Modules) but Snippets is snazzier.

2) Users would be able to create their types of Snippets – not so much because they matter, but just so you could customize the order they get listed

philwareham · 2015-07-30 17:33:43

I agree with Dale, we need reusable code snippets outside of page templates – one long page template of code would not be desirable to me. Not bothered about specifying actual types though.

But for the love of god someone please change ‘forms’ to ‘snippets’ – it’s ridiculous calling this stuff forms.

zero · 2015-07-30 17:46:36

Definitely need reusable snippets of some kind, imho, but how best to fit them into the system? I am maybe mistaken but wasn’t Ruud referring to forms being just like page templates so why have both types? And then there’s his ‘inheritance’ plugin which I think fits in with the pages-only idea. My woolly thinking again?

And themes vs templates, isn’t there a non-English word that exactly fits the bill? It would take next to no time to get used to the word, and a link could easily point people to the definition.

Last edited by zero (2015-07-30 17:47:35)

candyman · 2015-07-30 19:05:23

michaelkpate wrote #293843:

Forms would be called “Snippets” […] I used to prefer Modules (Movable Type called them Template Modules) but Snippets is snazzier.

I’d like the change from Forms to Modules: in the Italian translation they are Moduli yet. Snippets (Ritagli) wouldn’t work so well.

zero wrote #293848:

And themes vs templates, isn’t there a non-English word that exactly fits the bill? It would take next to no time to get used to the word, and a link could easily point people to the definition.

… why not using Pattern instead?

Last edited by candyman (2015-07-30 19:23:23)

towndock · 2015-07-30 19:19:30

mrdale wrote #293842:

Call them snippets, baby elephants or trouser snakes, I don’t care, they’ve got to be one of the most useful components of textpattern.

Bingo. Totally agree. I think of forms as “subroutines” – to use an ancient coding term. I use them often. “Forms” is a deceptive term for new users. A rename would be fine.

candyman · 2015-07-30 19:23:07

towndock wrote #293852:

A rename would be fine.

I thought better. Personally I wouldn’t change nothing of the historical foundations of Textpattern. Not even the Forms. Just think to all the informations out there (tips, tutorials, forum posts and even the Textpattern Resources book that references themselves to the original word “Forms”). This could create more confusion for the newcomer than the term itself.

Last edited by candyman (2015-07-30 19:26:57)

colak · 2015-07-30 19:25:17

candyman wrote #293853:

I thought better. Personally I wouldn’t change nothing of the hystorical things of Textpattern. Even Forms. Just think to all the information out there (tips, tutorials, forum posts and even the Textpattern Resources book references to the old word Forms). This could create more confusion that the terms itself.

Good point.

towndock · 2015-07-30 20:12:10

candyman wrote #293853:

I thought better. Personally I wouldn’t change nothing of the historical foundations of Textpattern. Not even the Forms. Just think to all the informations out there (tips, tutorials, forum posts and even the Textpattern Resources book that references themselves to the original word “Forms”). This could create more confusion for the newcomer than the term itself.

That is a fair point, and one to sleep on for a few nights. The book is out of date enough I wouldn’t care, online tips and tutorials would change easily, but the forum posts are a valid concern. However, for Textpattern to move forward some historical foundations may need to change.

Last edited by towndock (2015-07-30 20:12:57)

maverick · 2015-07-30 20:14:42

Changing the names of “forms” is another one of our reoccuring discussions that has not yet yield action. I don’t recall reason given why keeping forms was the desired outcome.

candyman wrote #293853:

I thought better. Personally I wouldn’t change nothing of the historical foundations of Textpattern. Not even the Forms. Just think to all the informations out there (tips, tutorials, forum posts and even the Textpattern Resources book that references themselves to the original word “Forms”). This could create more confusion for the newcomer than the term itself.

Good thought, and that quite compelling. Even so, I would support a renaming of forms. Like anything, you can’t make progress if you are needlessly constrained by the past. The name is not an essential that needs preservation even if the functionality is. . . as a project deprecations happen, support docs are updated, community tutorials are outdated if they have disappeared into the digital nether world. smd_where_used can help clean up a lot of those perhaps :D

I’m not irritated by “forms”, but I do think it fails the tests of 1) common usage and 2) intuitive usage.

If I recall, various alternatives and citations of similar features in other projects have included: snippets, blocks, chucks, bits, pieces, utilities, partials, includes, and more.

My preference is “includes” or “page includes”: For me it is the most intuitive word given it most closely describes the functionality of forms, and echoes the long used php includes. Blocks, bits, pieces, and snippets all describe sort of what it is, at least for some people, but none of those words describe their use. Obviously that’s just my take, though.

In the interest of focus, and not overwhelming/distracting our development team, I would also moving this discussion to our post 4.6 agenda. (I sometimes think we don’t need a development roadmap as much as we need a community agenda to focus and time flow our discussions and requests :D )

jakob · 2015-07-30 21:10:26

I use forms as txp’s version of php includes.

Me too.

What would alternate approaches?

The form overrides that Yiannis mentioned are also useful. I don’t use it often, but it’s good for anything where you need user-choosable post types in a single section, i.e. where the content or layout varies more significantly. Think: blog with different post types, sometimes long-form, sometimes just a link, sometimes a video, sometimes a carousel slideshow…

Bloke wrote #293832:

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

Hmm. Doesn’t that kind of granularity in themes kind of overlap with page templates?

Would making themes and page templates assignable on a per-section basis mean that as a themes designer you need to break down your styles for per-section use accordingly? If not, there’d need to be some corresponding way of loading a theme-specific css in the page head of that section. And also a way of making some parts of a site stay the same, e.g. you won’t want your menu jumping around between sections, because the css that governs how it looks changes with each section. And if you do that, you’re starting to interleave the theme styles too, so as a designer, you’d need to be careful to prevent different theme styles affecting one another, probably through careful modular css specificity and namespacing (while avoiding preventing theme swappability). If the designer doesn’t think about that, it quickly starts to break parts of the site.

When I think of layout variants, I think of page templates (forms too, but more modular). When I think of themes, I think of packages of pages, forms and styles that are in some way or other coordinated, either for a use case (photography site, portfolio, blog, business site, directory site…) or design-wise, in which case they are potentially swappable as a whole if the page structure and class names match.
So a theme could contain multiple page templates, both for different sections of the site – text page, blog, testimonials, portfolio – as well as different layout variants within a section, e.g. portfolio_grid, portfolio_list and portfolio_slideshow… only one of which might actually be assigned.

What’s the use case of one site having multiple themes? Sounds a bit like a misnomer. Maybe then (like on the admin side), the idea of extending a theme with functionality borrowed from another…

uli · 2015-07-30 21:14:59

philwareham wrote #293846:

I agree with Dale, we need reusable code snippets outside of page templates – one long page template of code would not be desirable to me.

If forms were removed in favour of pages, I don’t think that Ruud ever wanted to take them away completely and let us have repeating code blocks on a huge page. There would be a replacement. But: One can’t explain to a newbie using a tag like <txp:output_page /> on a page.

So there’d be a new tag necessary, anyway, (and with it surely a new name) that lets us call “pages” into “pages”, or, easier to imagine, “snippets” into “snippets”, whatever you name it, <txp:snippet /> or, yeah, <txp:trouser_snake />.
(Hope I’m right, but I’d not fear Ruud changing the way TXP works.)

What I’m afraid of, though, is, such a new, unified, admin page will be even more overloaded with UI elements: Add your list of page names to that of your forms, let alone a merged tag builder.

Textpattern CMS

Textpattern CMS support forum

#13 2015-07-30 16:27:55

Re: WTF do we need form types for?

Bloke wrote #293833:

#14 2015-07-30 16:38:18

Re: WTF do we need form types for?

#15 2015-07-30 17:33:43

Re: WTF do we need form types for?

#16 2015-07-30 17:46:36

Re: WTF do we need form types for?

#17 2015-07-30 19:05:23

Re: WTF do we need form types for?

michaelkpate wrote #293843:

zero wrote #293848:

#18 2015-07-30 19:19:30

Re: WTF do we need form types for?

mrdale wrote #293842:

#19 2015-07-30 19:23:07

Re: WTF do we need form types for?

towndock wrote #293852:

#20 2015-07-30 19:25:17

Re: WTF do we need form types for?

candyman wrote #293853:

#21 2015-07-30 20:12:10

Re: WTF do we need form types for?

candyman wrote #293853:

#22 2015-07-30 20:14:42

Re: WTF do we need form types for?

candyman wrote #293853:

#23 2015-07-30 21:10:26

Re: WTF do we need form types for?

Bloke wrote #293832:

#24 2015-07-30 21:14:59

Re: WTF do we need form types for?

philwareham wrote #293846:

Board footer