On Thu, Feb 27, 2014 at 7:04 AM, Nikolay Baluk <[email protected]> wrote:
> > Hi, I'm Nick and I don't want to feel myself when I call obj._meta as if I > am committing a mortal sin. > > > I thought that refactoring Meta objects and make it usable is a promising > contribution for the community, because there are a lot of situation when > accessing _meta attributes and methods can save a lot of developers time: > you can find hundreds real-life examples on Stackoverflow.com where people > use _meta, but make a remark that it's private, not recommended to use in > general and should be covered with unit tests (yeah, that's great, but not > when you had to cover framework's code). It also may be useful for those > who chose to encapsulate their business logic in a "fat" models instead of > views (can't imagine such use case of meta right now) since I think it's a > really good way to architect Django's apps. > > As for me, I'm currently using Django-nonrel and, for example, I had to > survive without multi table inheritance, so I really need to know many > information about model classes and instances that is available but like > forbidden fruit. It's time to change that! :) > > > Many of those for whom the Django is made are think: if it is written in > the documentation -- then it can and should be used. If not -- don't even > touch this. That's the first reason why documenting Meta is the most > responsible task. Second is that documentation (and the api itself, of > course) should warn the user against destructive use of the object's > interior. > > So, I'm as non-native English speaker, may seem at first glance not the > best candidate for this, but I will put a lot of effort to find the best > person for review of what I will write and the Django's docs writing style > looks very laconic. > > I am a little scared to work under hood of Django, but more challenging -- > is more interesting. > Any help with this project would be greatly appreciated! > > > *Brief plan:* > > > 1. Learn what actually supposed to be opened. > I mean we have a few options. We can make stable and expose the whole > obj._meta; we can make stable obj._meta, document it as well, but point > some things which are really necessary for developers to obj.meta since > it's sound more comfortable to use and bonus points for backwards > compatibility if any issues will appear. > > 2. Have fun while exploring Django so deeply (Options class and other meta > related code). > > 3. Clean up related classes. > > 4. Write some unit tests that supposed to be self-documented my point of > view on how API should looks like consequently. Ask Russell Keith-Magee (as > my mentor) for master class about how API actually should looks like. > > 5. Do what developers usually do. Write brilliant clean code. > > 6. Cover all that with docs and examples. > > 7. Make sure that all is meets the requirements of Django standards. > Hi Nikolay Glad to see you're interested in hitting a difficult problem like cleaning up Meta! It sounds like you've got the broad idea of what is required for this project; however, a successful project application will need a little more detail than this. Specifically, we're looking for a timeline (in blocks of about a week, and no more than 2 weeks) detailing what you're going to do over the 12 week program. We ask for this for two reasons: Firstly, in order to provide a detailed timeline, you need to fully understand the problem. It's not enough to just say "6 weeks: Fix the problems; 6 weeks: document the result". We're looking for a detailed teardown of specific activities. In order to provide this sort of timeline, you need to study the problem enough to identify specific coding/refactoring activities. Secondly, it gives us a mechanism to measure your progress. If, after 3 weeks, you still haven't finished the work allocated for week 1, we can guess you're not going to finish. However, if you've finished 6 weeks of work in 3 weeks, we know we'll need to find something else to fill your summer :-) Since this is a refactoring and documentation project, I'd also suggest that it might be helpful to have an independent way of evaluating success. Since you're experienced with Django-nonrel, this provides a potentially interesting option. One of the reasons for documenting Meta is to guarantee the interface it provides. The Meta interface exists to allow introspection, which is then used by ModelForms and Admin to provide automated (or semi-automated) interfaces. So - as a proof of concept that your refactoring works, you might commit to producing a wrapper for django-nonrel (or, to keep it simpler - a single nonrel data store) that is sufficiently "Meta-compliant" that it can be displayed in admin, and be displayed/edited in a ModelForm. To be clear - this isn't about adding Nonrel support to Django's core -- it's about proving that as a result of your refactor and documentation, Django provides the tools to allow external tools to interact with Django's internals as first-class citizens. Third party projects like Django-nonrel could then exploit this documented interface to provide fully-fledged Django support. Your project would require you to discover and document all the interfaces that are needed to prove that it can be done; having a concrete goal might make it easier to direct your activities. I hope that feedback is helpful. If you have any other questions, don't hesitate to ask! Best of luck with your GSoC application! Yours, Russ Magee %-) -- 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 [email protected]. To post to this group, send email to [email protected]. 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/CAJxq84-gUN55VNBQKFWqPW-TvSA2NC%3DbP2b1wWQ-SctncFzvZw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
