Re: JsonField
i'm watching the ticket right now. maybe there is no need to to create a class JSONDateEncoder(json.JSONEncoder) because there is DjangoJSONEncoder already. then it would be great to implement a lazy translation object for DjangoJSONEncoder to store ugettext_lazy objects. for me there is no need to create set_%s_json and get_%s_json method because the field should handle it directly, and we should use the to_python method, like all other fields in django. for example the datetime field directly push a datetime object to the model (using to_python) and transform it to a string when we call save method. we should use the same logic here and encode a json object to string only when we call the save method, no need for a get_%s_json in the field api. On 6 Nov, 01:36, Russell Keith-Magee wrote: > On Sat, Nov 5, 2011 at 7:48 PM, Ric wrote: > > this is my proposition to have custom data inside a model field > > > a json data field, the code is simple as this, and it works with > > lastest django release > > See #12990 -- this is a ticket that has requested exactly this feature. > > You'll also see that with one exception, the core team have all been > -1 or -0 on this idea. > > 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: JsonField
i'm posting this comment into the ticket. On 6 Nov, 20:14, Ric wrote: > i'm watching the ticket right now. > maybe there is no need to to create a class > JSONDateEncoder(json.JSONEncoder) because there is DjangoJSONEncoder > already. > then it would be great to implement a lazy translation object for > DjangoJSONEncoder to store ugettext_lazy objects. > > for me there is no need to create set_%s_json and get_%s_json method > because the field should handle it directly, and we should use the > to_python method, like all other fields in django. > > for example the datetime field directly push a datetime object to the > model (using to_python) and transform it to a string when we call save > method. > > we should use the same logic here and encode a json object to string > only when we call the save method, no need for a get_%s_json in the > field api. > > On 6 Nov, 01:36, Russell Keith-Magee wrote: > > > > > > > > > On Sat, Nov 5, 2011 at 7:48 PM, Ric wrote: > > > this is my proposition to have custom data inside a model field > > > > a json data field, the code is simple as this, and it works with > > > lastest django release > > > See #12990 -- this is a ticket that has requested exactly this feature. > > > You'll also see that with one exception, the core team have all been > > -1 or -0 on this idea. > > > 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.
TemplateResponse and loader should handle request
request.url_conf has been added with django 1.3. in my opinion, the loader object should handle the request, so that can be sublassed to pass different template folder based on request params. i need this feature for my app, is it possible to have different template folder based on request params with the current django release? -- 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.
Django application instances
Hi there,
My name's Chris Northwood and I'm a core contributor to the Molly
Project (http://mollyproject.org/), which is a mobile portal framework
built on top of Django. We're an open source project but we currently
think we're doing quite a few things that are "non-core" for us, and
we'd like to push back upstream into the Django project.
One of these things are multiple application instances. We've built a
fairly straight-forward way to instantiate multiple instances of the
same app (with self-contained configuration) in the settings.py, e.g.,
APPLICATIONS = [
Application('molly.apps.weather', 'oxweather', 'Oxford Weather',
location_id = 'bbc/25',
provider =
Provider('molly.apps.weather.providers.BBCWeatherProvider',
location_id = 25,
),
),
Application('molly.apps.weather', 'lonweather', 'London Weather',
location_id = 'bbc/8',
provider =
Provider('molly.apps.weather.providers.BBCWeatherProvider',
location_id = 8,
),
),
]
INSTALLED_APPS += extract_installed_apps(APPLICATIONS)
ROOT_URLCONF = 'molly.urls'
This defines two apps of the molly.apps.weather reusable Django app,
one with a URLconf under /oxweather/ and one under /lonweather/.
Depending on the URL accessed, the (class-based) views inside the app
then have access to a self.conf attribute which they can use when
querying the database (or whatever) to deliver different behaviour
based on the class, i.e., inside our view
current_weather =
Weather.objects.get(location_id=self.conf.location_id)
We use this fairly extensively, and there are a number of non-trivial
examples in our codebase too.
The URLconf is automatically generated by the molly.urls module, and
we also have the ability to annotate our class-based views using a
custom @url annotator so the URLconf for the application is also
automatically generated (to us it makes sense to keep the patterns in
the same place as the view!)
My question is, would the Django community at large find this
functionality useful, i.e., is it worth us working to break this
functionality out of our libraries and then provide a patch to you
guys? It's certainly non-trivial, and I wouldn't want to waste effort,
and I think this is functionality that could be useful for others.
Regards,
Chris Northwood
--
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: Django application instances
Chris,
Your message comes at a time of frequent discourse over the matter of
apps and pluggability. There's no doubt in my mind that a desire
exists in the django community for this functionality, so I'm
certainly +1 on your creation of a patch. There's no single ticket
around which this matter has coalesced - creating a new ticket is
probably a good approach.
I assume you have already checked out the main wiki page on pluggable
apps at https://code.djangoproject.com/wiki/ReusableAppResources - a
link to your proposal may be appropriate.
On Sun, Nov 6, 2011 at 2:40 PM, Chris Northwood wrote:
> Hi there,
>
> My name's Chris Northwood and I'm a core contributor to the Molly
> Project (http://mollyproject.org/), which is a mobile portal framework
> built on top of Django. We're an open source project but we currently
> think we're doing quite a few things that are "non-core" for us, and
> we'd like to push back upstream into the Django project.
>
> One of these things are multiple application instances. We've built a
> fairly straight-forward way to instantiate multiple instances of the
> same app (with self-contained configuration) in the settings.py, e.g.,
>
> APPLICATIONS = [
>
> Application('molly.apps.weather', 'oxweather', 'Oxford Weather',
> location_id = 'bbc/25',
> provider =
> Provider('molly.apps.weather.providers.BBCWeatherProvider',
> location_id = 25,
> ),
> ),
>
> Application('molly.apps.weather', 'lonweather', 'London Weather',
> location_id = 'bbc/8',
> provider =
> Provider('molly.apps.weather.providers.BBCWeatherProvider',
> location_id = 8,
> ),
> ),
>
> ]
>
> INSTALLED_APPS += extract_installed_apps(APPLICATIONS)
> ROOT_URLCONF = 'molly.urls'
>
> This defines two apps of the molly.apps.weather reusable Django app,
> one with a URLconf under /oxweather/ and one under /lonweather/.
> Depending on the URL accessed, the (class-based) views inside the app
> then have access to a self.conf attribute which they can use when
> querying the database (or whatever) to deliver different behaviour
> based on the class, i.e., inside our view
>
> current_weather =
> Weather.objects.get(location_id=self.conf.location_id)
>
> We use this fairly extensively, and there are a number of non-trivial
> examples in our codebase too.
>
> The URLconf is automatically generated by the molly.urls module, and
> we also have the ability to annotate our class-based views using a
> custom @url annotator so the URLconf for the application is also
> automatically generated (to us it makes sense to keep the patterns in
> the same place as the view!)
>
> My question is, would the Django community at large find this
> functionality useful, i.e., is it worth us working to break this
> functionality out of our libraries and then provide a patch to you
> guys? It's certainly non-trivial, and I wouldn't want to waste effort,
> and I think this is functionality that could be useful for others.
>
> Regards,
>
> Chris Northwood
>
> --
> 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.
>
>
--
Justin Holmes
Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330
--
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: I want to pass the Exception info from Http404 to handler404 view and consequently the 404.html
for me a simple solution to this is issue, is that django should be
able to recognize an HttpResponse as error and return it
like:
raise HttpResponseRedirect(url)
or
raise HttpResponse(render_to_template("errors/user_not_logged"),
context = RequestContext(context), status_code = 401)
with this approch a view can raise an HttpResponse and interrupt the
view process
django should simply check if the exception is an HttpResponse class
and simply returns it.
with the new TemplateResponse, everything is made mode customizable,
because the TemplateResponse should implement a render method that
checks is settings.DEBUG is true and then return a technical response,
or return template response.
On 31 Ott, 08:08, Mateusz Marzantowicz
wrote:
> On Sun, Oct 30, 2011 at 8:38 PM, Kiril wrote:
> > Hello guys,
>
> > in the past few months I have been developing a simple web site using
> > Django. I found Django amazing and mature framework for my needs. I am
> > now about to publish it in public hosting.
>
> > To my dismay the erro info I have included in Http404 calls is wasted
> > by Django and cannot make it's way ot the handler404 and consequently
> > to the 404.html template.
>
> > Here is example code from my views.py:
>
> > #is user logged in
> > if not request.user.is_authenticated():
> > raise Http404(_("It is not allowed to post anonymous comments"))
>
> > Now I want to display the localized message in the 404.html but it
> > seems this does not make it to the handler404 view.
>
> > Here is what I found in the Django sources -
> > django.core.handlers.base.get_response:
>
> > except http.Http404, e:
> > logger.warning('Not Found: %s' % request.path,
> > extra={
> > 'status_code': 404,
> > 'request': request
> > })
> > if settings.DEBUG:
> > from django.views import debug
> > response = debug.technical_404_response(request,
> > e)
> > else:
> > try:
> > callback, param_dict = resolver.resolve404()
> > response = callback(request, **param_dict)
> > except:
>
> > As can be clealry seen the exception "e" is only passed ot the DEBUG
> > handler but no to the production one "callback".
>
> > My feature request is to add keyword argument param_dict "exception"
> > with the value of the Http404 exception "e" that is passed over to the
> > handler404 code. I can make this fix in my local deployment but it is
> > not possible to edit my hodting provider Django instance.
>
> > This will help communicate the details of the 404 errors to end users.
> > Same could be applied few lines below in the handler for
> > exceptions.PermissionDenied.
>
> > I hope this resonates with the development concepts of Django and this
> > small fix can make its way in to follow on release.
>
> > -Kiril K
>
> But why you return HTTP 404 (Not found) error in case your user is not
> authenticated? Not found errors are designed to handle situations where
> document or page is not present on the server. It has nothing to do with
> user authentication.
>
> Please also see:https://docs.djangoproject.com/en/dev/topics/auth/for
> django and authentication usage patterns.
>
> Also note that one line below that block you've cited is code path for
> handling PermissionDenied exception.
>
> Mateusz Marzantowicz
--
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: Django application instances
On Mon, Nov 7, 2011 at 3:59 AM, Justin Holmes wrote: > Chris, > > Your message comes at a time of frequent discourse over the matter of > apps and pluggability. There's no doubt in my mind that a desire > exists in the django community for this functionality, so I'm > certainly +1 on your creation of a patch. There's no single ticket > around which this matter has coalesced - creating a new ticket is > probably a good approach. Untrue -- #3591 has been the ticket tracking this idea for some time. The ticket even has a patch/branch that is just waiting for review. I've been wanting to do a review for some time, but life has conspired against me... The focus of this branch has been to turn an "Application" into a configurable object; this would allow app designers to define configuration points that are set at time of deployment. The one major aspect that you've described but isn't covered by the current patch on #3591, is the idea of having multiple instance of the same app in a single project. This introduces the complication that database table names need to include a deploy-time component (i.e., some sort of instance identifier), which, IIRC, was punted from the goal list for the SoC project that yielded this patch. However, to the best of my knowledge, the approach described in the current patch *could* be used to handle the multiple instance scenario; it just hasn't been implemented. 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: I want to pass the Exception info from Http404 to handler404 view and consequently the 404.html
The way I am handling this type of thing (and this is getting into django-users territory), is to either: - have a middleware that catches exceptions, and if they are a sub-class of HttpError, then return them, - have a framework which handles this, often by having the CBV handle it in it's dispatch method. -- 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/-/KgRMAnoaz7wJ. 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: JsonField
I'm doing just this in several cases: I packaged up a JSONField into a re-usable application: https://bitbucket.org/schinckel/django-jsonfield/overview -- 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/-/XrB-bbFjvZcJ. 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: JsonField
it's a good code. you wrote: # TODO: Look for date/time/datetime objects within the structure? and there is no need, because it's handled by djangojsonencoder On 7 Nov, 07:06, schinckel wrote: > I'm doing just this in several cases: I packaged up a JSONField into a > re-usable > application:https://bitbucket.org/schinckel/django-jsonfield/overview -- 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.
