Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Situation report for Textpattern 4.6 and beyond
etc wrote #279610:
what is the
grouprole? Isn’t it intended to be used for filtering
Just arbitrary subdivisions, per content type. We’ll probably skim over the core using it at all for now, and leave it up to plugins to use. That means they can decide if the event names are for public side, admin side or both. There’s no implied taxonomy here. It’s just:
- You create a custom field.
- You assign it to a content type (which is now a string).
- You can give it an
eventname of your choosing. It could be used to group them within that content type, or add some kind of label, or be used to tie custom fields across content types.
That last one about tying fields to multiple types is a stretch. But in the absence of being able to create one custom field that can be used for more than one content type, it might enable a plugin to offer that facility by, for example, hooking into the rendering portion of the code and displaying the same field on the Images and Write panels if they had the same event name assigned.
Of course, that brings up a good point. If you do want to share fields across content types, what’s the best way to do it:
- The core shouldn’t allow it out of the box. So, just like categories, if you want the same field for more than one content type, you create a second field. Neat, clean, isolated, no dependencies, less likely to break other content types if someone modifies a field, but an admin hassle for users to maintain multiple fields if they want this facility.
- Permit the
content_typefield to hold multiple, delimited items, e.g.article, image. Feels messy and non-SQLish. - Add a table or two (which therefore adds one or two joins) that maps a field to N content types. In which case, going back to using an ID for the content_type field makes sense, with the types defined in a separate table (of which the core has a handful pre-defined). Collisions would be avoided by making that ID an auto-increment so you have to ‘register’ your content type first if you wish to extend the core types, and making sure that all custom types start at, say, 100+ in case we ever need to extend the core ones in future.
I guess it comes down to whether we think that sharing custom fields is worthy of the coding and/or potential retrieval overhead. If it’s perceived that only a fraction of people would use such a feature then option (1) is the way to go, with the fallback that people (a.k.a. plugins) could use the event field to simulate cross-type fields. If we think that the ability to assign the same field to multiple types is important, then (2) or (3) (or any other?) implementation should be investigated, with increased code complexity, but increased flexibility.
At the end of the day, the actual value data is stored in the same table anyway, regardless of which content_type the particular field is assigned — if it’s defined as a yesnoradio then it’s stored as a boolean/int value no matter what content_type it is assigned. So as far as the public side is concerned, it extracts the values and presents them as part of the content type’s tags. It only really affects admin side management of fields.
Anyone got any gut feelings on whether multiple fields across types is desirable, or a waste of effort?
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Situation report for Textpattern 4.6 and beyond
Bloke wrote #279613:
Anyone got any gut feelings on whether multiple fields across types is desirable, or a waste of effort?
Could be. It wouldn’t have any performance impact either — it’s just for the admin UI. That said, if you don’t have content registry, how do you register content types…? By having to keep plugins loaded for that type and the value is created on runtime, but is that ideal.
If you want to limit the content-types to events, you can merge content-type definitions with permissions table (event idx). That said, also permissions will require few tables, unless you identify privileges with a lowest/highest user-level integers.
Add a table or two (which therefore adds one or two joins) that maps a field to N content types. In which case, going back to using an ID for the content_type field makes sense, with the types defined in a separate table (of which the core has a handful pre-defined).
If implemented, it should be done with this. It would require the definition of content-type and then the mapping of content-type and the field; two tables.
Collisions would be avoided by making that ID an auto-increment so you have to ‘register’ your content type first if you wish to extend the core types, and making sure that all custom types start at, say, 100+ in case we ever need to extend the core ones in future.
There is no need. We would just insert new rows to the ‘content_types’ table and mark the owner as ‘core’ making them not deletable.
We aren’t going to create fields itself to existing sites of course, and if we are, we are going to use the same code as everyone else instead of hard-coded constants and we don’t need persistent IDs. We will also use the content_types registry as everyone else.
Offline
Re: Situation report for Textpattern 4.6 and beyond
Bloke wrote #279613:
Permit the
content_typefield to hold multiple, delimited items, e.g.article, image. Feels messy and non-SQLish.
Gocom wrote #279620:
It wouldn’t have any performance impact either — it’s just for the admin UI.
Don’t we have to check content_type (through meta_id) when retrieving value from txp_meta_value_ tables public-side for, say, an image with a given content_id?
Offline
Re: Situation report for Textpattern 4.6 and beyond
Now we’re talking. Well, you guys are talking. And that’s great.
I’d like to just add this…
Whatever happens, please don’t use the term “prototype” or “silo” in any official capacity — Txp semantics, UI dialogue, etc. They are less than ideal.
“Prototype” is not a bad word, per se, but it’s very indicative of something unfinished. Not live. Not production. And it gives a completely different notion of what is being talked about, because most people already have an idea of what a prototype is (and it’s not an article model). If what you are talking about is content types, then use “content types” — plain as day, and everybody knows what that means — and the world will understand you. If that’s technically impossible (e.g., because it’s two words), then use “model”, which is the next best thing because a model can represent something both in development and in production, unlike “prototype”.
“Silo” is a negative word, a stigma word, and about the worst word you can mention in the content strategy world, for many reasons. It’s the de facto word to mean content or information that is penned-up and cut-off from everything else, and thus not as valuable as it could be. You do not want to say “silo” about anything, anywhere, if you want more Textpattern adoption.
Let’s remember how long we’ve suffered with semantic flub-ups like “Forms”. Don’t make the same mistakes. Always use the most straight-forward, logical, and positive labels you can, if you want to help improve the UX.
Offline
Re: Situation report for Textpattern 4.6 and beyond
Textpattern ‘custom field kittens’. The internet loves kittens, right? :)
Offline
Re: Situation report for Textpattern 4.6 and beyond
Destry wrote #279872:
Whatever happens, please don’t use the term “prototype” or “silo” in any official capacity — Txp semantics, UI dialogue, etc. They are less than ideal.
+1.
Offline
Re: Situation report for Textpattern 4.6 and beyond
Rather than start a new thread for this, I’m going to throw this out for consideration/discussion: is the release of 4.6 a good time to turn development to GitHub instead of Google Code?
Genuine question, not trolling or antagonising.
Edit: missed a word.
Last edited by gaekwad (2014-05-15 13:29:40)
Offline
Re: Situation report for Textpattern 4.6 and beyond
gaekwad wrote #280822:
Rather than start a new thread for this, I’m going to throw this out for consideration/discussion: is the release of 4.6 a good time to turn development to GitHub instead of Google Code?
Genuine question, not trolling or antagonising.
Edit: missed a word.
I am not a coder. But from the user perspective Github is quite easy to understand and very common as well. So it might make it easier to submit bug reports for the average user…
Last edited by dos (2014-05-18 12:42:32)
“HaHa. Your medium is dying.” –Nelson Muntz, Springfield.
Offline
Re: Situation report for Textpattern 4.6 and beyond
GitHub will happen eventually, I probably need help from Jukka to do this though, as he’s more of an expert on all things git.
Offline
Offline
Offline
Re: Situation report for Textpattern 4.6 and beyond
after taking a quick look at bolt and locomotive… I will patiently await Textpattern’s next version
…. texted postive
Offline
Re: Situation report for Textpattern 4.6 and beyond
etc wrote #281071:
I don’t know how popular Locomotive CMS is, but they feature custom (and interrelated) content types. We shouldn’t miss the train…
Fantastic idea! circa 2007 ;)
Offline
Re: Situation report for Textpattern 4.6 and beyond
mrdale wrote #281084:
Fantastic idea! circa 2007 ;)
Patent number, por favor :) Now in 2014 the devs are working hard on custom fields. That will be a really big change, and custom content types might be not too difficult to add.
Offline
#90 2014-07-01 03:47:28
- DragonBard
- Member
- Registered: 2014-07-01
- Posts: 16
Re: Situation report for Textpattern 4.6 and beyond
Bloke wrote #279529:
Sorry to disappoint everyone, but this is the current database structure I have:
# Dump of table txp_meta...No doubt that’s all wrong because I’m just a beginner at SQL and relational databases. The notion of storing things in flat tables is utterly retarded, imo. I get so frustrated having to “downgrade” my thinking from true direct ERD-mapped databases to this rigid rows and columns abomination that’s dominated the market for over thirty years. I started out working with E-R databases for ten years (had never heard of relational at the time). Then someone showed me tables, rows, columns, 4NF and SQL, and I died a little inside. sigh
Anyway, with my rudimentary table wrangling, that’s what I have so far. Shoot it down if you want, but I’d rather someone improved it instead.
1. Relational is not “flat tables”. That’s just a convenient handle for comprehension. Relations are multi-dimension, not 2D.
2. MyISAM is NOT relational. It is pseudo-relational. Please switch to InnoDB so you can use constraints and impart some sanity on your development efforts.
3. You are falling into the SQL trap of believing the data type is the domain. It is not. The best way to demonstrate this is the idiocy of AddressLine1, AddressLine2, AddressLine3 I see everywhere. Unless you are doing GIS you don’t need to separate the elements of an address (and if you are doing GIS, you will separate it entirely different). The domain is address, so store it as an address. Yes, that’s right store the entire address as a large nvarchar, allow the enter key, and be done with it. Maybe if you are doing large mailings you might want to separate the city, state, and postal code for presorting purposes, but otherwise don’t bother.
4. You can get what you are after with far fewer tables. Don’t fall for storing data as it’s “true” data-type. Just store it as a reasonable length string, with appropriate linkages to where used. Use a hierarchical (aka self-referential) table to store the custom field types in their registry. The registry should consist of an ID, name, possibly a label, and help tip. Here is the fun part. Add two to four large fields, possibly text. The purpose of the fields is to provide the code to handle the admin side and published side view of the custom fields (two fields if no JavaScript, four fields if you will allow JavaScript). Let the implementer worry about how to interpret, verify, format, spindle, mutilate, and fold their own data. In other words, use the exact same idea as textpattern forms, in a smaller scale. The domain you should be implementing is “custom field”. You are currently implementing a custom SQL table editor.
5. You should be able to implement core custom fields with about 4 tables. Registry, Hierarchy, FieldValues, and FieldUse. Of course, modifying it to fit textpattern and adding security will grow the solution set. I’m only just beginning in using textpattern, but I built a similar custom field implementation back in 2001 in classic ASP, and it was plenty fast, even with loading the display handler code from the database for every page view. Cache the handlers and it should be plenty fast. That was a project for work, which died due to lack of interest.
By now, my suggestions may be too late. Take them in the spirit of cooperation they are intended and do with them as you will.
DragonBard.
Offline