Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#11 2020-06-27 15:29:50
- Bloke
- Developer
- From: Leeds, UK
- Registered: 2006-01-29
- Posts: 9,983
- Website
Re: Outgrow links tab
The tricky thing with treating everything as an article with a bunch of fields, while noble, is that some types just don’t fit. Primarily, image, file, video, but there are others.
You can create a “person” content type fairly easily. It has name (text), email (text/email), role (text or link to another table of roles), maybe description, some other custom fields of your liking for social media profile-du-jour, and image as an avatar… uh-oh. That last one’s not a native ‘thing’.
Now take Image as a content type. Name (filename?), alt text, caption, date created/uploaded, camera metadata as custom fields, then the image itself… uh oh. That is a file we don’t want to store in the DB; it’s a reference to an external file. It has dimensions. It has pixel density. Sure these could be additional fields. It has thumbnails of varying sizes. Hmmm, that means creating multiple ‘image objects’ and linking them together with differing dimensions in each one – and do they share alt text or is each one potentially unique? – or extending the definition of this image type with a bunch of columns that represent the other fields. The latter limits your ability to customise the content type.
Same with files. They also have physical assets stored parallel to the metadata. Things like videos might have an image used as an overlay too, and these need handling differently.
And then there’s how to get at the metadata in meaningful ways. Sure we could make a single tag <txp:get type="file" field="name" />
but that’s going to make things reeeeeeally wordy in your templates.
It’s not impossible, but the storage requirements and edge cases – let alone the flexibility to define types in meaningful ways – means that the onus becomes less on “Just write” and more on “Just configure before you can write”.
Modularising core types? Sure. We’ve started going down that route in a few places – Help is one. We could do the same with comments, so all tags and functionality are effectively bundled into a single content suite. If you disable the comments module, everything gets switched off (that’s not to be confused with having comments available but switching them off on an article).
But storing everything as “article + CFs” and then abstracting that to other types sounds like we might end up with a tonne of ‘exceptions’ in the code to handle the nuances of each type that doesn’t quite fit into the article model. We’ve only got four types – well, three because, yeah, Links could be handled as a specialised form of articles easily.
In theory of course, a custom content type is nothing other than a collection of custom fields. Some are treated in special ways (e.g. an Image field or a Video field) but they’re just metadata. There are, however, more nuances than that. Whether a type is searchable, whether to syndicate it. Does changing the alt text of an image mean it’s “updated” in terms of syndication? What happens if you delete something? How does that cascade to any assets on disk vs database?
Lots to think about.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Online
#12 2020-06-27 16:56:04
- colak
- Admin
- From: Cyprus
- Registered: 2004-11-20
- Posts: 8,460
- Website
Re: Outgrow links tab
Bloke wrote #324056:
The tricky thing with treating everything as an article with a bunch of fields, while noble, is that some types just don’t fit. Primarily, image, file, video, but there are others.
I agree with you! That is why I just mentioned the Links tab.
… Lots to think about.
Indeed! But links at the moment basically consist of textual data and insufficient custom fields. I know the later will be dealt with and I really liked the idea of the addition of an image field but again, this could be achieved by a custom field for image_ids content, set by the user.
Unlike media types links could be as simple as they were first intended or more complex. For example, further to the requests by Destry, we should also think of including local links to this equation. Unlike external ones, the local ones could be holding just the id of the article in order to allow for URL pattern changes in the site’s lifetime (ie. <txp:permlink id="##" />
). Then there is the issue of linking to section and/or category landing pages and the renaming of those sections or the changes in the URL pattern. At the moment sections and categories are not tied with ids and we may have to start thinking about those too.
We may also need to think of the rel
and target
attributes and any other meta information not yet in the html specs.
One issue that I had in the latest restructuring of the NeMe site was with the breadcrumbs tag which does not recognise the URL pattern (yet). I have built those links manually. Although links related, this is not related to this thread
I can think of many ways I can achieve the above using articles in pageless sections, and I’m looking forward to unlimited grouped CFs so that I can implement them. I’m very excited with this direction!1
Some questions.
- How do you guys envisage grouped CFs in the Writers’ interface?
- Will they be part of the
separationsunity tabs2 in the accordion? - Instead of only having one Custom fields unity tab, will we have as many unity tabs as the designers (Role) define?
1 Although I expect that the revamped Links pane might be able to cope too.
2 I’m not sure how to call the main menu in the accordion:)
Last edited by colak (2020-06-27 17:24:24)
Yiannis
——————————
neme.org | hblack.net | State Machines | NeMe @ github
I do my best editing after I click on the submit button.
Offline
#13 2020-06-27 17:46:58
- etc
- Developer
- Registered: 2010-11-11
- Posts: 4,058
- Website
Re: Outgrow links tab
Bloke wrote #324056:
The tricky thing with treating everything as an article with a bunch of fields, while noble, is that some types just don’t fit. Primarily, image, file, video, but there are others.
Note that I’ve always made a distinction between ‘physical’ images and their ‘presentation’ enhanced with captions and other garniture. And they are not exception: who says a text can not be stored in a file and imported where appropriate?
I’ve got no clear idea how things should be done. One can imagine that ‘articles’ are composed of ‘atomic’ items (like textual fields) and references to other ‘articles’ (like annotated images).
Offline
#14 2020-06-27 17:51:54
- Bloke
- Developer
- From: Leeds, UK
- Registered: 2006-01-29
- Posts: 9,983
- Website
Re: Outgrow links tab
etc wrote #324060:
Note that I’ve always made a distinction between ‘physical’ images and their ‘presentation’ enhanced with captions and other garniture. And they are not exception: who says a text can not be stored in a file and imported where appropriate?
True.
One can imagine that ‘articles’ are composed of ‘atomic’ items (like textual fields) and references to other ‘articles’ (like annotated images).
Also true.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Online
#15 2020-06-27 17:52:40
- etc
- Developer
- Registered: 2010-11-11
- Posts: 4,058
- Website
Offline
#16 2020-06-27 18:08:22
- etc
- Developer
- Registered: 2010-11-11
- Posts: 4,058
- Website
Re: Outgrow links tab
Bloke wrote #324062:
Also true.
Then we have just ‘fields’ and ‘files’ as atomic data, and just ‘article’ as content type. Current ‘images’ become image-type ‘articles’ with customizable data set (physical image, caption and whatever you need). ‘Normal’ articles can include them via ‘article_image’ field. Actually, that’s already possible, but not flexible enough.
Offline
#17 2020-12-24 15:40:48
- Pat64
- Plugin Author
- From: France
- Registered: 2005-12-12
- Posts: 1,453
- Website
Re: Outgrow links tab
Thank you, Stef.
What good news! Custom fields with section sensitive display will reduce the amount of elements into the “Write” page and avoid affection errors by the final users (authors).
Patrick.
Github | CodePen | Codier | Simplr theme | Wait Me: a maintenance theme | [\a mi.ni.ma]: a “Low Tech” simple Blog theme.
Offline