On Wed, Jul 14, 2010 at 3:55 AM, Carl Meyer <carl.j.me...@gmail.com> wrote: > Hi Russ, > > On Jul 13, 12:11 pm, Russell Keith-Magee <russ...@keith-magee.com> > wrote: >> My concern about doing this entirely in templates is that it makes the >> process of sharing a widget library a little more difficult. If it's >> just code, then it just needs to be in the PYTHONPATH. If there are >> templates too, then the templates need to be somewhere that they can >> be accessed. > > So I think this is very much a programmer's perspective, almost > humorously so :-) "Just code" may seem easy to you, but from the > perspective of at least one experienced Django-template designer I've > talked to, being able to do it entirely in templates makes the idea of > sharing a widget library conceivable, as opposed to almost impossibly > intimidating if its "just code."
By "just code", I don't mean "code is easy", I meant "code, and nothing else". Anything you can do in template you can also do in code. The same is not true the other way around. I'll concede that the intended audience may not see code as an easy option, but that doesn't change the fact that code offers solutions that aren't otherwise available. > The app_directories template loader is installed by default. Getting > templates "somewhere they can be accessed" means creating a directory > on the PYTHONPATH with an empty models.py, an empty __init__.py, and a > "templates/" subdirectory, then putting that in INSTALLED_APPS. That's > it. How is that harder than following exactly the same steps for an > app that includes Python code? From the perspective of a non- > programmer, it's much easier. Fair point. > The key issue is familiarity and ease-of-use. For template authors, > not programmers. Template authors know perfectly well how to add > classes and attributes to HTML elements. Why should they have to use a > special API to do the same thing for form input elements? Again: if > the goal is for Django template authors to create an ecosystem of > reusable widgets, the system needs to be geared around the tools they > are comfortable with, not the ones programmers are comfortable with. > That means templates. And not Python code. Ok. I can certainly see that a template-based solution is the popular solution, especially amongst designers. I still have some reservations, but they're almost entirely about technical feasibility and complexity of representation, not about desirability. Part of the problem is that we've spent a lot of time talking about the template tag/filter, but almost none on what the templates would look like, and how the multiple layers of templates will knit together. Here's my first cut at a list of the use cases we need to support: We need to be able to define templates for: a) The layout for a single widget (e.g., a DateWidget) b) The layout for a single row of a form c) The layout for an entire form (top errors, fields, hidden fields) in as_* style. In each of these templates, (b) will need to render instances of (a), and (c) will need to render multiple instances of (b) -- and not necessarily the same instances, either. Each of templates could be applied: 1) As a background system default - what you get if you don't override anything 2) As a specified default for the entire rendered page 3) As a specified default for a single form on a page 4) As a specified override for a field on a form (a/b) or a form as a whole (c) There's also the issue of doctypes; If I have a document that is html4 document, I need to ensure I only get html4 snippets; ideally without having to specify html4 every time I use a snippet. If anybody has any other use cases or points worth considering, please speak up. I'd like to spend a couple of days digesting what's been said in this thread; I also want to look at some existing template-based projects (like django-form-utils), and play around with a couple of ideas that are lurking in the back of my brain. Hopefully, I'll be back in a week or so with a revised proposal. 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 django-develop...@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.
