Thanks for any help. --John
If we go with multiple cardtypes, we'll want to expose type as a card. My sense is we're refactoring some related stuff, would that make this a pretty easy thing to do?
--John Abbe.....Sat Feb 19 23:30:55 -0800 2011
I've been wanting to do something like this. Not super easy, but we'll probably need to figure it out.
Relatedly, I've wondered whether absolute inclusions in forms should show up as fields. Kind of seems like we should do normal rendering of anything that is not relative to the card being (multi-) edited, and add all those fields to the form.
I think the answer to "how hard" is "fairly". Wouldn't want to count on it being less than 2 days of coding, and it's deep enough that we wouldn't want to release right away. I think we should do this, but I don't think any near-term deliverables should ride on it.
--Ethan McCutchen.....Sun Feb 20 08:53:33 -0800 2011
Thx. So:
render absolute inclusions in forms
Is the thing you say will take 2+ days of coding let one form control multiple forms (or would rendering absolute inclusions handle that?), or expose cardtype as a card? If the latter, I'm guessing that includes making it editable and if that's the case, what about just making it visible?
--John Abbe.....Sun Feb 20 15:28:54 -0800 2011
it's build special inclusion handling for forms. That includes lots of things, from storing the references in a special way to treating absolute and relative inclusions differently to having the custom form editing interface. I couldn't do all of that in anywhere near 2 days, but it would take that long to build and test the underlying structure that they would all share.
--Ethan McCutchen.....Sun Feb 20 21:43:22 -0800 2011