Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: [request] "Cascading" custom fields.
can’t a man sit on the fence and cheer in peace these days?
;)
Well I kind of grasp the ‘cascade’ concept, but can’t really see the usefulness of specifying the contents of custom fields at a section/global level… couldn’t you can kind of do that already with <code><txp:if_custom_field name=“pies”><txp:custom_field name=“pies” /><txp:else />we’re all out of pies</txp:if_custom_field></code> in your form? Maybe I’m missing the point tho.. it happens!
My cheer was mainly for the idea of (DOM enabled or otherwise) reloading the custom fields visible in the Write tab when you assign it a Section.
I think it would make the user-interface a whole lot more friendly, and this would be another big step towards making Txp a stronger option for more complex sites.
Like Bloke, I use custom fields pretty extensivey and I know from experience that people have trouble remembering to use which fields in which sections. In my current build I’m naming them with the section name as a prefix, but that’s not really a great solution.
Ideally, I’d like there to be an extensions tab for custom fields, where you can assign them to multiple sections. Or maybe the other way around would make more sense, as we already have a Sections tab(?)
I can see it might also open up usabilty problems – for instance if you published an article and then changed it to a section with different custom fields, what would happen to the data in the custom fields that you’d saved. I’ve used Cute before, with the functionality we’re talking about here, and sometimes I would start to write an article in the default section, then realise I hadn’t set a Section value, and then lose what I’d typed when I applied one. So it would bring complications, but I’d still kill for it!
Offline
#17 2006-06-28 13:25:01
- net-carver
- Archived Plugin Author
- Registered: 2006-03-08
- Posts: 1,648
Re: [request] "Cascading" custom fields.
pieman wrote:
can’t a man sit on the fence and cheer in peace these days? ;)
Well I kind of grasp the ‘cascade’ concept, but can’t really see the usefulness of specifying the contents of custom fields at a section/global level… couldn’t you can kind of do that already with <code><txp:if_custom_field name=“pies”><txp:custom_field name=“pies” /><txp:else />we’re all out of pies</txp:if_custom_field></code> in your form? Maybe I’m missing the point tho.. it happens!
Knew there was a good reason why no-one was shouting for this :O)
Thanks for the clarification!
Last edited by net-carver (2007-11-27 14:08:56)
— Steve
Offline
Re: [request] "Cascading" custom fields.
I think the cascading custom fields would be very powerful once sub-sections are in place with 4.1
Shoving is the answer – pusher robot
Offline
#19 2006-06-28 16:12:02
- net-carver
- Archived Plugin Author
- Registered: 2006-03-08
- Posts: 1,648
Re: [request] "Cascading" custom fields.
Thanks Patrick! :O)
— Steve
Offline
Re: [request] "Cascading" custom fields.
<blockquote>pieman said…
I can see it might also open up usabilty problems – for instance if you published an article and then changed it to a section with different custom fields, what would happen to the data in the custom fields that you’d saved. I’ve used Cute before, with the functionality we’re talking about here, and sometimes I would start to write an article in the default section, then realise I hadn’t set a Section value, and then lose what I’d typed when I applied one. So it would bring complications, but I’d still kill for it!</blockquote>
Two things:
1) The custom fields for a particular section will be available only after we select that specific section (i hope i’m right). So I dont see a point here, unless I’ve misunderstood you pieman.
2) I bieleve that we usually dont change the section for an article. That’s why categories are in place.
Please correct me if I’m wrong here.
Regards,
Vasanth
Last edited by creativesplash (2006-06-28 16:58:20)
“Take a point, stretch it into a line, curl it into a circle, twist it into a sphere, and punch through the sphere.”
— Albert Einstein
Offline
Re: [request] "Cascading" custom fields.
Hello Vasanth
on point 1, true… that was just my experience from another CMS, but it could be avoided
on point 2, usually is the key word there… you’re right, but the site I’m building at the moment needs to do exactly that
these are all pretty hypothetical problems at the moment though
Last edited by pieman (2006-06-28 17:04:43)
Offline
Re: [request] "Cascading" custom fields.
hakjoon wrote:
I think the cascading custom fields would be very powerful once sub-sections are in place with 4.1
I completely agree with you. It could do miracles and save a lot of time.
pieman wrote:
these are all pretty hypothetical problems at the moment though
I quite agree with you. I may have sounded a bit rude so excuse me for that. I dint mean to be rude though.
My advice would be that you stick to changing categories instead of sections. I myself have come across such a problem, but have solved it by assigning a different category.
Anyway hypothetically speaking you never know. Maybe both categories are busy. Lets say the section has to be changed. My suggestion would be that the custom data should continue to be in the database. There should be a tag (may be <txp:custom_field name="blabla" section="blabla" oldsection="blabla2" />) or something like that to pull out the older custom field data. Just a suggestion though. There may be better ways to handle this issue.
Regards,
Vasanth
“Take a point, stretch it into a line, curl it into a circle, twist it into a sphere, and punch through the sphere.”
— Albert Einstein
Offline
Re: [request] "Cascading" custom fields.
pieman wrote:
I can see it might also open up usabilty problems – for instance if you published an article and then changed it to a section with different custom fields, what would happen to the data in the custom fields that you’d saved. I’ve used Cute before, with the functionality we’re talking about here, and sometimes I would start to write an article in the default section, then realise I hadn’t set a Section value, and then lose what I’d typed when I applied one. So it would bring complications, but I’d still kill for it!
I think if the custom field is of the same field type (text input in both sections for example) I think the custom could probably just remain through a change in section.
Switching from section that has custom1 as a text field to a section that has custom1 as a drop down is more complicated though. That will definitely need to be worked out.
Maintaining old records like Vasanth demonstrates however creates all sort of other complications.
Last edited by hakjoon (2006-06-28 23:57:39)
Shoving is the answer – pusher robot
Offline
Re: [request] "Cascading" custom fields.
Hello all,
Are any of these ideas still alive?
I sure hope so.
—
Tom
Offline
Re: [request] "Cascading" custom fields.
I still want to do the per section custom fields. I just need time.
Shoving is the answer – pusher robot
Offline
Re: [request] "Cascading" custom fields.
Sweet!
Thanks Hakjoon.
This is a really great idea…glad to know it’s still alive.
I know you’ve got a TON of stuff going on with other plugins…
Maybe there is someone else out there that could pick up this idea and run with it?
Anyone? Anyone?
Beuller…Beuller… (sad reference attempt, I know)
Otherwise, I’ll get my bottle of patience and take a big spoonful.
- )
—
Tom
Last edited by renobird (2007-03-16 16:11:23)
Offline
Re: [request] "Cascading" custom fields.
I’m still big-style interested in this idea. To only show certain custom fields in the admin interface depending on section would be sooo useful.
renobird wrote:
Maybe there is someone else out there that could pick up this idea and run with it?
Although I’ve written a couple of plugins, anyone’ll tell you I’m still a meganewbie. I’ve not dared dabble in the dark arts of the admin side yet so this one’s out of scope for me right now, sorry.
I’ll willingly throw my oar in at (un)suitable junctures and also offer my alpha/beta testing services to anyone that wants to rise to the challenge of coding this up. Who knows, maybe in a few months’ time I’ll have learned enough to tackle it myself: hope you’ve got a good stock of that patience juice :-p
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: [request] "Cascading" custom fields.
Thanks Stef!
Glad to see there is still interest out there.
I’ll gladly wait for Hakjoon, just thought I’d throw a “call to developers” out there.
If you get to feeling fancy and want to take a crack at it…I’m happy to be a lab rat.
- ) Cheers.
Offline
Re: [request] "Cascading" custom fields.
hear, hear… there, there…
This whole confab could so easily get hijacked and diverted toward, (music swells mysteriously) custom content types and content type abstraction, but I would never do that, I promise :)
Offline
Re: [request] "Cascading" custom fields.
mrdale wrote:
This whole confab could so easily get hijacked and diverted toward, (music swells mysteriously) custom content types and content type abstraction, but I would never do that, I promise :)
You don’t know how much I want that. Every time I start planning out how to build this I start going down that road and then it becomes too big.
I honestly think that if we moved articles out of the Textpattern table into an articles table and turned the Textpattern table into a routing table for all elements we would be almost there. I was just talking about this with Matthew the other day.
It requires massive changes to pretext and some of the basic building block functions though.
Shoving is the answer – pusher robot
Offline