Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: [RFC] TXP5 Custom Fields Management
A content type builder works for me, if it can be made usable and fast.
Nothing to stop it being part of the Entity definition panel, maybe. Although we don’t necessarily know the fields at that point, so it mght be better done separately.
In terms of output format, can I tentatively make a suggestion to store layouts as *whispers* XML? Makes it easier to offer import / export of layouts in a semi-human and machine usable format.
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
Offline
Re: [RFC] TXP5 Custom Fields Management
Unless I misunderstand the idea, having to create a layout for every entity is not what I’d call “just write”. And what if you need to add/remove a cf to/from multiple entities via some multi-edit widget? And good luck for the builder implementation.
There will be an entity definition panel, but going beyond the sort order makes me think of.. other cms.
Offline
Re: [RFC] TXP5 Custom Fields Management
etc wrote #340759:
There will be an entity definition panel, but going beyond the sort order makes me think of.. other cms.
Haha yeah. If it’s too much of an overhead then I’m of the same opinion.
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
Offline
Re: [RFC] TXP5 Custom Fields Management
How about we leave designing panel layouts to plugin/admin theme authors? Core will make a best attempt at putting the controls in the most relevant position – and perhaps we can provide some simple mechanisms or naming conventions to nudge it one way or another, but that’s it.
We provide hooks, and any fine-grained control is down to an external entity to massage the layout.
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
Offline
Re: [RFC] TXP5 Custom Fields Management
Offline
Re: [RFC] TXP5 Custom Fields Management
So I’ve had a stab at realigning the _update scripts in the _to_5.0.0.php with Oleg’s latest table changes. Removed a few columns and whatnot, added the missing tables, and populated what I could.
I haven’t quite got my head round what the txp_entity_delta table is yet, so it’s currently unpopulated on upgrade. Any info to guide me would be most welcome. I suspect it links to the values table so we may need to split that info when migrating data from the textpattern custom_N columns to the new tables on initial upgrade.
If I’ve screwed up the data transfer, please feel free to alter what I’ve done.
I’ve created an entity type for all base types by reading the data from ContentType->getTableColumnMap(). That way, we know the IDs of the “core” content types and anything higher is custom-defined. Using the magic number in the code for the entity ID feels kind of kludgy, imo. I think it’d be more readable to use the name, and that also guards against those siutations where someone might start with a ‘zero’ theme that only has custom entity types in it, or only populates one or two of the core types.
Happy to revisit this and only create ‘article’ out of the box.
Last edited by Bloke (Yesterday 22:17:47)
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
Offline
Re: [RFC] TXP5 Custom Fields Management
Now we have core panels for entity type definitions, we have the opportunity to register “Entity shortcuts” that feed into Textpattern’s Just Write philosophy. Currently, we have one entity shortcut built in: Write which is very, very hard-coded into core.
What we could do is add a database field (similar to the way we handle “On Front page” and “Syndicate?” for Sections) called “Direct editing” (for example). If you Set that to ‘Yes’, your custom entity label could appear as a first-class citizen on the Content menu, which saves you a few clicks having to go to the content type ‘list’ panel, select the entity type and click ‘New’.
However:
- What happens if the number of entities you want to put on there grows large?
- Should we allow other core content types there? That creates problems for things like Users and Sections, because they have menu entries in other parts of the system, which could get confusing unless we allow people to rename how the core types appear on the Content menu.
- What is an entity type based on ‘Section’ or ‘User’ anyway?
- Do we need a ‘Media’ content type (so Images (and Files?) become an entity type based on Media, and people can add their own for Audio, Video, …)
The other option, instead of a column in the table, is a per-user pref. Perhaps a dropdown of all entity types and you multi-select the ones you want to have direct access from the Content (or whatever) menu. That seems more flexible, imo, as not everyone’s workflow will need to be dictated by an admin.
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
Offline
Re: [RFC] TXP5 Custom Fields Management
Side note: the moment an entity is created, its label becomes “fixed” in the current language. Could we hook the labels up to the txp_lang table instead, so they change if the admin language is switched?
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
Offline