Re: Feature proposal: Test client form value extraction

[Joshua Russo]

On Aug 25, 6:09 pm, Joshua Russo  wrote:
> I've just put together an enhancement of the test Client used in unit
> testing. I added the parsing of the content to extract the form fields with
> their initial values as a dictionary, so you can just change a few values
> and throw it back at the server.http://dpaste.com/hold/85281/
>
> I had to do a small monkey patch to get it to work because direct override
> of the __ call __ method interfered with the transaction management for some
> reason.
>
> Let me know what you think. Should I submit it as a ticket?

Here is a basic usage example:

def test_htmlParse(self):

response = self.client.get('/test/')
self.failUnlessEqual(response.status_code, 200, 'Failed to
retrieve the form test page. (1)')

curVals = response.form_values['frmTest']

response = self.client.post('/test/', curVals)
self.failUnlessEqual(response.status_code, 200, 'Failed to
retrieve the form test page. (2)')
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Feature proposal: Test client form value extraction

[Joshua Russo]

I've just put together an enhancement of the test Client used in unit
testing. I added the parsing of the content to extract the form fields with
their initial values as a dictionary, so you can just change a few values
and throw it back at the server.
http://dpaste.com/hold/85281/

I had to do a small monkey patch to get it to work because direct override
of the __ call __ method interfered with the transaction management for some
reason.

Let me know what you think. Should I submit it as a ticket?

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: On returning appropriate subclass instances when querying a model with subclasses

[Alex Gaynor]

On Tue, Aug 25, 2009 at 10:41 AM, Carl Meyer wrote:
>
>
>
> On Aug 23, 9:14 pm, Andrea Zilio  wrote:
>> So the answer to the question "Can I get the right instances with one
>> single and only DB query" seems to be:
>> "No, you cannot do so without touching the Django orm code".
>>
>> Am I right?
>
> Actually, I think the ORM's extensibility mechanisms are sufficient
> that you could provide your QuerySet.select_subclasses() method, which
> would perform a single query with n LEFT JOIN's, with custom QuerySet/
> Query subclasses. Writing it would certainly require a non-trivial
> level of familiarity with the ORM internals, and you might have to use
> private APIs - but I don't think you'd have to modify Django code.
>
> Carl
> >
>

Actually there's already a ticket to cover the ability to do that type
of joining.  Ticket 7270 works to add select_related support to
reverse 1-1 relations, which is all that inheritance is.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: On returning appropriate subclass instances when querying a model with subclasses

[Carl Meyer]

On Aug 23, 9:14 pm, Andrea Zilio  wrote:
> So the answer to the question "Can I get the right instances with one
> single and only DB query" seems to be:
> "No, you cannot do so without touching the Django orm code".
>
> Am I right?

Actually, I think the ORM's extensibility mechanisms are sufficient
that you could provide your QuerySet.select_subclasses() method, which
would perform a single query with n LEFT JOIN's, with custom QuerySet/
Query subclasses. Writing it would certainly require a non-trivial
level of familiarity with the ORM internals, and you might have to use
private APIs - but I don't think you'd have to modify Django code.

Carl
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: I need a pony: Model translations (aka "my proposal")

[David Danier]

Hi Gonzalo,

> [...] sorry for the late answer.

Sorry for my late answer, too.

> I like your proposal! You simplified some over designed or complex
> stuff about my original proposal and added some very neat ideas, good
> work.

Thanks!

>> 4. Special case: Create an own model for translations (like 2), but use
>> the original table for some kind of DEFAULT_LANGUAGE. (pluggable-model-i18n)
>>   I kind of like this, not only because you are able to enhance
>> third-party-apps. Independent from that I think translations.register()
>> seems to be a nice idea. But(!) this complicates things to much. You
>> have to choose whether you want a field out of the DEFAULT_LANGUAGE or
>> not for every field access/query.
> 
> This is the only thing I think deserves a second thought. It might
> complicate thinks a little bit but it's very nice to be able to have
> the model's default language translation loaded without needing the
> JOIN, you don't have to check if its the default language or not, what
> this does it to check if the translation is loaded (cached), defaults
> will allways be loaded and this should be seen as an optimitation for
> the common case .

I thought some time about this when I wrote my original email. Because
of the way I proposed how translations should work I don't see any real
drawback when having to use the JOIN in every query:
 * If you don't use the translations, no JOIN will be done, as the model
is not changed at all (like with pluggable-model-i18n)
 * When using translations you cannot assume, that the language you
first started your project will be used most. I can think of a german
site adding an english translation, which probably will be used most
after some time. If you add even more possible translations the benefit
gets smaller and smaller. When having a site that supports ten languages
you save the JOIN only on 10% of the queries (normal distribution). Not
all scenarios allow you to choose the "right" language as a default.
 * I see this similar to using model inheritance. If I need it, I have
to live with a (little) overhead. Trying to put optimization in here,
which might not even be really useful in all cases, is not a great idea
I think.

> If users have all models translations configured using
> DEFAULT_LANGUAGE as default language and this matches the most used
> lang (as it should) the content i18n overhead won't be that big most
> of the time, this is very important. Also It could optionally be used
> as an efficient fallback for missing traslations (a very common
> configuration).

The language fallback is one of the point I don't have a nice solution
for so far. But I don't think having one DEFAULT_LANGUAGE as the
fallback language is enough.

Think about some german site for example. What this site could do is add
an english translation (most common step for non-english sites, as
english really increases the potential userbase). Now after a while
the same site might want to add a spanish translation. As some content
is still only available in german this site might want to use a
multi-level fallback for their spanish version: spanish -> english ->
german (aka "spanish falls back to english, english falls back to german").

Other sites may not even need a fallback, for example when only listing
contents that fit the user language (objects that have no translation
get filtered out) or only having translated fields that are not
mandatory (objects that have no translation get None for every
translated field).

All these reasons did drive me to the conclusion that we can support
users when needing some fallback, but we may not be able to provide a
solution that works for all use cases. Because of this I dismissed the
idea of using a DEFAULT_LANGUAGE, which is used for this only because
its already in the result of the SQL-query.

> I look forward to hearing more ideas and continue this discussion here
> and on IRC and since I will have more free time to work on this now, I
> will start to study some django internals and take out the useful
> stuff from pluggable-model-i18n.

One thing I'm not sure about how to do is tracking different versions of
the translations. A very common scenario is to have an object with some
translations. If you update the objects itself (including one default
translation) all other translations of the model get marked as outdated.
This way you can track whenever an update to some translation is needed.

pluggable-model-i18n could easily solve this by just using some
modified-field in the base-model and all translations. To decide whether
your translation is outdated you only need to compare its modified-field
with the one of the base object. Having two tables this is not as easy,
because you don't have a base translation. You could of course just mark
the first translation as "is_base=True".

Anyway I'm not sure if this deserves to much attention. When writing my
proposal the idea was to implement translation.ModelTranslation (see
idea.txt) 

localization, i18n, localflavor

[hinnack]

Hi,

I wonder where to put/get country specific information on:
- money sign (printable and iso)
- money format
- number format
- date format
- timezones

maybe even:
- country names in local language

I did not find something about it anywhere in django itself - there
are some modules out there dealing with one or the
other point - but I think it should belong to localflavor

-- Hinnack

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: USStateField (again)

[Russell Keith-Magee]

On Tue, Aug 25, 2009 at 11:08 AM,
ch...@moffitts.net wrote:
>
>
>
> On Aug 22, 8:12 am, Russell Keith-Magee 
> wrote:
>> On Sat, Aug 22, 2009 at 7:49 PM, Tim
>>
>> Chase wrote:
>>
>> > James Bennett wrote:
>> >> The current proposal is for a "USPostalCodeField" which
>> >> corresponds to the US Postal Service's list of postal codes:
>>
>> >>http://www.usps.com/ncsc/lookups/abbr_state.txt
>>
>> >> [snip] Based on the various arguments up to this point, it
>> >> seems like no single field is going to make everybody happy,
>>
>> Agreed that this particular argument is a recurring theme that we
>> should address.
>>
>> > Internally, I've solved a similar "can't make everybody happy"
>> > problem with a class factory function that takes the desired set
>> > of defined data, depending on the project:
>>
>> Given that the number of options is constrained, a fully-fledged
>> factory strikes me as overkill. Why not just booleans on the field
>> itself?
>>
>> USStateField(lower_48=True, dc=True, non_contiguous=True,
>> protectorates=False, military_drops=True)
>>
>> No need to deprecate anything - we can continue to ship USStateField
>> as is, just with some extra options that have default boolean values
>> set to reflect the currently enabled choices.
>>
>> Given that US postal codes seems like a particularly common request,
>> there isn't much harm in including a a USPostalCodeField as a shortcut
>> - it's just a subclass with all the options set True.
>>
>
> I'll toss out one idea. In Satchmo, we have an l10n application to
> support this data. We use a fixture to load the following data:
> - ISO2, ISO3 and ISO numeric
> - Official Name, Continent and Aministrative Area (state, territory,
> etc)
> - List of all Admin Areas (aka states in US) with full name and
> abbreviation
>
> for most of the countries of the world.
>
> The nice thing about this approach is that if someone wants to add an
> administrative area of some sort, it can be done and if they want to
> deactivate one, it's simple. I realize this may be a bit out of the
> scope for this particular issue but it feels like it would be a more
> robust solution and would scale nicely to other countries. This would
> also be a really cool feature to have in Django as a whole. Once the
> models are in place, data maintenance is pretty simple. Integrating
> into the USStateField of other country fields wouldn't be too
> difficult.
>
> Anyway, let me know your thoughts. The Satchmo l10n code is BSD
> licensed and I'd be willing to help if there's sufficient interest.

Hi Chris,

While I can appreciate the intent of your suggestion, we've said in
the past that we don't want Django to become a repository for i18n and
l10n data. I don't see any particularly strong reason to change this
policy.

There are several reasons for this decision.

Firstly, it's a lot of data to carry around, and not every project
will need this data. It's also a huge maintenance burden for us - and
for the translators that need to inspect and potentially translate
every region name etc.

Secondly, this is one of those areas where the community can play an
important role. I'd much rather see a vibrant community of i18n/l10n
data tools than try to generate the One True Font of Regions, and ship
it with Django. Django should stick to what it is good at. Let the
community decide where the best source of i18n data is to be found.

So - Django tries to ship with a basic set of l10n data and tools that
is useful to many. It's not perfect, but it's suitable for most simple
cases. We'll try to accommodate simple configuration requests (such as
giving some flexibility for US states), but there comes a point where
we'll say no. There's a line between 'batteries included' and
'includes every battery you will ever need for every Tibetan kitchen
appliance you will ever buy' :-)

So - if you're sufficiently enthused by the l10n problem, I heartily
encourage you to split the l10n code and data out of Satchmo into a
separate project. If anyone else in the community is interested in
this problem, I encourage you to take Chris up on his invitation to
use his BSD licensed code and data. There is plenty that could be done
in the l10n space for Django, and I'm eager to see what the community
can do.

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-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
-~--~~~~--~~--~--~---