[GSoC Proposal] Read-only forms and DataBrowse ==============================================
About Me -------------------------- I'm a college student of computer engineering at the Universidad Politécnica de Madrid. This will be my last year before I graduate. I started programming websites six years ago in PHP and various frameworks like Zend Framework among others. Since I came across Django (v1.0) it is the only thing I've used. I have developed a bunch of things in Django including some small commits to Zinnia. I have a good understanding of Python and today I want to show you a proposal. I hope you like it. You can see this proposal in HTML here http://sysvar.net/gsoc2011/proposal_1.html Problem Description -------------------------- The addition of the `newforms` package to Django greatly improved the use of these since the last model. My proposal seeks to fix some of the existing problems and at the same time implement some new features to Django. As it is stated in the Django ideas site for the GSoC one of the remaining tasks is integrating the `django.contrib.databrowse` module into the administration, allowing among other things a read-only administration. My solution is not to integrate the module but to go a little further and allow forms to render in read-only mode (without showing their widget). This would result in various things: * A lot of web applications need to show the same form in two modes: write and read. Django is currently set up in a way the edition part would be already resolved, but the layout of the reading part has to be done manually. With this fix both parts can be done within the same form. * The administration could be viewed in read-only mode without too much coding. A new perm could be implemented (`can_read_xxx`) so if a user had it, he could navigate the administration without the possibility of changing the inputs. This way the need to integrate the databrowse module would be satisfied (without actually doing it). * Pushing things further, I propose the extension of the form perms so each input can be individually selected whether if they need to show up as read or write. If forms come from models they would have in consideration the `editable` attribute. These modes could be dinamically specifed, so that you could choose to leave certain inputs only to some users, while others could only see them in read mode. * Lastly, I propose making the rendering of all the inputs smarter to replicate the 'magic' achieved by the databrowse module. In a similar way to the `get_xxx_display` method available to lists, it would be wise for every field to be able to choose how they will render in read- only mode. In a simple example, we want a `ForeignKey` to be rendered in read mode with a link to it's object. This way a few will be shipped by default (like the ForeignKey ones) but it will be up to the developer to choose how he wants to draw his inputs. This will result in inputs being draw in a constant fashion **all along the website** and not only the administration. With this improvement in the forms we fixed the `databrowse` problem, including all the considered issues like the customization of the display with fields, fieldsets, ... because forms will still work the same way. Besides, with this solution all forms will be provided with the same powers, not just the ones in the administration. Implementation Plan -------------------------- This proposal has two distinct parts. In the first one I seek to extend the forms in Django so they are allowed to be rendered in read-only mode. For this, I propose adapting the code that has to do with the rendering, `_html_output` for example. In this first part there are no major problems because all the form is in read-only mode and we don't have to battle form validations. A new perm will be made `can_view` so the administration will be fully functional in read-only mode. To allow forms to be completely rendered in read-only mode I propose the creation of methods similar to the ones that already exist, for example `as_ul_display`. Lastly the intelligent rendering mode will be implemented (as in the previous ForeignKey example), extending the model so the user can define how he wants the inputs to render (or leave Django sort it out on his own). The second part will be focused to implement individual perms for each input, so users can only edit the ones they are allowed, while still being able to see the others. In this part any problem with form validations will be resolved, except in those the user can't write. Timeline -------------------------- Whilst studying I have enough time, virtually all in summer, in exception of the first weeks of June, when I have exams. * 2 weeks Research, design and discuss all the stuff related to the proposal (for the two parts). * 3 weeks Coding the upgrade for the forms to allow the read-only mode and implementing the intelligent rendering mode of fields. * 2 weeks Adapting the administration so it can be used in read-only mode. * 1 week Finishing the first part with documentation and the testing process. * 2 weeks Implementing specific perms for each individual field allowing to have them in read-only mode, managing correctly the validation of each field. * 1 week Finishing the second part with documentation and the testing process. * 1 week Finishing the GSoC project and making the code stable so it can merged with branch of Django (v1.4). -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
