Re: Re-design "proposal" for djangoproject.com

[Russell Keith-Magee]

On Mon, May 21, 2012 at 11:04 PM, Adam "Cezar" Jenkins
 wrote:
> On Mon, May 21, 2012 at 2:01 AM, Erik Stein  wrote:
>>
>>
>>
>> Am 21.05.2012 um 04:06 schrieb Adam Cezar Jenkins:
>>
>> > I'm sad to hear that about the pony. The pony itself isn't the issue,
>> > the issue to me is that there is a lack of branding of a real logo/mascot.
>> >
>> > I agree with 90% of the comparisons made in the blog post
>> > http://grokcode.com/746/dear-python-why-are-you-so-ugly/
>>
>> Please let me add in all politeness that I don't agree. djangoproject.com
>> is not for the masses and therefore doesn't need to be over-simplified. On
>> the contrary, it's for professionals who know what they are looking for.
>>
>
> I agree it doesn't need to be for the masses, but even professionals will
> make quick judgements based on look. Look is important, no matter the site.
>
>>
>> What is missing in django marketing is IMHO a cleverly selected showcase
>> of large and also small mature django sites, including in-house. A list of
>> mature plugin-projects/apps would make sense, too.
>>
>
> I can't agree more with this statement.

You won't get any disagreement from me here, either. However, what I
will disagree with is whether this showcase needs to be part of the
core Django project site (by which I mean created, monitored,
maintained by the core team), rather than an external project.

This is *exactly* why I keep harping on the point about providing a
space for links to external projects. Django People is the best
example of this, but a Django showcase would fit just as well. Both
can easily operate as a resource that is managed externally to the
core Django project. Managing them as external projects means they
aren't subject to the bottlenecks of "core team approval", and they
allow us, as a community, to expand the base of experts who are in a
position to represent the project as a whole. If any of these external
projects need help with hosting, the Django Software Foundation is in
a position to help out -- nobody should be out of pocket for
maintaining a resource that the whole Django community benefits from.

The DSF is also in a position to direct traffic to these projects --
but this isn't possible if the main project website doesn't provide a
way to spotlight these "external" projects as a prominent part of the
site design.

So - if you think there's a need for a showcase site -- go ahead and build it!

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.

Re: Customizable Serialization check-in

[Piotr Grabowski]

I do some changes to my previous API: (https://gist.github.com/2597306 
<- change are included)


 * which fields of object are default serialized. It's depend on 
include_default_field but opposite to Tom Christie solution it's default 
value is True so all fields (eventually specified in Meta.model_fields) 
are present

.
 * follow_object attribute. In short - on which object should work 
Serializer's child Serializer. Tom wrote about this in previous mail but 
I didn't fully understand the problem so I gave him bad answer. It's 
better described in algorithm I present.


 * get rid of aliases and preserve_field_ordering fields

 * change class hierarchy
class Serializer(object) # base class for serializing
class Field(Serializer) # class for serializing fields in objects
class ObjectSerializer(Serializer) # class for serializing objects
class ModelSerializer(Serializer) # class for serializing Django 
Models.



I prepare  list of steps for first phase of serialization. It's written 
in English-Python pseudo code :) Hope indentation will be preserved.
Serializer.serialize is function that for object will return dict with 
python native datatypes.


(Object|Model)Serializer.serialize(object, field_name (can be None), 
**options)

1. Get object
1.1. if object is iterable then do this algorithm for all elements 
and return list of returned values
1.2. if field_name for object is set from upper level we have 
object Obj:
1.2.1. if Meta.follow_object == True then work on object 
Obj.field_name

1.2.2. else work on Obj

2. Find all fields Fs that should be serialized
   2.1. Get all fields declared in Serializer
   2.2. Get all fields from Meta.fields
   2.3. If Meta.include_default_fields = True then get all fields where 
type is valid in Meta.model_fields and not in Meta.exclude


3. Create dictionary A and for F in Fs:
3.1. Find serializer for F
3.1.1. If F is declared in Serializer then serializer is 
explicit declared

3.1.2. Else get serializer for F type (m2m related etc)
3.2. Save in dictionary A[field_name] = serializer_value
3.2.1. If field has set label then field_name = label
3.2.2. If field has set attribute=True then add this to 
dictionary A[__attributes__][field_name] = serializer_value


4. Return A


Field.serialize(object, field_name (can be None), **options)
1. Get object
1.1. if it is iterable then do this algorithm for all elements
1.2. work on object Obj passed from upper level

2. Find all fields Fs that should be serialized
   2.1. Get all fields from declared fields

3. Create dictionary A and for F in Fs:
3.1. Find serializer for F
3.1.1. F is in declared fields so serializer is explicit declared
3.2. Save in dictionary A[field_name] = serializer_value
3.2.1. If field has set label then field_name = label
3.2.2. If field has set attribute=True then add this to 
dictionary A[__attributes__][field_name] = serializer_value


4. Resolve function serialized_value
4.1. If Fs (and A) is empty:
4.1.1. If function field_name returns None then return 
serialized_value

4.1.2. Else return {field_name() : serialized_value()}
4.2. Else
4.2.1. If function field_name returns None then raise Exception
4.2.2. Else  A.update({field_name() : serialized_value()})

5. Return A

We have dict (list of dicts) from first phase of serialization. Next 
__attributes__ must be resolve (depends on format and strategy).



Deserialization: (it's early idea)

SomeSerializer.deserialize(D - python_native_datetype_objects (dict or 
list of dict), instance=None, field_name=None, class_name=None, **options)


1. Get object instance # Resolving this may be more complicated than I 
wrote below (e.g. base on D fields - duck typing)

1.1. If instance is not None then use it
1.2. Else try resolve class_name
1.2.1. If class_name is class object instantiate it.
1.2.2. If class_name is string then find string value for this 
key in D and instantiate it

1.2.3. If class_name is None raise Exception

2. Find all fields in D and find fields in Serializer for deserializing them
2.1. Resolve label attribute for fields

3. Pass instance, data D and field_name to all fields Serializers

4. Return instance


I'm aware that there will be lot of small issues but I believe that 
ideas are good.


--
Piotr Grabowski

--
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: Re-design "proposal" for djangoproject.com

[Adam "Cezar" Jenkins]

On Mon, May 21, 2012 at 2:01 AM, Erik Stein  wrote:

>
>
> Am 21.05.2012 um 04:06 schrieb Adam Cezar Jenkins:
>
> > I'm sad to hear that about the pony. The pony itself isn't the issue,
> the issue to me is that there is a lack of branding of a real logo/mascot.
> >
> > I agree with 90% of the comparisons made in the blog post
> http://grokcode.com/746/dear-python-why-are-you-so-ugly/
>
> Please let me add in all politeness that I don't agree. djangoproject.comis 
> not for the masses and therefore doesn't need to be over-simplified. On
> the contrary, it's for professionals who know what they are looking for.
>
>
I agree it doesn't need to be for the masses, but even professionals will
make quick judgements based on look. Look is important, no matter the site.


> What is missing in django marketing is IMHO a cleverly selected showcase
> of large and also small mature django sites, including in-house. A list of
> mature plugin-projects/apps would make sense, too.
>
>
I can't agree more with this statement.


I agree


> Best
> -- erik
>
>
>
> Erik Stein
> Programmierung, Grafik
>Oranienstr. 32   10999 Berlin, Germany
>fon +49 30 69201880   fax +49 30 692018809
>email e...@classlibrary.net
>
>
>
> --
> 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.
>
>

-- 
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: GSoC Check-in: Security Enhancements

[Rohan Jain]

Hi,

Since my last check in I worked on improvements to
contrib.sessions:

 - Introduction of signing framework
 - Session expiry checks (for Ticket [#18194][0]
 - And some other trivial patches.

The tests (existing and the one which I added) are passing.

These changes are in my [Pull Request #78][1] over github.
Paul, could you please review it to see if the patches are usable.

Next, I'll make the changes which may be required in documentation
because of the above.
Today is official start date of the GSoC project, so I'll now start
concentrating more on the project now.

Rohan Jain

[0]: https://code.djangoproject.com/ticket/18194
[1]: https://github.com/django/django/pull/78

On Mon, May 7, 2012 at 12:21 PM, Rohan Jain  wrote:
> Hi,
>
> Last week I looked into the Ticket [#18194][0]:
>
>  - Trivial attempts to handle the issue.
>  - Wrote a minor initial patch.
>  - The test fails for Cache and Cookie backend.
>
> Also, I looked at the talks from Paul regarding advanced security
> topics at py/django cons. Realised that why I should not attempt
> anything related to encryption in my project.
>
> There is high academic pressure currently, so I am not able to give
> enough time to these. I think the situation will be better this
> weekend onwards.
>
> I'll try to work on:
>
>  - Write tests which emulate the problem in #18194 well, and then work
> on the final fix.
>  - Start looking into resources useful for my project, like [The
> Tangled Web][1].
>
> Rohan Jain
>
>
> [0]: https://code.djangoproject.com/ticket/18194
> [1]: http://www.amazon.com/The-Tangled-Web-Securing-Applications/dp/1593273886

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

Customizable serialization now passing Django's test suite.

[Tom Christie]

I've been working away on 
django-serializerslately, 
and I've now got a
customizable serialization API that's backwards compatible with the existing
serializers, and is passing Django's serializer tests.

Exactly where I take this will depend on how Piotr Grabowski's GSoC project
progresses, but I'd certainly appreciate any input regarding the API design,
or if there would be any obvious blockers that'd prevent something along 
these
lines making it's way in as a replacement to the existing serializers.

This work intentionally doesn't (yet) address customizable deserialization,
and as such it currently only supports the existing loaddata 
deserialization.


Running the existing tests with django-serializers
==

* Clone Django

* Install django-serializers

* Replace the existing dumpdata serializers with django-serializer's 
versions

In `django/core/serializers/__init__.py`, replace these strings:

"django.core.serializers.xml_serializer",
"django.core.serializers.python",
"django.core.serializers.json",
"django.core.serializers.pyyaml"

With these:

"serializers.dumpdata_xml",
"serializers.dumpdata_python",
"serializers.dumpdata_json",
"serializers.dumpdata_yaml"

* Run the serializer tests from Django's 'tests' directory

./runtests.py --settings=test_sqlite serializers serializers_regress


Example use-case


I've written a small app 
`django-auto-api` 
that uses `django-serializers`
to generate a read-only hyperlinked API for all installed models with 
`html`,
`json`, `yaml`, `xml` and `csv` outputs.

It demonstrates using custom relational fields between models to use
hyperlinking relationships rather than primary key relationships, and shows
how the customizable serialization can be used to build Web APIs with
very little code.


Summary
===

As mentioned I'd appreciate any thoughts on what else it might take to 
bridge
the gap of getting this to the point where it could be adopted into core.

I think it should also serve as a decent point of reference for Piotr's 
GSoC project, in
particular `django-auto-api` is a good concrete use-case that I'd like any
customizable serialization proposal to be able to handle.


 - Tom

[1] django-serializers: https://github.com/tomchristie/django-serializers
[2] django-auto-api: https://github.com/tomchristie/django-auto-api

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/TI2XBLY4FK8J.
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: Re-design "proposal" for djangoproject.com

[Erik Stein]

Am 21.05.2012 um 04:06 schrieb Adam Cezar Jenkins:

> I'm sad to hear that about the pony. The pony itself isn't the issue, the 
> issue to me is that there is a lack of branding of a real logo/mascot. 
> 
> I agree with 90% of the comparisons made in the blog post 
> http://grokcode.com/746/dear-python-why-are-you-so-ugly/

Please let me add in all politeness that I don't agree. djangoproject.com is 
not for the masses and therefore doesn't need to be over-simplified. On the 
contrary, it's for professionals who know what they are looking for.

What is missing in django marketing is IMHO a cleverly selected showcase of 
large and also small mature django sites, including in-house. A list of mature 
plugin-projects/apps would make sense, too.

Best
-- erik



Erik Stein
Programmierung, Grafik
Oranienstr. 32   10999 Berlin, Germany
fon +49 30 69201880   fax +49 30 692018809
email e...@classlibrary.net



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