2011/4/2 Russell Keith-Magee <russ...@keith-magee.com>:
> I think this would be a good way to structure the project -- i.e.,
> keep a clear conceptual separation between hooks and configuration
> options that need to be added to Django in order to make an external
> form rendering library possible, and the library that actually
> exploits those hooks and configuration options.
>
> Alex took a similar approach with the NoSQL work last year -- there is
> a fairly clear separation between the "query refactor" changes, and
> the "MongoDB module" that exploits those changes.
>
> I don't think this needs to change the scope of Gregor's proposal very
> much. If we change the focus to be just on the "Django side", we run
> the risk of architecture astronauting. Developing a non-trivial
> implementation that demonstrates the need for any given refactor helps
> to clarify exactly why any given change to Django's APIs are needed.
>
> Yours,
> Russ Magee %-)
I agree on this. The best practice seems to keep changes outside of django if
possible until proven useful. Which can be done cleanly with the templatetag
at least. I didn't integrate plans on what goes inside django and what will be
outside of it since I didn't know if GSoC projects are accepted that work most
of the time on an app than on django itself. But if thats possible like with
Alex's work last year, thats fine for me.
Let me split up quickly what might go into django directly and what could live
outside if my proposal gets accepted:
1. Layouts
The form layouts should be included in django itself, refactoring
{{ form.as_table }}, labels, errorlists etc to make django code HTML free :-)
2. The template tag
This one clearly goes outside of django. Including a template tag is pretty
easy. Merging this in later would be also a no brainer.
3. Rendering modifiers
Thats also something that will go into an app. It's tight pretty closely to
the template tag. But this might require some internal changes to forms to
support all of the aspects described in the proposal (I don't see any
necessary changes yet, but it's like Russell describes, we don't know what
needs to be done until we have a full featured, non-trivial implementation).
4. Changes to widgets
I could see some additional APIs to widgets that get included into django
directly. Like a clean API to add attributes (instead of modifying attrs
directly), an API to add classes, an API to change the template that is used
to render the widget ...
All thirdparty apps that provide additional form features like
"django-widget-tweaks" would benefit.
5. Admin integration
This is a big point that is difficult to do. Creating a "admin" form layout is
still possible. But using the template tag and its mechanics inside of the
admin might not be useful until the template tag is merged into django.
However we might use the admin just as proof of concept, developing
integration of the app in another branch of django. But thats not ideal IMO.
6. Documentation
Writing documentation is ofcourse straight forward for the stuff that goes
into django directly. The thirdparty stuff will be documented like any other
reusable app. I don't see very big problems there. It might just generate some
extra work merging it in afterwards if the app code is accepted for django
core. But thats really the tiniest problem and acceptable if we can produce a
more mature product.
Gregor
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
