AFAIK this is a non-issue with BSD. Under BSD, LJW can do anything
with code that becomes part of Django, and so can anybody else. If you
copyright your code, that's independent from you submitting it as a
patch or committing it to the project. Committers must be able to
attest that the code they
On 6/1/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote:
> Those writings (high-level, quickly, automating, no-SQL) create several
> expectations to a visitor. Expectations which django currently does not
> fulfill (at least in the context of a quick-start). This leads to a
> unnecessary negative Use
OTECTED]> wrote:
>
> Am 10.04.2006 um 17:28 schrieb Wilson Miner:
> > That should be possible with the changes to stylesheets in magic-
> > removal.
>
> Almost, but not entirely. Observe:
>
><http://code.djangoproject.com/browser/django/branches/magic-
> rem
I think it's great you were able to get that much mileage out of the
admin styles in your app. If other people see a benefit in doing the
same, you've certainly proven it's possible. I still don't consider it
within the scope of the admin application to provide a public
interface for your app.
On
That should be possible with the changes to stylesheets in magic-removal.
Also, nothing should be preventing you from copying the admin styles
and modifying them to be specific to your own needs.
On 4/10/06, Christopher Lenz <[EMAIL PROTECTED]> wrote:
>
> Am 07.04.2006 um 17:03 sc
My point is not that you should or shouldn't have to write your own
form code. My point is that (in my mind anyway) needing to write your
own styles is not a barrier to reusing the admin form code.
Styling forms (once) is a lot less tedious than writing them (over and
over). And style is somethin
I'm open to being convinced otherwise, but I don't see it as within
the scope of the admin CSS to accomodate being embedded in other
interfaces.
We've discussed this internally before and the general consensus was
that if you're reusing the admin templates and code in your public
site (which is g
Too crufty to wrap it in a div class="description" so I can set it off
somehow in the styles?
On 3/23/06, Luke Plant <[EMAIL PROTECTED]> wrote:
>
> On Thursday 23 March 2006 17:31, wiz wrote:
> > > http://files.lukeplant.fastmail.fm/public/admin_with_description.pn
> > >g
> >
> > oops... 500: inf
But what does it look like? :)
On 3/21/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I've got an app that has a long form which requires a fair amount of
> descriptive text, usually at the beginning of a section of form fields.
> Apart from this, it is a perfect fit to the admin functio
I added my two cents to the ticket. I'm assuming you were getting my
confused with Simon (everybody does). Simon's the brilliant
programmer, I just make things look shiny.
On 3/7/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> I'd especially appreciate Simon's feedback on this one as it's mo
The whole concept of projects in Django is that they aren't tied to
sites. You can use the same project across multiple sites and use
multiple projects on one site.
On 3/2/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
>
> a 'site' in django terminology refers to a instance of your
> application runn
I think we should be as toolkit-agnostic as we are
templatesystem-agnostic and ORM-agnostic. We deliver one with Django,and all Django code builds on the delivered ones. But we don't enforcethose on users, if they want to use something else.
+1 - well put
That's a red herring. Nothing in that plan precludes using an existing AJAX library. If Dojo or Mochikit or whatever else out there does what we need it to for the admin, then the end result will be that we "integrate" that particular AJAX framework and build in some access points to make it easy f
I think this all sounds great. I also think Adrian's point in his post about AJAX support is very valid here. Any support for AJAX in Django should come from real needs in a real project.As Rob pointed out in an earlier thread, once the new-admin changes are rolled in, the project to fix the edit_i
The arrow next to "Local vars" on the 500 page seems the wrong wayround to me. I think it should point down before you click it to
indicate that doing so will reveal more stuff, and point left whenthe stuff is expanded to indicate that clicking again will roll itall back up.I had it that way to beg
+1 for hugo's suggestion. A tarball now gives us a "stable" version to point people to before we start knocking off backwards-incompatible changes. A finalized roadmap for 1.0 puts the target in sight. And 0.9 says "we're almost there". All in favor
On 11/9/05, Jeremy Dunck <[EMAIL PROTECTED]> wrot
16 matches
Mail list logo
