template syntax error

[harsh sharma]

i created a model in which i have an image filed but when ever i am trying 
to get an uploaded image on the 
in my model.py 

image = models.ImageField(upload_to='static/pictures',)


setting.py

STATIC_URL = '/static/'
STATICFILES_DIRS = [
os.path.join(BASE_DIR, "static", "./static"),
'/var/www/static/',
]


index.html file

{% load static %}
https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5882b15f-d674-44b9-ba67-74eeecd39137%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Making an object unsaveable ...

[Bernd Wechner]

An interesting question I've not been able to solve reading docs or 
Googling. As every posting here only after some serious research efforts 
including class inspections ;-). But am stumped and wonder if anyone 
else has any ideas.


Here is the use case:

1. Load an object from database
2. Flag it as unsaveable, not to be written back to database under any
   circumstances
3. Make changes to the object (its fields)
4. Present a detail view of the object.

Basically, would like the freedom to change an object knowing the 
database is secure.


As ever, am more interested in how to do this, than questioning why to 
do it. It may not be possible in which case fear not, I'm on top of the 
why's and can look at alternative strategies. But this use case provides 
an easy way of injecting some filters in one place of a code body I have 
without changing any of the views or other code. Simply one small hook I 
place into extant code, which will play around with the object (making 
translations for example). But in order to do so would want to know this 
cannot be written back to the database, that from here on in, it's for 
display purposes only.


Have a suspicion after some research that this can't be done. In which 
case there's a second and almost as useful use case:


1. Load an object from database
2. Make a copy, that is unsaveable, not to be written back to database
   under any circumstances
3. Make changes to the copy (its fields)
4. Present a detail view of the copy.

This has some slightly better chance of being possible. If not as well, 
yes indeed, I have to dive into the view itself and put hooks into each 
field as it renders I guess. Which is life. But would seem useful to do 
it with one of these use cases (again no need to discuss the merits of 
one approach over the other at all, am more interested in possibility - 
projects have huge amounts of context not readily shareable that 
influence the relative merits of one approach over another of course.


Regards,

Bernd.

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/9162bad4-935a-ed39-d2d8-a001103ec705%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: The cloud panel doesn't into directory in django

[Safa Bayar]

It doesn't work and i clap eyes on other link in html file. link is delete 
file, edit page, download link etc. he did what you said, but it did not 
work. I got the same mistake. 



3 Mart 2018 Cumartesi 20:15:17 UTC+3 tarihinde Dylan Reinhold yazdı:
>
> Your sample URL /navforward/DigitalOcean/*root*docker-bench-security/
> Does not match anything in your urls
>
> This one looks to be the closest:
>
> url(r'^naviforward(?P[\w]+)/(?P[\*\w]+)/(?P[\w]+)/$','manager.views.navforward'),
>
>
> In the url there is no / after navforward, and it going to be looking for 
> a / between *root* and docker-bench
>
> Dylan
>
>
> On Sat, Mar 3, 2018 at 2:13 AM, Safa Bayar  > wrote:
>
>> I write cloud panel write python/django. My problem is, urls.py doesn't 
>> access next forward directory. I use apache. when it is go to next forward, 
>> this page is showing: 
>>
>>
>> 
>>
>>
>> my urls.py inside:
>>
>>
>> 
>>
>>
>> from django.conf.urls import patterns, include, urlfrom django.contrib 
>> import adminfrom django.views.generic.base import TemplateView
>>
>> admin.autodiscover()
>>
>> urlpatterns = [
>> url(r'^admin/', include(admin.site.urls)),
>> url(r'^$','explorer.views.home',name='home'),
>> url(r'^servers/$','explorer.views.servers'),
>> url(r'^addserver/$','explorer.views.addserver'),
>> url(r'^removeserver/$','explorer.views.removeserver'),
>> 
>> url(r'^manage/(?P[\w]+)/(?P[\w]+)/$','manager.views.filemanager'),
>> 
>> url(r'^navback/(?P[\w]+)/(?P[\*\w]+)/$','manager.views.navbackward'),
>> 
>> url(r'^naviforward(?P[\w]+)/(?P[\*\w]+)/(?P[\w]+)/$','manager.views.navforward'),
>> 
>> url(r'^edit/(?P[\w]+)/(?P[\*\w]+)/(?P[\.\w]+)$','manager.views.editdata'),
>> 
>> url(r'^saveandsend/(?P[\w]+)/(?P[\*\w]+)/(?P[\.\w]+)$','manager.views.senddata'),
>> 
>> url(r'^upload/(?P[\w]+)/(?P[\*\w]+)/$','manager.views.uploadfile'),
>> 
>> url(r'^delete/(?P[\w]+)/(?P[\*\w]+)/(?P[\.\w]+)$','manager.views.deletefile'),
>> ]
>>
>> my views.py inside:
>>
>>
>> 
>>
>>
>> https://postimg.org/image/s2c60qr2d/
>>
>>
>> views.py inside for ssh connection and sftp connection : 
>>
>>
>> 
>>
>> https://postimg.org/image/635rdjhxx/
>>
>>
>> my routing to html file inside:
>>
>>{% if path != orginalpath %} 
>>   http://127.0.0.1:8000/navback/{{ server }}/{{ modpath }}/">
>> 
>>  {% endif %} {% for d in dirs %} 
>>  
>> 
>> 
>> http://127.0.0.1:8000/naviforward/{{ server }}/{{ 
>> modpath }}/{{ d }}/">{{ d }} 
>>
>>  
>> {% endfor %} 
>>  
>>
>>
>> if you're access to project and image you can be look in link:
>>
>>
>> 
>>
>> https://postimg.org/gallery/3iakj1t7a/
>>
>>
>> 
>>
>> https://gitlab.com/rection/Cloud-Panel-Django.git
>>
>>
>> How to be solution my problem? 
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/d0d88a09-272b-494d-a1eb-a25cd77a5ffd%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/8fc2f9ff-6510-428d-a5d0-bb479e5a47f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
{% extends 'base.html' %} {% block title %}Manage Server{% endblock%} {% block Content %}



		


		Save 
		
		Exit




Current Path : {{ path }}



Folder



Files



	Upload File

	
	
		
			

	×
	Upload File

	

Re: Making an object unsaveable ...

[Dan Tagg]

Two possibilities spring to mind

1. Don't grant django's database user the right to update the relevant
table. If you take this approach you'll need to catch any errors if anyone
writes code to attempt to do this

2. Use signals to catch any save attempts. This is easily circumvented.

On 4 March 2018 at 09:41, Bernd Wechner  wrote:

> An interesting question I've not been able to solve reading docs or
> Googling. As every posting here only after some serious research efforts
> including class inspections ;-). But am stumped and wonder if anyone else
> has any ideas.
>
> Here is the use case:
>
>1. Load an object from database
>2. Flag it as unsaveable, not to be written back to database under any
>circumstances
>3. Make changes to the object (its fields)
>4. Present a detail view of the object.
>
> Basically, would like the freedom to change an object knowing the database
> is secure.
>
> As ever, am more interested in how to do this, than questioning why to do
> it. It may not be possible in which case fear not, I'm on top of the why's
> and can look at alternative strategies. But this use case provides an easy
> way of injecting some filters in one place of a code body I have without
> changing any of the views or other code. Simply one small hook I place into
> extant code, which will play around with the object (making translations
> for example). But in order to do so would want to know this cannot be
> written back to the database, that from here on in, it's for display
> purposes only.
>
> Have a suspicion after some research that this can't be done. In which
> case there's a second and almost as useful use case:
>
>1. Load an object from database
>2. Make a copy, that is unsaveable, not to be written back to database
>under any circumstances
>3. Make changes to the copy (its fields)
>4. Present a detail view of the copy.
>
> This has some slightly better chance of being possible. If not as well,
> yes indeed, I have to dive into the view itself and put hooks into each
> field as it renders I guess. Which is life. But would seem useful to do it
> with one of these use cases (again no need to discuss the merits of one
> approach over the other at all, am more interested in possibility -
> projects have huge amounts of context not readily shareable that influence
> the relative merits of one approach over another of course.
>
> Regards,
>
> Bernd.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-users/9162bad4-935a-ed39-d2d8-a001103ec705%40gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Wildman and Herring Limited, Registered Office: 28 Brock Street, Bath,
United Kingdom, BA1 2LN, Company no: 05766374

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAPZHCY7BciY%2B5JRQ2o%2B8eiLMVfCfg6boR0g_Fc8ymqO_E1EU_Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: The cloud panel doesn't into directory in django

[Jason]

I suspect it's due to the aserisks (*) in your URL with *root*.  

Remove that, and change (?P[\*\w]+)/  to (?P[\w]+)/

While an asterisk is a valid character in the URL, I've never seen it used 
in practice.  Your experiences here make me suspect you're not escaping 
*both* asterisks, and thus the issue.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/242a18b1-a70a-4057-b200-f4d95b0a67fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The cloud panel doesn't into directory in django

[Safa Bayar]

4 Mart 2018 Pazar 15:11:46 UTC+3 tarihinde Jason yazdı:
>
> I suspect it's due to the aserisks (*) in your URL with *root*.  
>
> Remove that, and change (?P[\*\w]+)/  to (?P[\w]+)/
>
> While an asterisk is a valid character in the URL, I've never seen it used 
> in practice.  Your experiences here make me suspect you're not escaping 
> *both* asterisks, and thus the issue.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/12a9b228-7e4c-4210-814e-8c388e02ca84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The cloud panel doesn't into directory in django

[Safa Bayar]

you're right. i am mistake. i try to your say but doesn't work. i changed 
althought it is not change. why did this made? i don't understand.


4 Mart 2018 Pazar 15:11:46 UTC+3 tarihinde Jason yazdı:
>
> I suspect it's due to the aserisks (*) in your URL with *root*.  
>
> Remove that, and change (?P[\*\w]+)/  to (?P[\w]+)/
>
> While an asterisk is a valid character in the URL, I've never seen it used 
> in practice.  Your experiences here make me suspect you're not escaping 
> *both* asterisks, and thus the issue.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/a66df368-9d61-4509-9cf4-6a40aadd87bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels AuthMiddleware question

[Hugo Castilho]

The example in the Channels documentation shows it being used with a 
consumer called consumers.AsyncChatConsumer which suggests it's safe to use 
with async consumers.
There probably should be a note there that it's currently not safe to use 
with async consumers no?

Regarding the SessionMiddleware wouldn't this be part a more general 
problem with routers? As it is they currently have to be async "safe".


On Sunday, March 4, 2018 at 3:03:05 AM UTC, Andrew Godwin wrote:
>
> Hi Hugo,
>
> The AuthMiddleware, like its Django counterpart, does not query the auth 
> backend immediately - it is lazily done the first time you access the 
> scope["user"] object. This does present a risk that you could access it 
> during an async method body, though - I will look into how we could fix 
> this (it might mean making it non-lazy, but I don't quite know yet).
>
> The SessionMiddleware does have the problem you suggest, though - I have 
> opened this issue to track it: 
> https://github.com/django/channels/issues/949
>
> Andrew
>
> On Sat, Mar 3, 2018 at 5:49 PM, Hugo Castilho  > wrote:
>
>>
>> Hi all,
>>
>> The channels authentication documentation (
>> https://channels.readthedocs.io/en/latest/topics/authentication.html) 
>> shows using the channels AuthMiddleware with an AsyncConsumer.
>>
>> Now, my problem is that all session backends in Django are blocking.
>> I know that the user is only retrieved lazily but from what I understand 
>> this only means that instead of the blocking call happening during the 
>> instantiation of the application in daphne.Server.create_application it 
>> will happen in the AsyncConsumer.
>> Either way the call will be made in the event loop.
>> Are we not stopping the event loop for the first time every connection 
>> accesses request.user?
>> I'm sure I'm missing something here.
>>
>> Thanks!
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/f9a7ec05-7d54-4459-a08a-20d6a931c8a3%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/430b86ac-d0d7-4d50-b32d-89f2bd117b0a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Djangonauts: say no to selenium drug

[Jamesie Pic]

Hello everybody,

This is a message coming from the deepest of my heart.

When you start applying best development practices such as TDD, you
discover that you make much better software.

First, you can TDD your python code with anything, django has a test
runner, otherwise you have pytest and many friends.

Then, you make python to interact with javascript. In the Django community,
it seems that there is a conscensus around “use selenium to test your JS”.
I’ve been like this myself for years, but the thing with selenium is that
it’s functional testing, not unit testing, it does bring short term ROI,
but on the long term it becomes costy to maintain over time.

And lets face it: have 100% unit test coverage of your code first, then
think of functional testing. If you’re doing functional testing on some JS
code which has 0 unit test: you’re clearly wasting a lot of efforts on the
long run. Selenium is always going to ask for more attention, unit tests
are fast and have low resource requirements which make them perfect to run
on free services such as travis or circle.

The reality seems to be that most backend developers who are able to
produce quality backend code have hard times creating quality JS code. I
see this all the time:

   - django-dynamic-fields, until the current rewrite
   

   ,
   - django-autocomplete-light,
   - it’s the case for django-material js,
   - same for nagare framework js

And i’m not here to criticize django-material or nagare, i LOVE both, but
let’s be honest: our JS is not up to our Python in terms of quality.

To be completely honest, i’m writing this for me because I’m guilty as
everyone else, because i’m never falling in the trap again from now on. I
don’t see any excuse to not TDD JS and rely on functional tests instead,
it’s my fault and all I can honestly do about it is become a proper JS
developer, and apply the same design principles which help me make better
Python code.

Django itself, is even historically affraid of supporting any kind of JS
integration outside their famous admin app. So your Django app out of the
box will be usable as something from the Web 1.0 era. And really, I LOVE
Django, but I’m also honest about it.

This is my invitation to break the pattern: say no to selenium code. Please
TDD your JS code and release it as an NPM module, nowadays JS has all the
ecosystem like Python with package managers, unit testing libraries -
sometimes even better than Python.

And please, do go ahead and dump Python objects into JSON to pilot your JS
code, it’s easy to unit test on both sides, instead of wasting your time
with selenium.

With LOVE
https://blog.yourlabs.org/post/171520206623/djangonauts-say-no-to-selenium-drug

-- 
∞

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAC6Op19fepfsiamoCv7PAShxe%3D8bVpLSfCX1-CtsvhQjH5yfcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels AuthMiddleware question

[Andrew Godwin]

This is a problem with _any_ ASGI app, not just middleware - doing blocking
things in the __init__ is bad.

I will look at the docs when I look at solving the SessionMiddleware
problem as well, as the two are linked.

Andrew

On Sun, Mar 4, 2018 at 7:10 AM, Hugo Castilho  wrote:

>
>
> The example in the Channels documentation shows it being used with a
> consumer called consumers.AsyncChatConsumer which suggests it's safe to use
> with async consumers.
> There probably should be a note there that it's currently not safe to use
> with async consumers no?
>
> Regarding the SessionMiddleware wouldn't this be part a more general
> problem with routers? As it is they currently have to be async "safe".
>
>
> On Sunday, March 4, 2018 at 3:03:05 AM UTC, Andrew Godwin wrote:
>>
>> Hi Hugo,
>>
>> The AuthMiddleware, like its Django counterpart, does not query the auth
>> backend immediately - it is lazily done the first time you access the
>> scope["user"] object. This does present a risk that you could access it
>> during an async method body, though - I will look into how we could fix
>> this (it might mean making it non-lazy, but I don't quite know yet).
>>
>> The SessionMiddleware does have the problem you suggest, though - I have
>> opened this issue to track it: https://github.com/django/
>> channels/issues/949
>>
>> Andrew
>>
>> On Sat, Mar 3, 2018 at 5:49 PM, Hugo Castilho  wrote:
>>
>>>
>>> Hi all,
>>>
>>> The channels authentication documentation (https://channels.readthedocs.
>>> io/en/latest/topics/authentication.html) shows using the channels
>>> AuthMiddleware with an AsyncConsumer.
>>>
>>> Now, my problem is that all session backends in Django are blocking.
>>> I know that the user is only retrieved lazily but from what I understand
>>> this only means that instead of the blocking call happening during the
>>> instantiation of the application in daphne.Server.create_application it
>>> will happen in the AsyncConsumer.
>>> Either way the call will be made in the event loop.
>>> Are we not stopping the event loop for the first time every connection
>>> accesses request.user?
>>> I'm sure I'm missing something here.
>>>
>>> Thanks!
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-users...@googlegroups.com.
>>> To post to this group, send email to django...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-users.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/django-users/f9a7ec05-7d54-4459-a08a-20d6a931c8a3%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-users/430b86ac-d0d7-4d50-b32d-89f2bd117b0a%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFwN1urLP41zbpooSq7RWcXbK1qaiJXbOR_znuNfu9uzT7eBgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Django server and client communications

[Richard Maceček]

Hello, I need help with client and server communications. Web Application - 
Djang Server Side. The client is written in python, it's actually a KODI 
add-on.

They need to deal with:
 1. client authorization,
 2. communications,
 3. data transfer.

I need to send the data I receive from the client to the server.

What would I use? I was thinking about JSON (websocket) or XML. Or 
Django-rest-framework? Another idea?

Thank you Best regards 
M.R

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/61ee09a1-ae0e-4415-9180-9702020e73ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django server and client communications

[Avraham Serour]

I suggest using DRF, It can autogenerate the schema which can be useful.

It seems they also have a client to consume that, worth taking a look

On 4 Mar 2018 21:58, "Richard Maceček"  wrote:

> Hello, I need help with client and server communications. Web Application
> - Djang Server Side. The client is written in python, it's actually a KODI
> add-on.
>
> They need to deal with:
>  1. client authorization,
>  2. communications,
>  3. data transfer.
>
> I need to send the data I receive from the client to the server.
>
> What would I use? I was thinking about JSON (websocket) or XML. Or
> Django-rest-framework? Another idea?
>
> Thank you Best regards
> M.R
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-users/61ee09a1-ae0e-4415-9180-9702020e73ec%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFWa6t%2B-OyTYBfANt0d8Kb1GVmALPUNGctgz8xagsTg47o%3DYgA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making an object unsaveable ...

[Bernd Wechner]

Thanks Dan,

I was actually thinking also last night of:

3. Override the save() method on the model.

Not tested, not sure how robust, but as it happens there's a hook there 
already as all the models I'm work with have it overridden with tiny method 
that updates some admin fields like last_updated and last_updated_by. This 
could be a nice place for a small hook.

Signals are an idea too, and want to explore them as much for the heck of 
it and learning as anything. But I wonder what you mean by "This is easily 
circumvented." - I'm guessing that even if you catch a signal prior to save 
and do something, there's no guarantee some downstream code won't do a 
save. I wonder if overriding save() is more secure, or if there's any 
possibility other code could go around such an override.

Regards,

Bernd.

On Sunday, 4 March 2018 22:24:38 UTC+11, Dan Tagg wrote:
>
> Two possibilities spring to mind
>
> 1. Don't grant django's database user the right to update the relevant 
> table. If you take this approach you'll need to catch any errors if anyone 
> writes code to attempt to do this
>
> 2. Use signals to catch any save attempts. This is easily circumvented. 
>
> On 4 March 2018 at 09:41, Bernd Wechner 
> > wrote:
>
>> An interesting question I've not been able to solve reading docs or 
>> Googling. As every posting here only after some serious research efforts 
>> including class inspections ;-). But am stumped and wonder if anyone else 
>> has any ideas.
>>
>> Here is the use case:
>>
>>1. Load an object from database 
>>2. Flag it as unsaveable, not to be written back to database under 
>>any circumstances 
>>3. Make changes to the object (its fields) 
>>4. Present a detail view of the object. 
>>
>> Basically, would like the freedom to change an object knowing the 
>> database is secure. 
>>
>> As ever, am more interested in how to do this, than questioning why to do 
>> it. It may not be possible in which case fear not, I'm on top of the why's 
>> and can look at alternative strategies. But this use case provides an easy 
>> way of injecting some filters in one place of a code body I have without 
>> changing any of the views or other code. Simply one small hook I place into 
>> extant code, which will play around with the object (making translations 
>> for example). But in order to do so would want to know this cannot be 
>> written back to the database, that from here on in, it's for display 
>> purposes only.
>>
>> Have a suspicion after some research that this can't be done. In which 
>> case there's a second and almost as useful use case:
>>
>>1. Load an object from database 
>>2. Make a copy, that is unsaveable, not to be written back to 
>>database under any circumstances 
>>3. Make changes to the copy (its fields) 
>>4. Present a detail view of the copy. 
>>
>> This has some slightly better chance of being possible. If not as well, 
>> yes indeed, I have to dive into the view itself and put hooks into each 
>> field as it renders I guess. Which is life. But would seem useful to do it 
>> with one of these use cases (again no need to discuss the merits of one 
>> approach over the other at all, am more interested in possibility - 
>> projects have huge amounts of context not readily shareable that influence 
>> the relative merits of one approach over another of course.
>>
>> Regards,
>>
>> Bernd.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/9162bad4-935a-ed39-d2d8-a001103ec705%40gmail.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Wildman and Herring Limited, Registered Office: 28 Brock Street, Bath, 
> United Kingdom, BA1 2LN, Company no: 05766374
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5e292463-504b-41db-984f-86a25d8c36b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Customizing mode loading ...

[Bernd Wechner]

Found this lovely doc:

https://docs.djangoproject.com/en/2.0/ref/models/instances/#customizing-model-loading

But it leaves me with a thirst for more knowledge. My conclusion form 
reading it is, that if I wanted to put a hook into some custom code that 
always ran after data was loaded from the database, and after the model 
instance is created (populated with data) I would need to dos something 
like:

class Book(models.Model):
title = models.CharField(max_length=100)

@classmethod
def create(cls, title):
book = super().create(cls, title)
# hook to custom code here
return book

@classmethod
def from_db(cls, db, field_names, values):
book = super().from_db(cls, db, field_names, values)
# hook to custom code here
return book

def refresh_from_db(self, using=None, fields=None, **kwargs):
super().refresh_from_db(using, fields, **kwargs)
# hook to custom code here

Taking note that the last of these is an instance method and the first two are 
class methods and returns nothing.

The documentation is not very clear in this space.

If that hook took the simple form of:

if hasattr(book_or_self, "_post_load") and callable(book_or_self._post_load):
 book_or_self._post_load(book_or_self)

Then defining a model method _post_load(self) would provide a place to put code 
that ran reliably before any other code could inspect the instance?

It seems a little clunky almost as if it would be neater if there were a signal 
issued at that point in time by django base, but could be tidied up by writing 
a new model class that derives from models.Model, like ModelWithPostLoadHooks 
and deriving a model from that if it wanted to have such hooks.

Musing here, and wondering if I have it right. 

Bernd.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/9c2b8368-6620-4387-83a7-f52390a0e921%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

YesNoWidget(CheckBoxInput) widget woes

[Mike Dewhirst]

In some training software a student can use 'Yes', 'No' or any other 
string as valid answers for up to six questions in a set and all of them 
have to be answered correctly to get a score. When checking student 
answers against the set answers, we ignore case and punctuation and 
leading zeroes if the answers are numeric.


I want to use a checkbox widget if all the answers (up to six) are 'Yes' 
or 'No' . If any of the answers don't fit the mould we use an ordinary 
input field.


I cannot get the following widget working and wonder if someone can help?

class YesNoWidget(CheckboxInput): """ from 
https://docs.djangoproject.com/en/1.11/_modules/django/forms/widgets/#CheckboxInput 
""" def value_from_datadict(self, data, files, name): #print('29 
forms.py self= %s\n Name=%s\n data=%s' % (self, name, data)) if name not 
in data: # A missing value means False because HTML form submission does 
not # send results for unselected checkboxes. return False value = 
data.get(name) # Translate true and false strings to boolean values. 
values = {'true': True, 'false': False} if isinstance(value, 
six.string_types): value = values.get(value.lower(), value) if 
bool(value) == True: return 'Yes' return '' def 
value_omitted_from_data(self, data, files, name): # HTML checkboxes 
don't appear in POST data if not checked, so it's # never known if the 
value is actually omitted. return ''


This visibly renders properly and returns 'Yes' when the checkbox is 
checked but triggers errors (see below) which I don't want.


[05/Mar/2018 15:53:32] "POST /question/115/ HTTP/1.1" 200 3739 
Answer a:class="errorlist">Select a valid choice. Yes is not one of the 
available choices.value="Yes" id="id_answer_a" checked /> for="id_answer_b">Answer b:class="errorlist">Select a valid choice. Yes is not one of the 
available choices.value="Yes" id="id_answer_b" checked /> for="id_answer_c">Answer c:class="errorlist">Select a valid choice. False is not one of the 
available choices.id="id_answer_c" /> for="id_answer_d">D:maxlength="32" id="id_answer_d" /> for="id_answer_e">E:maxlength="32" id="id_answer_e" /> for="id_answer_f">F:maxlength="32" id="id_answer_f" />


The correct answers for the first two are 'Yes' or 'yes' or 'y' the 
correct answer for the third is 'No', 'no', 'n' or ''


I understand that unchecked checkboxes are omitted from the POST data 
and get converted to False. My mission is to convert them to nothing or 
'No' and to make my valid choices valid so we don't get an errorlist.


Thanks for any ideas

Mike

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/8de1204c-10de-1f2b-f26c-c80c8b949748%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1,11 upgrade, render template with context in template.Node

[Bernd Wechner]

Can't say I'm experienced with template.Node, but you piqued my curiosity 
so I found this:

https://stackoverflow.com/questions/14434624/how-to-get-dictionary-of-requestcontext-imported-from-django-template

which may help, but am left wondering why upgrade to 1.11 when 2.0 is out 
already and the way to go? I'm on 1.11 and about to move to 2.0.

Regards,

Bernd.

On Saturday, 3 March 2018 06:26:46 UTC+11, Christian Ledermann wrote:
>
> In Django 1,8 it  worked but in Django 1.11 it throws: 
>
> TypeError: context must be a dict rather than RequestContext. 
>
> The code is: 
>
> class EpilogueNode(template.Node): 
>
> def __init__(self):  # noqa: D102 
> self.epilogue_template = 
> template.loader.get_template('themes/presenter_epilogue.html') 
>
> def render(self, context):  # noqa: D102 
> rendered = self.epilogue_template.render(context) 
>
> In https://docs.djangoproject.com/en/1.11/ref/templates/upgrading/ it 
> is documeted that I need to pass a dict as context, but the context 
> passed to Node,render is a 
> RequestContext. 
>
> How can I upgrade this to 1.11? 
>
>
>
> -- 
> Best Regards, 
>
> Christian Ledermann 
>
> Newark-on-Trent - UK 
> Mobile : +44 7474997517 
>
> https://uk.linkedin.com/in/christianledermann 
> https://github.com/cleder/ 
>
>
> <*)))>{ 
>
> If you save the living environment, the biodiversity that we have left, 
> you will also automatically save the physical environment, too. But If 
> you only save the physical environment, you will ultimately lose both. 
>
> 1) Don’t drive species to extinction 
>
> 2) Don’t destroy a habitat that species rely on. 
>
> 3) Don’t change the climate in ways that will result in the above. 
>
> }<(((*> 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/0d289efe-614b-4fa8-ad87-87d559b6aaa3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making an object unsaveable ...

[Derek]

I think the second case is more manageable; I'd actually have a second 
table that has an exact duplicate structure of the first. Then you can save 
your newly changed copy into that -- and delete the record just afterward, 
or even  much later,  if you need to. 

I cannot imagine a scenario in which somone would do a lot of work and then 
not save it (even temporarily). 

On Sunday, 4 March 2018 11:43:06 UTC+2, Bernd Wechner wrote:
>
> An interesting question I've not been able to solve reading docs or 
> Googling. As every posting here only after some serious research efforts 
> including class inspections ;-). But am stumped and wonder if anyone else 
> has any ideas.
>
> Here is the use case:
>
>1. Load an object from database 
>2. Flag it as unsaveable, not to be written back to database under any 
>circumstances 
>3. Make changes to the object (its fields) 
>4. Present a detail view of the object. 
>
> Basically, would like the freedom to change an object knowing the database 
> is secure. 
>
> As ever, am more interested in how to do this, than questioning why to do 
> it. It may not be possible in which case fear not, I'm on top of the why's 
> and can look at alternative strategies. But this use case provides an easy 
> way of injecting some filters in one place of a code body I have without 
> changing any of the views or other code. Simply one small hook I place into 
> extant code, which will play around with the object (making translations 
> for example). But in order to do so would want to know this cannot be 
> written back to the database, that from here on in, it's for display 
> purposes only.
>
> Have a suspicion after some research that this can't be done. In which 
> case there's a second and almost as useful use case:
>
>1. Load an object from database 
>2. Make a copy, that is unsaveable, not to be written back to database 
>under any circumstances 
>3. Make changes to the copy (its fields) 
>4. Present a detail view of the copy. 
>
> This has some slightly better chance of being possible. If not as well, 
> yes indeed, I have to dive into the view itself and put hooks into each 
> field as it renders I guess. Which is life. But would seem useful to do it 
> with one of these use cases (again no need to discuss the merits of one 
> approach over the other at all, am more interested in possibility - 
> projects have huge amounts of context not readily shareable that influence 
> the relative merits of one approach over another of course.
>
> Regards,
>
> Bernd.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/42be8668-a288-410c-a2c0-5f933e5d4d41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.