Re: Proposal: deprecate and remove django.contrib.comments

[shacker]

Sorry, but -1 from me.

Given the core premise that the job of a web application framework is to 
find the common features that many websites need to implement and make them 
easy to achieve, commenting definitely fits into this category. 

I run two sites that use Django comments heavily. Django comments were easy 
to implement, and  work very well (though a layer of spam protection would 
be nice), and I have no desire to migrate years of historical comments to a 
3rd party system, or to write my own system (given the choice, I would 
write my own).

Yes, I could handle having comments moved out of core as long as they were 
maintained somewhere "official," but I don't quite see the necessity. 
Commenting is a feature that most sites need, so commenting seems like 
something that Django should provide. That's part of what "using a kick-ass 
framework" means to me. 

My .02,
./s


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: So has Instagram...

[shacker]

On Monday, April 9, 2012 10:03:57 PM UTC-7, diogobaeder wrote:
>
> ... just been acquired by Facebook? And it uses Django?
>
>
Indeed. We can only hope that Instagram will stay on Django under 
Facebook's care, though I won't be surprised if it's eventually subsumed 
into their PHP soup.  

But speaking of giving thanks, I'd like to do that too. After working 
mostly in Django over the past five years, I recently switched jobs into a 
Java shop running a "minor" framework, and came face to face with how much 
complexity it takes to build complex systems without something like Django 
working for you behind the scenes. It really is shocking to see the 
contortions some institutions go through to get things done that Django and 
Rails people now consider almost trivial. So here's a huge helping of 
thanks to all of the work the Django developers and contributors have put 
into it over the years, for all of the efficiencies and pleasantness we all 
have enjoyed on account of it. Your work is deeply appreciated.

./s

-- 
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/-/1NmvhUTCNd0J.
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: We're a group of students at UC Berkeley looking to contribute to Django

[shacker]

Since you're at Berkeley, stop by the Graduate School of Journalism some 
time to see the Django sites we run and meet the devs (look me up). Would 
also be interested in campus Django meetings (any alternative to the 
relentless Drupal push on campus :).

./s

-- 
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/-/QC0sasjCOQsJ.
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: Proposal: Replace django.contrib.formtools.wizard

[shacker]

On Sep 8, 1:27 pm, Anssi Kaariainen  wrote:

> > This is a real special case. ATM the formwizard isn't able to store invalid
> > forms. But if you are at the sprints in Portland, I would be happy to talk
> > to you about possible solutions.
>
> > Do you have any idea how this could be solved? (maybe you already patched
> > the formwizard to support this?)

I haven't  attempted patching formwizard - I'm not at that level :)
Was just letting you know the need is out there, since you're working
on this part of the system.

I'll probably end up doing as Anssi suggests and pickle the temporary
form data, only saving it to a db record once all fields are valid.

Thanks,
Scot

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Proposal: Replace django.contrib.formtools.wizard

[shacker]

On Sep 7, 6:00 pm, Stephan Jäkel  wrote:
> Hi,
>
> about 4 months ago, I started this thread. I want to give some news on
> django-formwizard to keep you all up2date.

Great to hear this is being worked on. At the djangocon forms session
today, I raised the following question and didn't get any concrete
suggestions. Hoping the new FormWizard will address this use case:

Not all forms are completed in a single sitting. We have a form with
more than 100 fields, which takes at least two hours for the user to
complete. Therefore it's essential that the (authenticated) user be
able to save it and return later to edit or complete it. IOTW there is
a need for resumable forms. The problem arises when you have required
fields - if these aren't filled out yet, form.is_valid() will never
pass, so you can't elegantly save it to be resumed later.

I would love to see FormWizard (or Forms in general) provide some
mechanism to deal with this.

Thanks,
Scot

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Filebrowser functionality in contrib?

[shacker]

On Jul 29, 8:09 pm, Tobias McNulty  wrote:
>
> For whatever it's worth, my sense is that there are a number of these types
> of third party apps out there, and no single one is a clear winner.

I would have to respectfully disagree - FileBrowser is far and away
the clear winner. There are no viable alternatives that I can find (if
someone can point one out, I'm all ears).

>  Furthermore, I don't really see what adding file management to contrib
> gives us (it seems to work just fine as a third party app),

... except that it's not working just fine (because of this dependency
on Grappelli).

> and I'd hate to
> see innovation stifled at this stage by including one of the implementations
> in contrib.

I definitely agree in principle about not stifling innovation. But at
the same time, one of the important jobs of a framework is to handle
tasks that are common to many web sites. I'd say that file management
falls into that category.  But I certainly won't press on this if the
developers disagree.

On Jul 29, 8:28 pm, Russell Keith-Magee 
wrote:

> That said - I *would* be interested in any proposal to improve the
> interface that contrib.admin provides so would make it easier to plug
> in external features such as a file browser. If django-filebrowser has
> become dependent on Grapelli, I presume this was to leverage some
> benefit of Grapelli that Django's native admin wasn't providing. To
> me, this points at a deficiency in Django's admin that should be
> addressed.

The author stated the reason in a ticket once but  I'm having trouble
finding it. It was along the lines of what you're saying here. I'll
post something and see if I can get details on exactly what he was
trying to overcome.

Thanks for the feedback.

Scot

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.