Re: The XMLField ticket

[Paul McMillan]

I've attached a patch per the discussion here. It's ready for review
and hopefully a speedy commit.

http://code.djangoproject.com/ticket/3094#comment:19

-Paul

-- 
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: Your thoughts on the Secure Web Application Framework Manifesto

[Rohit Sethi]

Hi Jacob, just as an FYI I messaged you last week about this off list
- my email was from my first name @securitycompass.com. Just wanted to
make sure you got it

Thanks,

Rohit

On Feb 24, 6:55 am, Jacob Kaplan-Moss  wrote:
> Hi Rohit --
>
> I had a skim of the document, too, and my feelings are pretty close to
> Russ's, so I won't bother with any specific feedback -- he basically
> speaks for me, too.
>
> To build off Russ, though, I have a bit of a meta meta-suggestion
> about OWASP in general. One huge problem I have as a software
> developer is that security is a bit of blind spot: I know a bit I've
> picked up here and there, but I really only know enough to not trust
> myself to get it right. Now, I'm used to trusting others' opinions
> about most of my technical blind spots, but the implications of
> security failures mean that I don't just have a knowledge problem, I
> *also* have a trust problem. I would be absolutely thrilled if there
> was a resource I could reach out to for design help, code review,
> advice for handling vulnerability reports, etc. I think OWASP has the
> trust to be such a group.
>
> The model here I think would be groups like the SFLC, who provide free
> legal advice to free software authors. Law is another place, like
> security, that has both a blind spot problem and a trust one, and they
> (and similar groups/individuals) are a critical part of the open
> source ecosystem.
>
> We've strayed way off-topic, I think, and so I'll leave this there --
> but feel free to contact me off-list if you want to discuss further.
>
> Jacob

-- 
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: Trac components cleanup

[Gabriel Hurley]

I'm not endorsing any specific set of changes here, but I can address the 
feasibility of making the changes in Trac:

>From empirical testing on my own Trac installation (running 0.11 currently, 
Django is on 0.12) updates to components, resolutions, etc. all propagate 
correctly when edited through the admin. Whether that's because Trac's 
backend is using foreignkeys (as one might hope), or whether it's simply 
wired up with the right hooks to update the database fields when the values 
are edited I don't know. But either way, it works as you'd expect.

So, whatever changes we decide to make, they shouldn't be hard to implement.

- Gabriel

-- 
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: Trac components cleanup

[Julien Phalip]

On Feb 28, 10:58 am, Paul McMillan  wrote:
> I think the django-admin.py categories could be consolidated into a single 
> one.
>
> In the interest of readability, we might rename django.contrib.foo to
> simply contrib.foo.
>
> As long as we're clarifying, "Django Web Site" might be better named
> "DjangoProject Web Site".

Yes I totally agree with those points. Perhaps "django-admin.py"
should also be renamed "Django built-in commands", and add ".com" in
"DjangoProject.com Web Site".

I'm not a Trac expert, but it feels as though the component values are
stored as full strings. So if changes are made it's likely we'll have
to run SQL queries to bulk-update the corresponding database entries.

Julien

-- 
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: Trac components cleanup

[Paul McMillan]

>> * The "Contrib apps" component [1] should be made redundant and new
>> components for each missing contrib app (e.g. contenttypes, sitemaps)
>> should be added. I mean, even databrowse has its own component! :) The
>> "Contrib app" mixes lots of unrelated things, making it a bit
>> pointless.
>> * For consistency, the "Authentication" component should be renamed to
>> django.contrib.auth, and "RSS framework" to
>> django.contrib.syndication.

I'm also +1 on those two.

> However, "core" is clearly being misused (or at least misunderstood).
> I'm open to suggestions (driven by the data) as to what extra
> categories we should add and/or how we should rename core. There are
> 169 open tickets attributed to "core" -- care to make some
> suggestions?

Core tends to end up as a dumping ground for people who haven't
carefully read the (admittedly already long) list of categories. It's
near the top, and so it's easy to choose over other more appropriate
categories. Consolidating some of the redundant categories might help.

I think the django-admin.py categories could be consolidated into a single one.

In the interest of readability, we might rename django.contrib.foo to
simply contrib.foo.

As long as we're clarifying, "Django Web Site" might be better named
"DjangoProject Web Site".

Those later two probably aren't worth doing unless Trac provides an
easy rename functionality.

-Paul

-- 
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: Customizable Serialization

[sebastien piquemal]

Hi

I just stumbled across this discussion ... even though I have always
been very interested about contributing to Django, I never took the
step yet ! But this is actually a topic that interests me very much
(even though for the moment it is Vivek's).

For several projects I am working on (a lot of APIs), I needed highly
customized serialization (and sometimes on objects that are not Models
at all). After a few attempts at writing directly some serialization
functions (a lot of very repetitive code), I decided to take a wider
view of the problem, and I wrote a generic serialization library for
Python : https://bitbucket.org/sebpiq/spiteat/. There is still quite a
lot of work to make the whole thing simpler, the docs are not well
organized ... so I am sorry for that. And also, that might be a little
overkill for django's built-in serialization framework (I even
implemented some debug logging functionalities for my serializers),
and it is probably too generic ... however it might give you
interesting ideas, and some inspiration on this problem !

The base idea are the following (https://bytebucket.org/sebpiq/spiteat/
wiki/doc_pages/conception.html):

1. treat all serialization/deserialization operations as recursive : a
serializer just divide its work, finds other serializers to delegate
sub-operations to, and then combines the results.
2. serialize/deserialize to a pivot format (a python dictionary
{: }), which allows to separate the heavy
(de)serialization work from the conversion to/from one or another
serial format. Then chain the result to another serializer for
example :
pivot = pivot_srz.serialize(queryset)
serialized = emitter_srz.serialize(pivot)

With SpitEat's system of settings which makes the serializers very
easily configurable, it has proven quite powerful for me. For example
say you have a model:

class MyModel(models.Model):
some_fk = models.ForeignKey(OtherModel)
some_field = models.TextField()
# ...

Say you have a serializer class ModelSrz that is used by default for
all model instances ... delegating the work would mean for this
serializer to find another serializer for every field ... by default,
for 'some_fk', ModelSrz would be used as well. But say you can
configure your serializers like this (using SpitEat's syntax):

#create new serializer that does really crazy stuff for my foreign key
class SomeFkSrz(Srz):
def serialize(self, inpt):
return "A super duper transformation %s"

def deserialize(self, inpt):
return a_super_duper_way_of_getting_my_object(inpt)

#then building my serializer for MyModel
my_model_srz = ModelSrz(attr_srz_map={'some_fk': SomeFkSrz()})

So basically, treating that as a recursive operation, allows a huge
flexibility while allowing to reuse a lot of code (if you provide good
mechanisms to plug-in your custom serialization at any level), because
you re-use ModelSrz, but you plug-in your own custom serializer for
'some_field'.

By doing like that, you can address all the requirements in
http://code.djangoproject.com/wiki/SummerOfCode2011 very easily, and
provide a lot of flexibility to the end-user.
Then, of course, this post doesn't address the problem of registering
your custom serializers to Django, nor registering your custom
emitters... but it probably ain't the complicated part.

I would be happy to provide any help on that topic, though I stopped
to be a student a few months ago :'-(

Cheers,

Sébastien

PS : There is an attempt at writing a SpitEat serializer for django
there : 
https://bitbucket.org/sebpiq/django-spiteat/src/312cb47ab200/serializers.py
it is very ugly, quite complicated (on purpose, because I needed
to handle a lot of things : MTI, GenericForeignKeys, ...), but it
should work fine for manytomany, fks, etc etc ...

On Feb 26, 6:54 pm, Russell Keith-Magee 
wrote:
> On Thu, Feb 24, 2011 at 10:24 PM, Vivek Narayanan  wrote:
> > Hi,
>
> > I am Vivek Narayanan, an undergrad student at IIT, Varanasi in India
> > and am interested in participating in this year's SoC
>
> Hi Vivek, and thanks for your interest in the GSoC!
>
>
>
> > Problem
> > 
> > Django provides a serialization framework that is very useful for
> > loading and saving fixtures, but not very flexible if one wants to
> > provide an API for a Django application or use a serialization format
> > different from what is defined by Django. Also the current handling of
> > foreign keys and many to many relationships is not really useful
> > outside the context of fixtures.
>
> > Solution
> > 
> > I propose a class based Serializer, extending/refactoring the current
> > base class which would be entirely configurable by the user. I would
> > also like to provide some configurations for XML and JSON/YAML, that
> > can serve as building blocks for writing other serializers. The class
> > would have the following configurable options:
>
> > • A basic structure, markup or 

Re: Suggestion: a new "nature" field in Trac

[Julien Phalip]

> On Mon, Feb 21, 2011 at 3:05 PM, Julien Phalip  wrote:
> > Hello,
>
> > I was wondering if others would find it useful to introduce a new
> > field in Trac to characterise the nature of a ticket, allowing to
> > choose from at least: "bug report", "feature request", or
> > "optimisation".

Going back to the original proposal, I suggest we introduce the
following options:

* Uncategorized (default)
* Feature request: for adding something new.
* Bug report: for when an existing thing is broken or not behaving as
expected.
* Optimisation: for when a thing is not broken but could be made
better, faster, stronger.
* Other: none of the above.

I anticipate at least one grey area, for when a new feature must be
introduced to fix a bug - I guess that this would be resolved on a
case-by-case basis, and that which side of the fence it eventually
falls would depend on the actual importance/gravity of the bug and on
the Beta/Alpha/RC stages.

Can you think of any other specifically useful options, or
alternatives for the ones above?

Cheers,

Julien

-- 
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: Trac components cleanup

[Russell Keith-Magee]

On Mon, Feb 28, 2011 at 4:13 PM, Julien Phalip  wrote:
> Hi,
>
> Tweaking Trac seems to be in the air, so I had some more ideas to
> suggest :)
>
> The "component" field in Trac is very useful when people look for
> tickets in their areas of familiarity/expertise. I think there are a
> few things that should be cleaned up to make the system a bit more
> useful and effective:
>
> * The "Contrib apps" component [1] should be made redundant and new
> components for each missing contrib app (e.g. contenttypes, sitemaps)
> should be added. I mean, even databrowse has its own component! :) The
> "Contrib app" mixes lots of unrelated things, making it a bit
> pointless.
> * For consistency, the "Authentication" component should be renamed to
> django.contrib.auth, and "RSS framework" to
> django.contrib.syndication.

Definitely agreed on these two.

My only concern would be implementation -- can we change the name of
the component, or do we need to go through a "create new name,
reassign existing, delete old" dance.

This is something that anyone with admin rights in Trac (including
myself) can do, once we've got a few +1 votes confirmed.

> * Clarify what the "Core framework" component [2] means, as it ends up
> being used for a lot of irrelevant things (for example, I've just
> cleaned out a lot of ORM-related tickets). Note that django.core.mail
> has its own component, but there are so many things that could be
> considered as part of the core framework that it might be difficult
> and counter-productive to split it in a gazillion components (as
> opposed to the number of contrib apps which is reasonably small and
> will never grow). At the very least, the name "Core framework" should
> be disambiguated if possible.

In defence of the status quo -- "mail" is a clearly isolated set of
APIs in a single module, but this isn't true of other "core" parts of
Django. I think this makes a good

However, "core" is clearly being misused (or at least misunderstood).
I'm open to suggestions (driven by the data) as to what extra
categories we should add and/or how we should rename core. There are
169 open tickets attributed to "core" -- care to make some
suggestions?

> * Merge the "User experience" component [3] with django.contrib.admin
> since it contains very few tickets and the vast majority of user
> experience related tickets will likely always be related to the admin
> anyway.

This differentiation was intentional (at least, it was at the time).
The idea of the "UX category" was to provide a list of
designer-focussed work -- ie., things where you didn't necessarily
need to be a programmer in order to make a contribution. Of course,
this ignores the contribution that designers can make in a design as
"how things work" vs "how things look" sense.

However, I think it's worth keeping this differentiation; it may be a
weak differentiator, but I think it's work keeping the distinction
between tasks that are known to be primarily Python, and tasks known
to be primarily CSS/JS.

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.

Trac components cleanup

[Julien Phalip]

Hi,

Tweaking Trac seems to be in the air, so I had some more ideas to
suggest :)

The "component" field in Trac is very useful when people look for
tickets in their areas of familiarity/expertise. I think there are a
few things that should be cleaned up to make the system a bit more
useful and effective:

* The "Contrib apps" component [1] should be made redundant and new
components for each missing contrib app (e.g. contenttypes, sitemaps)
should be added. I mean, even databrowse has its own component! :) The
"Contrib app" mixes lots of unrelated things, making it a bit
pointless.
* For consistency, the "Authentication" component should be renamed to
django.contrib.auth, and "RSS framework" to
django.contrib.syndication.
* Clarify what the "Core framework" component [2] means, as it ends up
being used for a lot of irrelevant things (for example, I've just
cleaned out a lot of ORM-related tickets). Note that django.core.mail
has its own component, but there are so many things that could be
considered as part of the core framework that it might be difficult
and counter-productive to split it in a gazillion components (as
opposed to the number of contrib apps which is reasonably small and
will never grow). At the very least, the name "Core framework" should
be disambiguated if possible.
* Merge the "User experience" component [3] with django.contrib.admin
since it contains very few tickets and the vast majority of user
experience related tickets will likely always be related to the admin
anyway.

What do you think?

Cheers,

Julien

[1] Contrib apps component:
http://code.djangoproject.com/query?status=assigned=new=reopened=Contrib+apps=id=summary=component=status=milestone=version=priority
[2] Core framework component:
http://code.djangoproject.com/query?status=assigned=new=reopened=Core+framework=id=summary=component=status=milestone=version=priority
[3] User experience component:
http://code.djangoproject.com/query?status=assigned=closed=new=reopened=User+Experience=id=summary=component=status=milestone=version=priority

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