Am 11.07.19 um 19:20 schrieb Robert Schindler:
Sure it is, but I, personally, find it more appealing to have the
functionality as part of the Q object itself, because it operates on a
single Q object as input and returns another one, which makes this an
ideal candidate for an object member
sting, but note that the
prefix() method doesn't need to be a member of the Q class -- it seems
to be just as easy to write an external function to do the same thing:
Sure it is, but I, personally, find it more appealing to have the
functionality as part of the Q object itself, because i
h-a-sub-query can depend on many details --
mostly details of the database engine implementations. If database
engines were ideal, equivalent queries would have equivalent
performance.
More generally: The idea does seem interesting, but note that the
prefix() method doesn't need to be a memb
Hi again,
Am 11.07.19 um 09:54 schrieb Robert Schindler:
> For convenience, I created this module [0], which makes declaring the
> query logic as part of a model's manager really straightforward and also
> provides the well-known API for getting filtered querysets (aka
> Fruit.objects.green()).
Hi Matthew,
Am 11.07.19 um 04:13 schrieb Matthew Pava:
I had a use for such a feature, though I used an implementation more
specific to my application.
Basically, I have a model and then I have several other models that are
directly related to that model. So in the base model I would have a
one field on one model in my project.
From: 'Robert Schindler' via Django developers (Contributions to Django itself)
[mailto:django-developers@googlegroups.com]
Sent: Wednesday, July 10, 2019 2:13 PM
To: Django developers (Contributions to Django itself)
Subject: Prefixing Q Objec
Hi all,
I've been redirected to the mailing list from the ticked I opened [0].
Therein, I proposed to add a new method to the Q object API for prefixing Q
objects with a related field's name in order to be able to create reusable
Q objects.
I think the use case I pointed out might
Contributions to Django itself)
> wrote:
>
>> This is my first message here, and sure enough I'm necromancing this
>> thread from 2016!
>>
>> Below there's a message about how to use Q objects with get_or_create by
>> chaining them. This works! But it'
x27;m necromancing this
> thread from 2016!
>
> Below there's a message about how to use Q objects with get_or_create by
> chaining them. This works! But it's not documented. Is it crazy to document
> this?
>
> I think I used the advice in this thread a while back to
This is my first message here, and sure enough I'm necromancing this thread
from 2016!
Below there's a message about how to use Q objects with get_or_create by
chaining them. This works! But it's not documented. Is it crazy to document
this?
I think I used the advice in this
> So I suppose my question is this - are there any operations that return a
queryset that couldn't be captured in a Q object?
Annotations are a good example of operations that cannot be expressed in a
Q object.
On the ticket I suggested relying on the "sticky filter" feat
Actually - my recollection was faulty. As the queryset method always has to
return a queryset (dur) I am not sure that I'm actually doing anything that
couldn't be expressed as a Q object. I'm just doing some funky stuff to get my
queryset in shape.
So I suppose my question is t
In a few cases I've had to do filtering in Python because it wasn't possible
purely at the db level. (mainly in cases where I'm expected small result sets
obviously). I'd like to see this remain possible with any future changes.
--
You received this message because you are subscribed to the Goo
doesn't hope to address that comprehensively, I do think that some
interesting options come into play when we stop authoring FilterSpecs to
chain filters() and instead return Q-like objects which are then applied by
the ModelAdmin or AdminSite.
-Steve
--
You received this message because yo
It didn't occur to me that it could be done that way. Thanks!
I'm closing the ticket as 'invalid'
On Tuesday, August 16, 2016 at 2:03:02 PM UTC-5, charettes wrote:
>
> Hi Flavio,
>
> Is there a reason we can't document chaining filter() with these method
Hi Flavio,
Is there a reason we can't document chaining filter() with these methods
when
querying with Q() objects?
Person.objects.filter(
Q(first_name='George') | Q(first_name='Bruce')
).get_or_create(defaults={'last_name': 'Harrison'})
If `def
I'm thinking about adding support for `Q` to `get_or_create` and
`update_or_create`. I've summarized my thoughts at
https://code.djangoproject.com/ticket/27070.
I have a couple of unsolved question; the most critical is the one Tim
raises: if we were to add another keyword argumen
lumn that
> is
> > called "field_dttxt" that is to_char(field, 'Mon DD, '). Then add
> this
> > as a field to Django and let it use the normal Q lookups.
> >
>
> Why would you need to create a view? Can't you use a Transform?
>
--
Y
On Tuesday 29 March 2016 05:07:14 Stephen J. Butler wrote:
> Why not do this in the database? Create a view with an extra column that is
> called "field_dttxt" that is to_char(field, 'Mon DD, '). Then add this
> as a field to Django and let it use the normal Q lo
Why not do this in the database? Create a view with an extra column that is
called "field_dttxt" that is to_char(field, 'Mon DD, '). Then add this
as a field to Django and let it use the normal Q lookups.
On Mon, Mar 28, 2016 at 5:13 PM, Michael E wrote:
> I don
tackoverflow.com/questions/36191609/how-can-i-filter-django-datefield-using-a-string>
> to
> understand why)
>
> If there was an option on a Q filter like this:
>
> Q(field__icontains="data", *T**ypeCheck=False*)
> ^^
erstand why)
If there was an option on a Q filter like this:
Q(field__icontains="data", *T**ypeCheck=False*)
^^
(instructing Django to bypass type checking for this field)
it would then be possible to do *datatype conversion
implemented predicate test like functionality for Q objects.
>
> https://code.djangoproject.com/ticket/18931
>
> In brief, this lets you define a condition in a Q object and then test
> whether a model instance matches the condition.
>
> I believe this to be a relatively com
I've implemented predicate test like functionality for Q objects.
https://code.djangoproject.com/ticket/18931
In brief, this lets you define a condition in a Q object and then test
whether a model instance matches the condition.
I believe this to be a relatively complete patch, and
On Tue, Oct 4, 2011 at 4:35 AM, Johannes Dollinger
wrote:
> as you could write Q(foo=Q(...)) instead of Q(..).push('foo')
I thought that would work magically, since the Q object would just
pass that to the filter(); but a quick test proved me wrong.
I've just refactored
tion and
an instance method on tree.Node that just calls it.
> While I'm not sold on the method name (perhaps prefix() or shift() or even
> __rshift__() would be clearer), I believe the ability to modify Q objects
> outside of filter()-Expressions is important.
__rshift__() is too C++ fo
Am 03.10.2011 um 20:01 schrieb Javier Guerra Giraldez:
> On Fri, Sep 30, 2011 at 4:37 PM, Johannes Dollinger
> wrote:
>> The aim of this proposal is to reuse Q objects for models that are related
>> through FK or M2M fields.
>
> i really want to have this feature! s
On Fri, Sep 30, 2011 at 4:37 PM, Johannes Dollinger
wrote:
> The aim of this proposal is to reuse Q objects for models that are related
> through FK or M2M fields.
i really want to have this feature! so i went and did a quick
implementation and created ticket #16979[1]
[1]
On Fri, Sep 30, 2011 at 5:37 PM, Johannes Dollinger
wrote:
> The aim of this proposal is to reuse Q objects for models that are related
> through FK or M2M fields.
> A simplified example would be a Q object like
>
> >>> is_blue = Q(blue=True)
> >>> Th
The aim of this proposal is to reuse Q objects for models that are related
through FK or M2M fields.
A simplified example would be a Q object like
>>> is_blue = Q(blue=True)
>>> Thing.objects.filter(is_blue)
that should be reused to filter th
ib.quote::
>
> _phone_chars = {'a': '2', 'b': '2', 'c': '2', 'd': '3', 'e': '3',
> 'f': '3', 'g': '4', 'h': '4', &#
ly want to be fast, you can do the following, a la urllib.quote::
>
> _phone_chars = {'a': '2', 'b': '2', 'c': '2', 'd': '3', 'e': '3',
> 'f': '3', &#x
'e': '3',
'f': '3',
'g': '4',
'h': '4',
'i': '4',
'j': '5',
'k': '5',
'l': '5',
&
If you really want to be fast, you can do the following, a la urllib.quote::
_phone_chars = {'a': '2', 'b': '2', 'c': '2', 'd': '3', 'e': '3',
'f': '3', '
#x27;e': '3',
'f': '3', 'g': '4', 'h': '4', 'i': '4', 'j': '5', 'k': '5', 'l': '5',
'm': '6', 'n&#x
I've opened a ticket and submitted a patch that fixes this strange
oversight: http://code.djangoproject.com/ticket/12613
Thanks!
- Gabriel
On Jan 14, 5:05 am, Harro wrote:
> hmm that's indeed weird. The regex excludes those as well
> specifically.
> The Q and Z should be
hmm that's indeed weird. The regex excludes those as well
specifically.
The Q and Z should be added or a comment should be added to the code
explaining the reason for leaving them out.
On Jan 14, 11:23 am, Gabriel Hurley wrote:
> 1. Is there a reason Django's phone2numeric method
2010/1/14 Gabriel Hurley :
> 2. I was also wondering if there's a reason that the dictionary of
> numbers/letters used in that function is in such a seemingly random
> order... is there some brilliant logic behind it?
Yes, there is. Someone probably copy&pasted it from python's output,
so they're i
1. Is there a reason Django's phone2numeric method doesn't work for
the letters Q or Z? I realize that those two letters are the ones that
share four letters to a number instead of the standard three, but
that's no reason to leave them out. Most modern phones include the
full al
On Thu, 2009-04-09 at 20:48 -0700, jameslon...@gmail.com wrote:
> I have a dynamically generated search form which constructs Q()
> objects at runtime. This works brilliantly in almost every case. There
> is a particular combination of these objects which appears to create
> an extra
I have a dynamically generated search form which constructs Q()
objects at runtime. This works brilliantly in almost every case. There
is a particular combination of these objects which appears to create
an extra where clause though. Currently this isn't killing me because
the clause is sim
lement of filter. This did not work
> > in 0.96 but works now, which is great.
> > I don't think however that it is a good idea to let filter(~Q()) mean
> > 'not exists', i.e. be equivalent to 'exclude', for multi valued
> > relations, while it mean
On Fri, 2008-07-18 at 04:11 -0700, Göran Åström wrote:
> Thank you for answering and for the workaround tip.
> I agree, exclude should be the complement of filter. This did not work
> in 0.96 but works now, which is great.
> I don't think however that it is a good idea to let
Thank you for answering and for the workaround tip.
I agree, exclude should be the complement of filter. This did not work
in 0.96 but works now, which is great.
I don't think however that it is a good idea to let filter(~Q()) mean
'not exists', i.e. be equivalent to 'exclud
ining an entry that matches the condition
(since the filter() version would be those blogs containing an entry
that match the condition). Thus exclude() and filter() are opposites.
Since (a) writing your own Q-like object is possible and not
particularly hard and (b) nested queries are more or less
;or' are.
In my opinion number 3 which is a 'not exists' merits its own operator
e.q -Q(). This would also make it possible to custruct a filter like:
Give me blogs without entries not matching a criteria.
Thanks for a great system!
Regards,
Göran
On Jul 17, 2:53 am, Malcolm Tredinnick
>> Blog.objects.filter(name="myblog").exclude(entry__body_text__contains="blah
> >> blah")
> >> Blog.objects.filter(Q(name="myblog") &
> >> QNot(Q(entry__body_text__contains="blah blah"))) # 0.96
> >> Blog.object
Malcolm Tredinnick wrote:
>
> On Wed, 2008-07-16 at 10:12 -0700, serbaut wrote:
>> Consider the following equivalent queries based on the weblog model
>> from the documentation:
>>
>> Blog.objects.filter(name="myblog").exclude(entry__body_text__contains=
different filter
>
> The filter is dynamically built by the gui so writing custom sql is
> not an option and as I understand it we cant do what we want with a
> filter query as it is. Right now the best solution may be to add a Q
> operator that works like the old QNot.
Yo
relying on indices will not work.
> Then write custom SQL. Or write a different filter
The filter is dynamically built by the gui so writing custom sql is
not an option and as I understand it we cant do what we want with a
filter query as it is. Right now the best solution may be to add a Q
opera
On Wed, 2008-07-16 at 10:46 -0700, serbaut wrote:
> There is no m2m relation involved in the example.
Yes, you're right. It's not many-to-many, but it is multi-valued. It's a
reverse many-to-one, which means one blog maps to many entries. The
logic for the query construction still stands.
[...]
Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Wed, 2008-07-16 at 10:12 -0700, serbaut wrote:
> > Consider the following equivalent queries based on the weblog model
> > from the documentation:
>
> > Blog.objects.filter(name="myblog").exclude(entry__body_text__contains=&q
On Wed, 2008-07-16 at 10:12 -0700, serbaut wrote:
> Consider the following equivalent queries based on the weblog model
> from the documentation:
>
> Blog.objects.filter(name="myblog").exclude(entry__body_text__contains="blah
> blah")
> Blog.obje
Consider the following equivalent queries based on the weblog model
from the documentation:
Blog.objects.filter(name="myblog").exclude(entry__body_text__contains="blah
blah")
Blog.objects.filter(Q(name="myblog") &
QNot(Q(entry__body_text__contains="blah bla
I've been a while trying to implement full-text search under
PostgreSQL, I created some code that works, but is not optimal.
I asked Malcolm Tredinnick and he told me:
"In fact, thinking about this a bit more, it might even be possible to
do
it all via a custom Q-like object. You migh
On 11/27/07, yopi <[EMAIL PROTECTED]> wrote:
> Just bringing attention to this new ticket which affects the database
> wrapper component
Thanks.
For future reference, note that all the core developers automatically
get emailed (via the django-updates group) any time tickets are filed
in Trac. Th
Just bringing attention to this new ticket which affects the database
wrapper component
--~--~-~--~~~---~--~~
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
Added a few tests and docs - not sure how good they are, but better
than nothing :)
--~--~-~--~~~---~--~~
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@g
On 7/13/07, Nick <[EMAIL PROTECTED]> wrote:
>
> On Jul 13, 8:36 am, Collin Grady <[EMAIL PROTECTED]> wrote:
> > As such, the following patch was born, allowing ~q instead of
> > QNot(q) :)
> >
> > http://code.djangoproject.com/ticket/4858
>
>
On Jul 13, 8:36 am, Collin Grady <[EMAIL PROTECTED]> wrote:
> Simon requested I bring this up here - I was working through a problem
> with a user on IRC, and he noted that Q objects support the bitwise &
> and |, but not ~ - if you wanted to negate a Q object, you had to
Simon requested I bring this up here - I was working through a problem
with a user on IRC, and he noted that Q objects support the bitwise &
and |, but not ~ - if you wanted to negate a Q object, you had to
explicitly import QNot and use that instead.
As such, the following patch was
though with the where clauses the way they are, I think the LEFT
OUTER JOINs patch I submitted WILL work, just not as well as it
could.)
-Mike
On Feb 26, 5:18 pm, "Mike Axiak" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Recently I've been working extensively with Q objec
On 2/27/07, Mike Axiak <[EMAIL PROTECTED]> wrote:
>
> Anyway, I'm about to overload the Q object. In this new object, Q' (i
> still haven't got a good name for it), will look up the tree (or down)
> for any ORs, and switch the join type from 'INNER JO
Hello,
Recently I've been working extensively with Q objects (that is, I've
been doing some cool things to have a user automatically create a new
set with arbitrary set combinations). Anyway, a lot of the
combinations will not work without some hackery. The reason? Q Objects
will (int
I am working on a Django project (using the latest dev version, as of a
few days ago) in which I use Q objects quite a bit to build up queries
dynamically. I like that the binary & and | operators are overloaded
to AND and OR queries together with QAnd and QOr, but I was surprised
that
the test cases for the new changes, so it will be fixed).
>
Is there a page or ticket discussing the larger change?
I've several times lately wished for a couple edge-case Q objects.
--~--~-~--~~~---~--~~
You received this message because you are subscribe
On Sat, 2006-10-14 at 03:27 +, afarnham wrote:
> Ok, so I looked at the SQL and it is a huge statement. Once I work out
> what it is doing I may post it here. However, I may just go with a
> straight sql query here and bypass the ORM until these new changes are
> implemented. Any idea of a tim
Ok, so I looked at the SQL and it is a huge statement. Once I work out
what it is doing I may post it here. However, I may just go with a
straight sql query here and bypass the ORM until these new changes are
implemented. Any idea of a time frame on when those will be up for
testing? I will be hap
On Fri, 2006-10-13 at 20:04 +, afarnham wrote:
> Hi all,
>
> I am having trouble with a Q object look up in one of my apps. When I
> execute the following:
>
> Tag.objects.filter(Q(card__owner = u)|Q(usercardmeta__user = u))
>
> an empty queryset is returned. The
Hi all,
I am having trouble with a Q object look up in one of my apps. When I
execute the following:
Tag.objects.filter(Q(card__owner = u)|Q(usercardmeta__user = u))
an empty queryset is returned. The filtered QuerySet should be
returning this list:
[, , , ]
After stepping through and
Ian Holsman wrote:
> all of these types of things should get as much info as possible out
> of the database/models that exist
> having to retype the relationships sounds yuko to me.
>
> but hey... I'm not a ruby guy.. maybe they like doing these kind of
> things.
This is a limitation of support
On 3/5/06, kmh <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee wrote:
> > We could get really carried away here, but I'm not sure if there is
> > any gain. The problem you are describing has existed since pre-MR days
> > (and can be seen living large in the unit tests), and while it is an
> > i
Russell Keith-Magee wrote:
> On 3/3/06, kmh <[EMAIL PROTECTED] > wrote:
> >
> > My concern is that you end up with this:
> >
> > book.authors = [author1, author2]
> > book.authors == [author1, author2] # not true
>
> Well, if we want to get picky like that, then book.authors should
> evaluate as
On 3/3/06, kmh <[EMAIL PROTECTED] > wrote:
>
> My concern is that you end up with this:
>
> book.authors = [author1, author2]
> book.authors == [author1, author2] # not true
Well, if we want to get picky like that, then book.authors should
evaluate as a set as well, unless an order_by has been
Russell Keith-Magee wrote:
> On 3/3/06, kmh <[EMAIL PROTECTED]> wrote:
> >
> >
> > If it were a 'set' method assignment would not be possible and an
> > exception hinting to use 'set' would be raised.
>
>
> (Damn English language... setting the set with a set...)
>
> If I am understanding you corr
On 3/3/06, kmh <[EMAIL PROTECTED]> wrote:
If it were a 'set' method assignment would not be possible and anexception hinting to use 'set' would be raised. (Damn English language... setting the set with a set...)If I am understanding you correctly, you are opposed to having assignment notation for
Russell Keith-Magee wrote:
> On 3/3/06, kmh <[EMAIL PROTECTED]> wrote:
>
> > Assigning a list implies assigning an order. How about:
>
>
> book.authors.set([author1, author2])
>
>
> This doesn't address the problem - what is the 'set' behaviour of the
> descriptor protocol.
>The start of the expre
On 3/3/06, kmh <[EMAIL PROTECTED]> wrote:
Assigning a list implies assigning an order. How about:book.authors.set([author1, author2])
This doesn't address the problem - what is the 'set' behaviour of the descriptor protocol. The start of the _expression_ has to be 'book.authors ='; the question is
Russell Keith-Magee wrote:
> I can see the merit in finishing the descriptor protocol
> for all m2m objects. So:
>
> book.authors = [author1, author2]
> would be equivalent to
> book.author.clear(); book.author.add(author1, author2)
Assigning a list implies assigning an order. How about:
book.au
On 3/3/06, Luke Plant <[EMAIL PROTECTED]> wrote:
fields. For ManyToMany, you do: book.author.add(author1, author2...)I guess it would be good if the __set__ descriptor was there, and eitherdid the right thing or threw some exception.
I've been working with the descriptor protocol on RelatedManage
On Thursday 02 March 2006 04:49, xamdam wrote:
> class Book(models.Model):
> name = models.CharField(maxlength=200)
> author = models.ManyToManyField(Person)
> def set_author(self, a): self.author = a # is this (having to
> define the set_ method) fixed yet?
> def __repr__(self):
I am playing with a class like this:
class Book(models.Model):
name = models.CharField(maxlength=200)
author = models.ManyToManyField(Person)
def set_author(self, a): self.author = a # is this (having to
define the set_ method) fixed yet?
def __repr__(self):
return self.na
Hi
I have been thinking about doing something like this, and it seems you
probably would have to use the new save() method. However you would
still need a model for each history table. Although I was toying with a
genric history table (more akin to a log) where you could then easly
code it up onc
hi.
So I have my tagging and auditing application on the current trunk,
and they service their purpose well.
but I'd like to know the 'best' way to rewrite this in the magic-removal trunk.
when magic removal was first proposed it mentioned that these kind of
things would be much easier.
so.. h
Russell Keith-Magee wrote:
> I have a need - or, at least, larger plans for a need.
>
> Short version - don't just think about instances of Q() itself. You can also
> use any objects descendent from, or objects that meet the Q() intereface.
> This allows the end user to
On 1/30/06, Luke Plant <[EMAIL PROTECTED]> wrote:
Yeah, I think you're right, I'm just aware that other people might beusing the Q() syntax already and have some use cases for it that I'munaware of. I haven't used it myself, and working on the setsthemselves seems fine
On Monday 30 January 2006 18:56, Luke Plant wrote:
> Actually, Q()s are immutable, so doing a deepcopy on their account
> was a complete mistake on my part. You don't have to copy them at
> all, which would make them rather nice to use performance-wise.
In which case, and assumin
On Monday 30 January 2006 16:11, Adrian Holovaty wrote:
> ... I prefer avoiding copy.deepcopy() --
> which had been necessary in QuerySet._clone() due to the fact that we
> were using Q() instances. That meant each call to _clone() (for
> filter(), order_by(), etc.) was doing deepc
On 1/30/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> One thing - should _clone() actually do call
> 'self.__class__()' (or something like that), rather than QuerySet()?
> Otherwise you lose any subclass behaviour, which I don't think is
> desirable.
Good call -- yes, it should. Of course, if self.
Adrian wrote:
> It seemed a bit YAGNI to me, and I prefer avoiding copy.deepcopy() --
> which had been necessary in QuerySet._clone() due to the fact that we
> were using Q() instances. That meant each call to _clone() (for
> filter(), order_by(), etc.) was doing deepcopy(), which m
On 1/30/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> In the new descriptor syntax, are we going to allow Q() objects as
> positional arguments to the filter() method (and others)?
> [...]
> I mention this because I see you've changed core_filters back to a
> dictionary o
Robert Wittams wrote:
> Couldn't you just pass a model class or manager into your function that
> generates the appropriate queryset from that? Seems like an esoteric
> need anyway.
Yeah, I think you're right, I'm just aware that other people might be
using the Q() synt
Luke Plant wrote:
> In the new descriptor syntax, are we going to allow Q() objects as
> positional arguments to the filter() method (and others)? They seem
> like they could be a useful way of creating queries, although there is
> some duplication now that you can combine QueryS
In the new descriptor syntax, are we going to allow Q() objects as
positional arguments to the filter() method (and others)? They seem
like they could be a useful way of creating queries, although there is
some duplication now that you can combine QuerySets directly. However,
passing QuerySets
On 12/16/05, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Now that you mention it, I think "Admin" and "Meta" look better,
> though...
I've changed "class META" to "class Meta" in the magic-removal branch.
The former is no longer accepted. I figure since this will be such a
big change, we migh
On 16 Dec 2005, at 21:09, Jacob Kaplan-Moss wrote:
Now that you mention it, I think "Admin" and "Meta" look better,
though...
+1. They're much prettier and improve code readability (a tiny bit)
as well.
On Dec 16, 2005, at 2:01 PM, Robert Wittams wrote:
Brant Harris wrote:
However, Why do they have to be all caps? "class Admin" and "class
Meta", seem nicer.
I think so too. It would be easy enough to make it accept both.
I always think capitals are constants, or I'm using something scary
l
Brant Harris wrote:
> On 12/15/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
>
>>Basically, promote Admin settings to a full inner class, rather than
>>nesting it in meta. It would still end up in meta though.
>>
>>Thoughts?
>
>
> +1
>
> Just last night I was making a new model, and thinking t
Robert Wittams wrote:
>That would be even wierder in my opinion, as the Manager:
>a) is not required
>b) is orthogonal to the admin
Fair enough. I guess what I was looking for was an ADMIN class that is
closer to a manipulator (and if so I think it is inflexible to assume
there should only ever b
On 12/15/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> Basically, promote Admin settings to a full inner class, rather than
> nesting it in meta. It would still end up in meta though.
>
> Thoughts?
+1
Just last night I was making a new model, and thinking that this should be done.
However, Wh
1 - 100 of 107 matches
Mail list logo
