WTF do we need form types for?

ruud · 2015-07-30 21:37:52

uli wrote #293859:

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.

My point was that technically there isn’t much difference between pages and forms so there’s no need to have both of them. If it were up to me, I’d merge ‘pages’ and ‘forms’ into ‘templates’ which could be grouped into user-configurable template types (much like the form types, only not hard-coded as they are now). But it’s not up to me and it’s not easy to do if you want to be able to upgrade old TXP installs easily.

GugUser · 2015-07-30 23:00:09

I often use forms and it doesn’t matter to me if they are called forms, snippets or whatever. But I think there is a conceptual difference between pages and forms. For me in my work the page is the hole pagecode from <html> to </html> in which I include the forms.

But, I never use form types other than article, I think it doesn’t make a difference, it’s only an organizational thing.

wet · 2015-07-31 12:41:06

philwareham wrote #293846:

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

I think ‘partials’ is an established term for this concept. In other news, I’d rather paint this bikeshed #ffcc00 ;)

Edited to add:

If we do not drop the ‘Overwrite form’ feature completely, you need some device to tell article-related forms (presented to the end-user) apart from others, which exist solely to help the coder make sense of the template mess.

Last edited by wet (2015-07-31 12:44:31)

maverick · 2015-07-31 13:59:12

jakob wrote #293858:

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…

I was unclear. My question about alternates related directly to the question of removing forms. If we did not have forms, how would one do includes, how could one pre-process some tags, then use the results in later tags.

However, I’ve never used the form overrides. In part because I’ve never could think a situation what was useful to me. I appreciate your explanation – as soon as I read long form vs link vs video vs slideshow, the light bulb went on and I started to think more creatively about this feature.

Thanks!

Last edited by maverick (2015-07-31 13:59:54)

maverick · 2015-07-31 14:06:15

ruud wrote #293860:

My point was that technically there isn’t much difference between pages and forms so there’s no need to have both of them. If it were up to me, I’d merge ‘pages’ and ‘forms’ into ‘templates’ which could be grouped into user-configurable template types (much like the form types, only not hard-coded as they are now). But it’s not up to me and it’s not easy to do if you want to be able to upgrade old TXP installs easily.

On a functionality level, that makes sense. On a UI level, I definitely would want to be able to separate those items that function as forms currently do from those that are functioning as full page template. It seems that it might matter a bit too when associating a section to a page? Perhaps there is a benefit in simplifying the UI, but keeping the option for the user to choose from a default type of either 1. “page type” or 2. “include” (or “partial” or “snippet” )

Then there would be one less tab in the Admin UI for the end user to learn.

Last edited by maverick (2015-07-31 14:07:05)

Destry · 2015-07-31 15:17:20

[some prior stuff about why renaming forms shouldn’t happen]

towndock wrote #293856:

However, for Textpattern to move forward some historical foundations may need to change.

Absolutely! Outdated documentation and buried forum threads is no reason to not improve the usability of the system. On the contrary, now is an ideal time to change the label, there’s fire under development, we’re rewriting user docs, opening up the .com blog to contributor tutorials, an newsletter is in the works (if I’m not mistaken), etc.

Snippets, Partials, Trouser Snakes… one of them has to be more universally understood as “includes” than Forms.

Bloke · 2015-08-02 22:05:08

jakob wrote #293858:

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?

Not necessarily. You may have missed the post about the various options buried in the Theme discussion thread. But the overwhelming response was to go for the path of least resistance: manual assignment.

Sidestepping Bert’s simplification of a theme only being one Page/Style, a Theme at its most basic level is an independent collection of Pages, Forms and Stylesheets. As a designer, that’s the primary focus: make the site look and work in a particular fashion, with the assumption that it will be the sole Theme in use on anyone’s site. People who install that theme then assign it to one or more of their existing Sections and it shows up on the public site when the relevant content is viewed.

Now if a particular person likes the look of two Themes, great. Install both. Assign Theme A to three Sections and Theme B to a fourth. It’s not your job as the designer to anticipate this split. It’s up to the person who decided to employ two Themes to unify the look and feel so their menu structures work. Theme B just gives them a leg-up so they don’t need to start from scratch if some Sections of their site demand a significantly different layout that Theme A doesn’t fit as well.

If, however, you as a designer had a multi-faceted Theme in mind, then by all means go to town. Create one Theme containing many Pages/Forms/Stylesheets that all inter-relate and give them suitable sectionish names to indicate their intended usage. That way, people can assign the appropriate Page/Style to the Sections that best fit their site divisions.

Textpattern cold make this process more flexible. I had envisaged that if you viewed Section A which was assigned to Theme A (and therefore only had access to Page set A, Stylesheet set A, and Form set A) then any call to <txp:css /> without the name, for example, would render the CSS from that Theme. If you added the name attribute it would have to match the name of a stylesheet in the Theme that was assigned to the Section. Since the assets in the Theme have been designed to work together, the designer has used the correct names in the templates, so everything just works, as long as the person who is using the theme doesn’t make any sweeping changes. But if they do, well, that’s their prerogative, and smd_where_used becomes their next best friend.

This is a slightly inflexible approach insofar as there is no way to refer to any asset outside the Theme in which it’s defined. Perhaps this could be relaxed by adding an optional theme attribute to <txp:css /> and <txp:output_form />. That would at least permit someone who did wish to employ multiple Themes to pull out, say, the navigational elements and Styles into separate assets in one of the Themes and cross-link to them from any other installed Theme.

Not sure where that leaves the form attribute in other tags, as those would be confined to the Theme in which they were used. But that’s not really a bad thing as they tend to be presentational within the context of a Theme for displaying lists of things and formatting content. All the theme attribute would do would be to permit cross-linking of essential building blocks: something that (ummm, I think) only makes sense to do with <txp:css /> and <txp:output_form /> tags.

Would that sort of address your concern, or have I missed the point?

michaelkpate · 2015-08-03 14:47:53

Bloke wrote #293914:

This is a slightly inflexible approach insofar as there is no way to refer to any asset outside the Theme in which it’s defined. Perhaps this could be relaxed by adding an optional theme attribute to <txp:css /> and <txp:output_form />. That would at least permit someone who did wish to employ multiple Themes to pull out, say, the navigational elements and Styles into separate assets in one of the Themes and cross-link to them from any other installed Theme.

All the theme attribute would do would be to permit cross-linking of essential building blocks: something that (ummm, I think) only makes sense to do with <txp:css /> and <txp:output_form /> tags.

I that could be very useful. The main thing I have been worrying about is not having namespace collisions between forms in two different themes.

Perhaps there could be a way to enhance the duplicate option to transfer between themes (although copy and paste works easily enough).

candyman · 2015-08-03 16:06:13

Destry wrote #293878:

Outdated documentation and buried forum threads is no reason to not improve the usability of the system.

Snippets, Partials, Trouser Snakes… one of them has to be more universally understood as “includes” than Forms.

We have to see if the advantage that we gain simply changing a name (from Forms to wordchoice) will deserve all the disadvantages that that change will port.

The changing of the name, according to me, is would not be a great step forward. The updating of all the docs and the buring of all unuseful threads (if so we can call them) would make sense only if due to an epocal change.

We all know what Forms are, don’t we? Are you sure that changing a name into another will improve the usability? I think it will lead to more confusion to the newcomer that will find some tips that now are usefull, ununderstandable.

Last edited by candyman (2015-08-03 16:17:10)

michaelkpate · 2015-08-03 18:28:06

candyman wrote #293919:

We all know what Forms are, don’t we? Are you sure that changing a name into another will improve the usability? I think it will lead to more confusion to the newcomer that will find some tips that now are usefull, ununderstandable.

I think most people know what forms are.

A webform, web form or HTML form on a web page allows a user to enter data that is sent to a server for processing. Forms can resemble paper or database forms because web users fill out the forms using checkboxes, radio buttons, or text fields. For example, forms can be used to enter shipping or credit card data to order a product, or can be used to retrieve search results from a search engine. – Form

But not perhaps the way Textpattern defines them.

Textpattern Forms are predefined portions of text, Textpattern Tags, and/or HTML, which collectively define how content should be formatted and displayed. Textpattern forms are easily created in the Forms panel. Forms are used by the Tags that call them, via the form=”“ attribute. Once you have a good grasp of Tags, Forms, and the relationship between, you’ll begin to realize the seeming endless possibilities of how to customize your website’s architecture and content. – (Forms Explained)

jakob · 2015-08-10 12:39:09

Bloke wrote #293914:

Not necessarily. You may have missed the post about the various options buried in the Theme discussion thread. But the overwhelming response was to go for the path of least resistance: manual assignment.

Sorry for the late reply: I was away last week and unable to reply. Thanks for clarifying the thinking behind it.

I see the advantages in being able to “bolt on” different theme components from other themes rather than switch and discard what is already okay. I still wonder if it will lead to problems in how people ‘expect’ themes to behave and in helping people on the forum (we’ll need to ask “what theme(s) are you using for which section(s)?” or “…for the section in question” rather than “what theme are you using?”) but I suppose that depends on what the received notion of a theme is, and that may be a matter of how it is communicated.

I like the idea of a coordinated set of themes, and I guess there it makes sense to split css into core and section/functionality css.

maverick · 2015-08-10 15:59:07

jakob wrote #294048:

but I suppose that depends on what the received notion of a theme is, and that may be a matter of how it is communicated.

I’m supportive of a section by section approach, which we functionally have now. I also am supportive of having section agnostic options for code; so when it needs to be included regardless of themes/sections it can be. Again, which functionally we can do now. To the simple minded as myself, the change is really about organization – how to group and name these without losing current functionality.

That said, I too am cautious about support and troubleshooting. From that perspective is seems like complications might be ahead.

So letting my inside thoughts outside :P

Right now we treat pages and forms from an editor paradigm (which I’m a fan of – I use the editors :D). The editor is front and center, and the list of pages, or forms, or CSS are off to the side. From a screen real estate perspective, it can be high-density.

What if there was a tab or three (I’d lean to a single unified tab divided by page/form/css, each section capable of collapsing) showing each page, form, and css in a grid; page/form/css name on the left, and a used by to the right, with every place it is used listed. With the advent of templates/themes/packages/etc. it would be a quick and fast way to find out this form is being used by two themes. This css is being used by all the themes. This page is being used by this section(s)

Perhaps this is plugin territory and I know smd_where_used can be installed for some if not all of this and more. But to be visually focused this way might go a long way to managing the junction of themes with pages/forms/css and give a tool for help discussions.

fwiw

Last edited by maverick (2015-08-10 16:01:40)

Textpattern CMS

Textpattern CMS support forum

#25 2015-07-30 21:37:52

Re: WTF do we need form types for?

uli wrote #293859:

#26 2015-07-30 23:00:09

Re: WTF do we need form types for?

#27 2015-07-31 12:41:06

Re: WTF do we need form types for?

philwareham wrote #293846:

#28 2015-07-31 13:59:12

Re: WTF do we need form types for?

jakob wrote #293858:

#29 2015-07-31 14:06:15

Re: WTF do we need form types for?

ruud wrote #293860:

#30 2015-07-31 15:17:20

Re: WTF do we need form types for?

towndock wrote #293856:

#31 2015-08-02 22:05:08

Re: WTF do we need form types for?

jakob wrote #293858:

#32 2015-08-03 14:47:53

Re: WTF do we need form types for?

Bloke wrote #293914:

#33 2015-08-03 16:06:13

Re: WTF do we need form types for?

Destry wrote #293878:

#34 2015-08-03 18:28:06

Re: WTF do we need form types for?

candyman wrote #293919:

#35 2015-08-10 12:39:09

Re: WTF do we need form types for?

Bloke wrote #293914:

#36 2015-08-10 15:59:07

Re: WTF do we need form types for?

jakob wrote #294048:

Board footer