I still have a problem although here is my appache file
DocumentRoot /var/www/mysite
ServerName mysite.com
ErrorLog logs/mysite.com-error_log
CustomLog logs/mysite.com-access_log common
SetHandler python-program
PythonHandler django.core.handlers.modpython
Py
2006/1/24, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>
> I still have a problem although here is my appache file
>
> DocumentRoot /var/www/mysite
> ServerName mysite.com
> ErrorLog logs/mysite.com-error_log
> CustomLog logs/mysite.com-access_log common
>
> SetHandler python-progr
I still have a problem although here is my appache file
DocumentRoot /var/www/mysite
ServerName mysite.com
ErrorLog logs/mysite.com-error_log
CustomLog logs/mysite.com-access_log common
SetHandler python-program
PythonHandler django.core.handlers.modpython
PythonPath
I'v finished a little program used for parsing settings.py, I think it
may be has some useful.
How to use it:
===
# import DjangoIni
# ini = DjangoIni('settings.py')
# ini['KEY'] if a key has been delete, so it'll
complain a KeyError Exception
# ini.ge
[EMAIL PROTECTED] wrote:
my Django proeject is not in the sitepackages it is in /var/www/mysite
First of all, it isn't a good practice to store a python web application
under /var/www. This can pose a potential security risk.
PYTHONPATH "['/var/www/mysite']"
Could be you are looking
Simon Greener wrote:
OK, thanks for confirming this for me. I had seen the docs but simply
didn't know their relationship to those on the site. Anyway, the ones on
the site are easier to read which is why I asked if they could be
downloaded
all in one hit rather than having to File>Save As (as
On 1/23/06, Simon Greener <[EMAIL PROTECTED]> wrote:
> OK, thanks for confirming this for me. I had seen the docs but simply
> didn't know their relationship to those on the site. Anyway, the ones on
> the site are easier to read which is why I asked if they could be
> downloaded
> all in one hit
Adrian,
On 1/23/06, Simon Greener <[EMAIL PROTECTED]> wrote:
Dunno if this is the right place to ask this question but I
would like to get a copy of all the Django documentation as
a single download and not have to go to the actual Django site.
Does the documentation exist as a single download
On 1/23/06, Simon Greener <[EMAIL PROTECTED]> wrote:
> Dunno if this is the right place to ask this question but I
> would like to get a copy of all the Django documentation as
> a single download and not have to go to the actual Django site.
> Does the documentation exist as a single download?
H
Folks,
Dunno if this is the right place to ask this question but I
would like to get a copy of all the Django documentation as
a single download and not have to go to the actual Django site.
Does the documentation exist as a single download?
I have been looking for an MDA framework for a multi-
On 1/23/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Let me see if I can clarify the new use of manipulators here. You
> either use a manipulator *or* you have to explicitly set every
> attribute of your model. Only manipulators know which elements from
> the POST data ought to be passed int
On 1/23/06, Maniac <[EMAIL PROTECTED]> wrote:
>
> Joseph Kocherhans wrote:
>
> >Have you started on this yet maniac?
> >
> Not yet. And actually can't predict when I'll be able to :-(. So feel
> free to implement the idea if you like. Please post here a ticket number
> to track the thing.
I've ad
my Django proeject is not in the sitepackages it is in /var/www/mysite
can anyone help me how to configure my appache so as it will work
proparly
here it is what i have but it is not working i don't know why
SetHandler python-program
PythonHandler django.core.handlers.modpython
PYTHO
Joseph Kocherhans wrote:
Have you started on this yet maniac?
Not yet. And actually can't predict when I'll be able to :-(. So feel
free to implement the idea if you like. Please post here a ticket number
to track the thing.
On 1/23/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Is there any reason subtyping and field descriptors need to happen on
> magic-removal? Could we just test/merge magic-removal and create a new
> branch for those tasks? Is there anything else but those two tasks
> left? It doesn't sound li
On 1/22/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 1/23/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> >
> > I'd like to start moving my stuff over to the magic removal branch and
> > was wondering if the API is stable enough to start doing so.
> >
> >
>
> I would say probably not. Th
On 1/11/06, Maniac <[EMAIL PROTECTED]> wrote:
>
> Adrian Holovaty wrote:
>
> >You can get started, if you're willing to use the magic-removal branch. :)
> >
> >The event system is in that branch, in django.dispatch.
> >
> >
> Ok. I'll get to it as soon as I could kill some more lines from ToDo on
On 1/23/06, Brant Harris <[EMAIL PROTECTED]> wrote:
>
> For instance with manipulators, after magic-removal, it will be
> elementary to over-ride the Model.AddManipulator(), and
> Model.ChangeManipulator(pk). So you could then apply RuleDispatch in
> your own model, and not need it built-in to Dj
Ian went over the RuleDispatch at the ChiPy meeting a few months back.
It's a very interesting technique, certainly. But it's usage is
limited in scope, and I think dangerous in appeal. In this case, I
think it's better to apply it at the application level, rather than in
Django itself. Rather
On 1/23/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/23/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > Rather than reserving attribute names in a model instance
> > (modelinstance.objects returns a Manager) we could use a combination
> > of generic functions and a simple type of a
On 1/23/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Rather than reserving attribute names in a model instance
> (modelinstance.objects returns a Manager) we could use a combination
> of generic functions and a simple type of adaptation.
What real-world problem would this solve?
Adrian
--
This may be rather confusing for those who aren't familiar with Philip
Eby's RuleDispatch package. Feel free to ask questions. I'll answer
them as best I can.
Rather than reserving attribute names in a model instance
(modelinstance.objects returns a Manager) we could use a combination
of generic
On 1/22/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> I've been messing with manipulator code in magic-removal, and it
> struck me that we could avoid a lot of the boilerplate, cruft and
> newbie confusion by making models validation-aware.
Let me see if I can clarify the new use of manipula
Adrian Holovaty wrote:
> I've been messing with manipulator code in magic-removal, and it
> struck me that we could avoid a lot of the boilerplate, cruft and
> newbie confusion by making models validation-aware.
In general, I think this is a very good idea. I can't say I'm 100%
sold on the imple
On 1/23/06, Jason Davies <[EMAIL PROTECTED]> wrote:
> I'm keen to get the "semantics of subtyping" stuff done. If you have
> any implementation hints to help me along that would be really helpful,
> thanks.
Same here. I'd love to see a working subtyping implementation for
magic removal, the soon
Hi all,
Any news on this simple patch ? Any ETA when it will be commited to
trunk ?
Regards, Alex
Robert Wittams wrote:
> I personally am not going to be able to work on it any time soon. Sorry.
> Anyone else should feel free to give it a stab.
I'm keen to get the "semantics of subtyping" stuff done. If you have
any implementation hints to help me along that would be really helpful,
thanks.
Russell Keith-Magee wrote:
> On 1/23/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
>
>>
>>I'd like to start moving my stuff over to the magic removal branch and
>>was wondering if the API is stable enough to start doing so.
>>
>>
>
> I would say probably not. There is still one big change to come -
This:
>What I'm suggesting is that validation only happens when you do
>save(), or when you access the "errors" attribute. This means you can
>set data on the model to your heart's content until you actually want
>to validate it.
won't work with that:
>This is a good question. I don't see a *hu
>Up until today I could even run both branches of
>code against the same database, but that changed tonight because we've
>changed the way database-table names are calculated.
Ok, now I know why it was a bad idea to switch the logger to
magic-removal ;-)
(just kidding, it's a really simple proje
30 matches
Mail list logo
