On 2/14/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
This change, at a glance, looks good. Go ahead and commit it.Ok. Will do.
cached vs. non-cached query sets. The way it's currently handled inmagic-removal is great, and a fine improvement. Let's move forward. If this is the will of the gods, i
Robert Wittams wrote:
> Adrian Holovaty wrote:
> >
> > This change, at a glance, looks good. Go ahead and commit it.
> >
> > As for renaming all() to cached() and/or making SomeModel.objects a
> > QuerySet directly and having to deal with cached vs. non-cached query
> > sets -- we've already had t
Adrian Holovaty wrote:
This change, at a glance, looks good. Go ahead and commit it.
As for renaming all() to cached() and/or making SomeModel.objects a
QuerySet directly and having to deal with cached vs. non-cached query
sets -- we've already had this discussion, decided on it and moved on.
Hi. I have a situation where I store a pickle in a field that I'd like
to unpickle for an update form and on save pickle again. What would be
the best approach for this scenario given the current or future
possibilities of admin customization.
Regards,
David
Jacob Kaplan-Moss wrote:
On F
On Monday 13 February 2006 19:44, Luke Plant wrote:
> The attached patch does so - the .all() call is now optional on
> related objects (it's still there due to inheritance, but I've fixed
> it so it does the right thing).
I listened to the code a bit more carefully, and couldn't let this lie -
On Feb 13, 2006, at 12:05 PM, Joseph Kocherhans wrote:
Another option (although I'm not sure that I like it) is to allow
either style. The tuple would use the template lookup described in
Jabob's first email, and the dict would of course allow you to supply
*any* template path. It's more flexibl
On Monday 13 February 2006 18:52, Luke Plant wrote:
> And there isn't a technical reason for it either - it should be
> relatively easy to make it go away.
The attached patch does so - the .all() call is now optional on related
objects (it's still there due to inheritance, but I've fixed it so i
On Monday 13 February 2006 17:29, Adrian Holovaty wrote:
> As for renaming all() to cached() and/or making SomeModel.objects a
> QuerySet directly and having to deal with cached vs. non-cached query
> sets -- we've already had this discussion, decided on it and moved
> on. It's SomeModel.objects.
On 2/13/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 2/13/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> > How about this syntax::
> >
> > class Admin:
> > custom_templates = {
> > 'field_name1' : 'widget/template_name1',
> >
On Feb 13, 2006, at 11:57 AM, Adrian Holovaty wrote:
Seems a bit boilerplatish, compared to a simple list of field names,
but the advantage of this would be that you could easily reuse
widget-specific templates. On the other hand, you could reuse
widget-specific templates with the field-name lis
On 2/13/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> How about this syntax::
>
> class Admin:
> custom_templates = {
> 'field_name1' : 'widget/template_name1',
> 'field_name2' : 'widget/template_name2',
>
On Feb 13, 2006, at 11:22 AM, Adrian Holovaty wrote:
I strongly object to this, because that means for *each widget on your
admin form* it's going to hit the filesystem for *all of those* files.
So if your admin form has 10 fields (average), and none of them has a
custom field widget (average),
Adrian Holovaty a écrit :
>Instead of this hook, how about just using the existing JavaScript
>hook? Either that, or we can add declarative syntax to the 'class
>Admin' like so:
>
>class Admin:
>use_custom_templates = ('field_name1', 'field_name2')
>
>Adrian
>
>
Hi i'm nobody.
I'd j
On 2/13/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 2/13/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> > Right now admin widgets use templates named ``widget/
> > ``. I'd like the change this to be similar to the
> > change form templates and look for templates in this order::
> >
On 2/11/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> Now that the dust has settled on the descriptor work, I've turned back
> to bulk delete.
>
> I've attached a new patch to the original ticket -
> http://code.djangoproject.com/ticket/1219 - which is updated to
> reflect the descriptor ch
On 2/13/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Right now admin widgets use templates named ``widget/
> ``. I'd like the change this to be similar to the
> change form templates and look for templates in this order::
>
> * admin///widget/
> * admin///widget/
> *
On 2/13/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> Right now (thanks to Robert's awesome admin work a few months ago)
> you can easily make a custom template for an admin change form. I've
> found at times that this is too heavyweight for me since often all I
> want to do is override th
Hey folks --
Right now (thanks to Robert's awesome admin work a few months ago)
you can easily make a custom template for an admin change form. I've
found at times that this is too heavyweight for me since often all I
want to do is override the display of a specific field. For example:
Russell Keith-Magee wrote:
I was assuming that cached() would _always_ clone. If the source
QuerySet is non-cached, you get a clone with caching enabled; if the
source is cached, you get a new QuerySet with a clean cache. The use
case I can see is:
p = Article.objects.filter(...) # Original, un
While all the cache talk is interesting and important, it is somewhat
separate from the original purpose of this thread: critique of the
bulk delete patch.
So far, the only criticism seems to revolve around the significance of
all(), and exactly how the cache works/should work. However, bulk
dele
On 2/13/06, Robert Wittams <[EMAIL PROTECTED]> wrote:
> Yes, this is exactly what I intended to convey... sorry if I didn't make
> myself clear...
It might take me few attempts to get the point, but as long as we all
end up on the same page... :-)
> > - q = Article.objects.filter(...).cached();
Lately i prefer textile/markdown over WYSIWYG, my experience is that
WYSIWYG is too
often too sloppy for good using with existing CSS / styling. Most ppl
tend to copy & paste stuff into rich text editors and trying to filter
that stuff is a nightmare. Try filtering word documents pasted as HTM
Hi.
I was wanting to know what other people thought about TinyMCE and
other javascript WYSIWYG editors which enable people to enter in raw
html.
do people in general let the unwashed masses use them on their sites?
(and then attempt to filter it)
or do they resort to textile/bbcode/markdown and s
Russell Keith-Magee wrote:
However, rather than having cached() as a factory/proxy method on the
manager, wouldn't a better approach be to make cached() a 'cache enabling'
clone method on QuerySet?
Er, yeah. That was kind of assumed. I'm still working from the
assumption that we want to make
24 matches
Mail list logo
