On Thursday 06 March 2014 01:17:51 Paolo Coffetti wrote:
> Hi Django devs,
>
> I want to share an idea with you and get some feedback in order to know if
> it makes sense, if it could solve a common problem and maybe evolve into an
> official GSoC proposal.
>
> Some years ago I was working on a printing on demand website using Django
> 1.2 and some model forms.
> Our front-end guy designed a HTML form that had:
> - A *paper type* <select> tag with options: A4, A5
> - A *color* <select> tag with options: B&W, COLORS
> The form must follow some business rules:
> - B&W available only for A4
> - COLORS available only for A5
> (actually the original problem was a bit more complicated, but I'll keep it
> short...)
>
> The solution I adopted was made of the following components.
> - A classic Django *model* and a *ModelForm* to manage and render the
> *paper type* and *color* form fields.
> Plus a Django *model* to implement the 2 rules
> - A minimal *Javascript* code to detect an interaction of the user with
> the *paper type* or *color* field: when the user changed the selected value
> of *paper type* to f.i. A4, the entire form was sent back to Django using a
> AJAX request.
> - After receiving the edited form, Django checked the rules, disabled the
> unavailable options, COLORS in our case (by setting <option
> disabled="disabled" value="1">COLORS</option>), rendered the form to HTML
> and sent it back to the AJAX request.
> This behavior was implemented with a custom *form widget*.
>
> With this solution users had a clear visual feedback on what the rules
> were.
>
> Do you think this was a good design?
This depends on a detail you haven't given us: How are these rules controlled?
How do they evolve?
The design is probably ok if the rules need to be changed by users. If changes
are rare and correspond to system changes, then this appears to be quite over-
engineered -- it would be simpler and much more efficient to just hard-code the
rules in JavaScript, all on the client side. You would still need to validate
the forms on the server, of course, but not every selection change would need
to involve a web request.
Actually, it would probably be a better design to have the client handle it
all by itself even if the rules are changed by users -- the JavaScript code
would need to be a little more complex, and would need to rely on data
provided by the server at page load; but unless it is crucial that whenever
the rules change, even users who have already opened the page (before the
change) have their UI behave according to new rules, this would still be
simpler and more efficient.
> Is there a better solution nowadays?
> Do you believe this could be a solution to a common problem? Could this
> idea evolve to a GSoC proposal (from myself of course)? Or maybe this idea
> is more likely a third-party library so it does not fit GSoC?
Cross-field client-side form validation could be an interesting idea, but I
don't see why it needs to be developed in core. There are probably already
some solutions along these lines out there. This does not automatically mean
it is unsuitable for GSoC -- but it does raise the bar.
HTH,
Shai.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/201403102325.33545.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.
