On Thu, Apr 7, 2011 at 5:04 PM, igalarzab <[email protected]> wrote: > [GSoC Proposal] Read-only forms and DataBrowse > ==============================================
> > 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). What you're proposing here is quite different from what the GSoC wiki proposes. The wiki refers to about adding read permissions to the admin, and providing browsing capability for data within the admin. Your proposal is to add read-only widgets -- a feature that the admin already has, and has been historically rejected as part of the core forms library. If you're going to propose a project that has historically been rejected, you may want to provide some counterargument to the reasons it has been historically rejected. Ideally, this discussion should have started several weeks ago, so you could demonstrate that there is now community acceptance for the idea you are proposing. > 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). This is also a red flag for me. Research and design is what you do *before* you apply, not something that takes up 1/6 of the allotted time for the GSoC. If you haven't done any research and design, how can you have any confidence that your work estimates for the rest of the project are even remotely accurate? In short -- this doesn't seem like a particularly viable proposal in it's current form. Yours, Russ Magee %-) -- 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.
