On Sat, 2007-03-24 at 08:41 +1100, Malcolm Tredinnick wrote: > Quite often, preview and edit are combined on the same form, so you see > the preview version at the top and the editable fields lower down. If > you do this, your single form (for edit/create) just needs a block at > the top that contains the optional "static preview" version.
Yeah. I don't mind this much in wikis, but it feels ugly to me in general, especially if the form is rather long. > Another way is to layout the form fields as you normally would and then > use CSS to hide them (feels ugly to me, but technically possible). That's an idea, but probably not great for text readers. And you're right--using CSS for what is basically content formatting is just as bad, IMHO, as using HTML for presentation. > If you don't want to do either of these and truly want to store the > information in hidden fields the second time around, then, yes, you are > going to have to specify all the hidden fields, or provide a way to > alter the "type" of your original fields between their editable type and > "hidden". So there will be some repetition, whether you generate them > programmatically or by hand. That really can't be avoided because you > *are* repeating the information. Let me ask a silly question before I go off and do something radical, just to make sure I won't hit a brick wall later. I'm trying to model every conceivable kind of question in a way that won't involve changing the database later. To do this, my Question model has some meta-information and has a OneToMany mapping to a DataBit model. A DataBit has fields for type and one piece each of textual and numeric data. If I want a true/false question, it has two DataBit objects: a bit containing the statement and a bit indicating whether it's true or false. If I want a fill-in-the-blank question, it has one DataBit instance for the statement and one for each answer that belongs in the blanks. For a multiple-choice question, there are several bits: the question, each possible answer, and a bit saying which answer is correct. Obviously, trying to represent these things directly from the database is a bit of a pain, so I have non-model classes that translate from the representation in the database to a more natural representation and vice versa. These classes also create the forms (as in django.newforms) that I display. Could I pickle one of these non-model objects and use the pickled value in a hidden field to store everything all at once and then get it back really easily? I've never used pickle, so I'm a little apprehensive that there are gotchas I don't know about, but, if it works the way it's advertised, it seems an easy way to dump something into the preview and then reconstruct it on the way out. Are there any gotchas I should be aware of before I start? Thanks for reading all of that, Todd --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
