Access specific ModelForm field option within array of ModelForms for use with .js
Hello,
I have the following situation:
I am rendering an array of ModelForms to my template. ie. formArray =
[, , ]
In the template I display the forms with the following:
{% for form in formArray %}
{{ form }}
{% endfor %}
Previously I have accessed certain ModelForms using {% if forloop.counter
== # %} to add some customization.
However, now I would like more detailed control of certain field tags
within a given ModelForm. ie. ModelForm2 is a RadioSelect, and I would like
to add an onChange="some function" to one of the Radio Buttons within this
ModelForm.
Is there a way to access this specific field in my implementation directly?
Or, through the use of a custom template filter?
To give the larger picture my goal is to have an "Other" RadioButton that
when selected shows a Other text input using javascript, but while using
ModelForms.
As such, if there is an entirely different way to going about this I would
love to hear it.
Any help would be greatly appreciated!
JD
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/OVPO5oqiXc4J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Access specific ModelForm field option within array of ModelForms for use with .js
You're right!
Thank you.
I have a custom template filter in the app to format the radio options a
certain way and I can just add this in to pick out the ones needing the
additional onChange.
JD
On Tuesday, May 1, 2012 9:27:01 PM UTC-6, jondykeman wrote:
>
> Hello,
>
> I have the following situation:
>
> I am rendering an array of ModelForms to my template. ie. formArray =
> [, , ]
>
> In the template I display the forms with the following:
>
> {% for form in formArray %}
>
> {{ form }}
>
> {% endfor %}
>
> Previously I have accessed certain ModelForms using {% if forloop.counter
> == # %} to add some customization.
>
> However, now I would like more detailed control of certain field tags
> within a given ModelForm. ie. ModelForm2 is a RadioSelect, and I would like
> to add an onChange="some function" to one of the Radio Buttons within this
> ModelForm.
>
> Is there a way to access this specific field in my implementation
> directly? Or, through the use of a custom template filter?
>
> To give the larger picture my goal is to have an "Other" RadioButton that
> when selected shows a Other text input using javascript, but while using
> ModelForms.
>
> As such, if there is an entirely different way to going about this I would
> love to hear it.
>
> Any help would be greatly appreciated!
>
>
> JD
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/R26wVKtkf1YJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
form resubmit on refresh problem
Hello, I have a form submission problem I can't seem to figure out a way around. Normally, once a form was submitted I would HttpResponseRedirect() to the main page. However, there is something I can't seem to make work with this approach. The form is being completed/submitted in the context of an "active account" ie. there is a hidden form field "account" with value="account #" So when the form is submitted the view saves the data to that account #. Once the new form data is saved I would like it to reload to that accounts summary page. ie. the summary view needs to be passed the account # This is where my issue arises. I know this would be easy to pass the HttpResponseRedirect() the view with args=(account#,) yielding an appropriate summary page of eg. /summary/account3/ The kicker is I can't pass any account information through the urls so there can only ever be a /summary/ url. The other views all work by passing around the account # through POST. However, using this method to end the form save view allows the user to reload the page and resubmit the form. Any help would be greatly appreciated!! Thanks, JD -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/vgotOZTs3KIJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: help with foreignkeys
As far as I understand it the ForeignKey will have to be unique=True and null=False. I want to get a better sense of what you are trying to achieve. Is it that you want to link comment and park only some of the time? JD On Sunday, May 13, 2012 7:41:39 PM UTC-6, psychok7 wrote: > > so i have this 2 models (Comment and Park) > > Comment has a foreign key to USER and PARK > > PARK has a foreign key to Comment > > my question is, isn't there going to be a deadlock if i don't have a > comment or a park created? i mean , in order to create a Park i need to > have a comment, and in order to create a comment i need a park and a user. > > is there a way for me to fix my problem? like allowing the foreign key to > be null or something like that? > > thanks in advance > -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/5DSX-Ls64boJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: help with foreignkeys
If all comment have to have a park and user. I would have a ForeignKey to Park and User in the Comments model, and no Foreign key in the Parks model. As such a comment will always need to be linked to an existing park and user object, but a park can be created without needing a comment. JD On Sunday, May 13, 2012 7:53:58 PM UTC-6, psychok7 wrote: > > yes, like a park doesn't have to have comments, but all the comments must > have an associated park and user all the time. > > what is the django syntax for me to achieve this? > > On Monday, May 14, 2012 2:49:18 AM UTC+1, jondykeman wrote: >> >> As far as I understand it the ForeignKey will have to be unique=True and >> null=False. >> >> I want to get a better sense of what you are trying to achieve. Is it >> that you want to link comment and park only some of the time? >> >> JD >> >> On Sunday, May 13, 2012 7:41:39 PM UTC-6, psychok7 wrote: >>> >>> so i have this 2 models (Comment and Park) >>> >>> Comment has a foreign key to USER and PARK >>> >>> PARK has a foreign key to Comment >>> >>> my question is, isn't there going to be a deadlock if i don't have a >>> comment or a park created? i mean , in order to create a Park i need to >>> have a comment, and in order to create a comment i need a park and a user. >>> >>> is there a way for me to fix my problem? like allowing the foreign key >>> to be null or something like that? >>> >>> thanks in advance >>> >> -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/ArUqOsM142QJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: form resubmit on refresh problem
Thanks so much. I looked into the documentation and that is exactly what I
will use.
I have two followup questions:
1) I have a main page that is a table of accounts where the user selects
the account they want to edit. Currently the table is in a form and I just
have the values of the radiobuttons rendered as value={{ account.number }},
and so it is passed via a POST to the initial "active account page". Is
there a way to get rid of this POST as well? (as I can see how to get rid
of all the rest using sessions). ie. a way to make the selection of an
account set the account number in the session.
2) How should I go about selecting which type of session is best for me to
use?
Thanks again!
JD
On Sunday, May 13, 2012 7:39:53 PM UTC-6, jondykeman wrote:
>
> Hello,
>
> I have a form submission problem I can't seem to figure out a way around.
>
> Normally, once a form was submitted I would HttpResponseRedirect() to the
> main page.
>
> However, there is something I can't seem to make work with this approach.
>
> The form is being completed/submitted in the context of an "active
> account" ie. there is a hidden form field "account" with value="account #"
>
> So when the form is submitted the view saves the data to that account #.
>
> Once the new form data is saved I would like it to reload to that accounts
> summary page. ie. the summary view needs to be passed the account #
>
> This is where my issue arises. I know this would be easy to pass
> the HttpResponseRedirect() the view with args=(account#,) yielding an
> appropriate summary page of eg. /summary/account3/
>
> The kicker is I can't pass any account information through the urls so
> there can only ever be a /summary/ url. The other views all work by passing
> around the account # through POST. However, using this method to end the
> form save view allows the user to reload the page and resubmit the form.
>
> Any help would be greatly appreciated!!
>
> Thanks,
>
> JD
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/_rTZp251QgoJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
favourite reusable apps
Hi Everyone, I have found when getting into Django that at least once a month I find a reusable app that replaces the need for what I had spent the last ~2 weeks figuring out how to write myself. As such, I thought it might be nice to start a thread of everyone's favourite / most useful apps that they find themselves re-using over and over again. If I were to start it off I would go with django-extensions (https://github.com/django-extensions/django-extensions/) for some very useful additional commands via ./manage.py that come in handy with almost every project. JD -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/bPDnMm6WAekJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Announcement of GUI for Creating Models
Timothy - I am implementing something similar (Model GUI.png attached) that is within a larger structure that not only generates models.py, but registers them to the admin, builds the modelforms, and generates JS logic etc. Rather than such a thing being useful for developers I have found it great to be able to use non-programmers to basically build the first 70% of apps I work on. Also, fyi - Mezzanine comes with something similar (also attached), but more dynamic in the sense that the models are never actually written out - they are stored in a table, the forms are rendered off the table, and the information is saved FK to the field in a separate table. Let me know if you want to discuss what we each have done a little more to see if we can learn anything from each other's experiences. JD On Saturday, September 8, 2012 8:31:00 PM UTC-6, Alec Taylor wrote: > > Kurtis: That looks very interesting; just finished reading it. > > I wouldn't recommend this for Timothy though; it looks like something > which will require a large team to develop. > > Maybe submit it as a project proposal to Canonical? > > Or post on Django-Dev [and here] to see if you can get a large + > skilled enough team to build such a system. > > On Sun, Sep 9, 2012 at 6:41 AM, Kurtis Mullins > > > wrote: > > You could take it a few steps farther and reproduce some work done by a > > doctor(now) I used to go to school with. > > > > http://knoesis.wright.edu/research/srl/projects/mobicloud/ > > > > > > On Sat, Sep 8, 2012 at 2:50 PM, Javier Guerra Giraldez < > jav...@guerrag.com > > > wrote: > >> > >> On Fri, Sep 7, 2012 at 9:42 PM, Timothy Clemans > >> > wrote: > >> > I've developed a GUI for creating models, see > >> > https://github.com/timothyclemans/django-admin-models-editor > >> > > >> > Would this be helpful for developers? Would it be useful for you? > Should > >> > I > >> > keep developing it? What features would you like to see added? > >> > >> personally, i much prefer the reverse approach: i write the models, > >> and a tool (ie. django-extensions) generates a graphical > >> representation. > >> > >> pros: > >> - the final models are exactly what i want them to be. even if the > >> graphical tool doesn't support some obscure Django feature, i can > >> still use it; it's just not shown graphically. > >> > >> - i don't have to learn a different (graphical) language > >> > >> - i keep fluent in the real Django language, so i don't have to > >> relearn it when for any reason i don't have to use that tool. > >> > >> cons: > >> - less sexy than not writing code > >> > >> -- > >> Javier > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Django users" group. > >> To post to this group, send email to > >> django...@googlegroups.com. > > >> To unsubscribe from this group, send email to > >> django-users...@googlegroups.com . > >> For more options, visit this group at > >> http://groups.google.com/group/django-users?hl=en. > >> > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "Django users" group. > > To post to this group, send email to > > django...@googlegroups.com. > > > To unsubscribe from this group, send email to > > django-users...@googlegroups.com . > > For more options, visit this group at > > http://groups.google.com/group/django-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/M6DSZabzv9QJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en. <><>
Re: Announcement of GUI for Creating Models
Also, I saw on your github that you are looking for choices support. Just to give my insight I have implemented the attached for adding choices. It is ajax via a modal that pre-populates existing options and allows for creation and deletion of options for that field on the fly. JD On Sunday, September 9, 2012 8:37:48 AM UTC-6, jondykeman wrote: > > Timothy - I am implementing something similar (Model GUI.png attached) > that is within a larger structure that not only generates models.py, but > registers them to the admin, builds the modelforms, and generates JS logic > etc. > > Rather than such a thing being useful for developers I have found it great > to be able to use non-programmers to basically build the first 70% of apps > I work on. > > Also, fyi - Mezzanine comes with something similar (also attached), but > more dynamic in the sense that the models are never actually written out - > they are stored in a table, the forms are rendered off the table, and the > information is saved FK to the field in a separate table. > > Let me know if you want to discuss what we each have done a little more to > see if we can learn anything from each other's experiences. > > JD > > > On Saturday, September 8, 2012 8:31:00 PM UTC-6, Alec Taylor wrote: >> >> Kurtis: That looks very interesting; just finished reading it. >> >> I wouldn't recommend this for Timothy though; it looks like something >> which will require a large team to develop. >> >> Maybe submit it as a project proposal to Canonical? >> >> Or post on Django-Dev [and here] to see if you can get a large + >> skilled enough team to build such a system. >> >> On Sun, Sep 9, 2012 at 6:41 AM, Kurtis Mullins >> wrote: >> > You could take it a few steps farther and reproduce some work done by a >> > doctor(now) I used to go to school with. >> > >> > http://knoesis.wright.edu/research/srl/projects/mobicloud/ >> > >> > >> > On Sat, Sep 8, 2012 at 2:50 PM, Javier Guerra Giraldez < >> jav...@guerrag.com> >> > wrote: >> >> >> >> On Fri, Sep 7, 2012 at 9:42 PM, Timothy Clemans >> >> wrote: >> >> > I've developed a GUI for creating models, see >> >> > https://github.com/timothyclemans/django-admin-models-editor >> >> > >> >> > Would this be helpful for developers? Would it be useful for you? >> Should >> >> > I >> >> > keep developing it? What features would you like to see added? >> >> >> >> personally, i much prefer the reverse approach: i write the models, >> >> and a tool (ie. django-extensions) generates a graphical >> >> representation. >> >> >> >> pros: >> >> - the final models are exactly what i want them to be. even if the >> >> graphical tool doesn't support some obscure Django feature, i can >> >> still use it; it's just not shown graphically. >> >> >> >> - i don't have to learn a different (graphical) language >> >> >> >> - i keep fluent in the real Django language, so i don't have to >> >> relearn it when for any reason i don't have to use that tool. >> >> >> >> cons: >> >> - less sexy than not writing code >> >> >> >> -- >> >> Javier >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> Groups >> >> "Django users" group. >> >> To post to this group, send email to django...@googlegroups.com. >> >> To unsubscribe from this group, send email to >> >> django-users...@googlegroups.com. >> >> For more options, visit this group at >> >> http://groups.google.com/group/django-users?hl=en. >> >> >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "Django users" group. >> > To post to this group, send email to django...@googlegroups.com. >> > To unsubscribe from this group, send email to >> > django-users...@googlegroups.com. >> > For more options, visit this group at >> > http://groups.google.com/group/django-users?hl=en. >> > -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/xetCBWuznyoJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Announcement of GUI for Creating Models
with attachment. On Sunday, September 9, 2012 8:46:10 AM UTC-6, jondykeman wrote: > > Also, I saw on your github that you are looking for choices support. > > Just to give my insight I have implemented the attached for adding choices. > > It is ajax via a modal that pre-populates existing options and allows for > creation and deletion of options for that field on the fly. > > JD > > On Sunday, September 9, 2012 8:37:48 AM UTC-6, jondykeman wrote: >> >> Timothy - I am implementing something similar (Model GUI.png attached) >> that is within a larger structure that not only generates models.py, but >> registers them to the admin, builds the modelforms, and generates JS logic >> etc. >> >> Rather than such a thing being useful for developers I have found it >> great to be able to use non-programmers to basically build the first 70% of >> apps I work on. >> >> Also, fyi - Mezzanine comes with something similar (also attached), but >> more dynamic in the sense that the models are never actually written out - >> they are stored in a table, the forms are rendered off the table, and the >> information is saved FK to the field in a separate table. >> >> Let me know if you want to discuss what we each have done a little more >> to see if we can learn anything from each other's experiences. >> >> JD >> >> >> On Saturday, September 8, 2012 8:31:00 PM UTC-6, Alec Taylor wrote: >>> >>> Kurtis: That looks very interesting; just finished reading it. >>> >>> I wouldn't recommend this for Timothy though; it looks like something >>> which will require a large team to develop. >>> >>> Maybe submit it as a project proposal to Canonical? >>> >>> Or post on Django-Dev [and here] to see if you can get a large + >>> skilled enough team to build such a system. >>> >>> On Sun, Sep 9, 2012 at 6:41 AM, Kurtis Mullins >>> wrote: >>> > You could take it a few steps farther and reproduce some work done by >>> a >>> > doctor(now) I used to go to school with. >>> > >>> > http://knoesis.wright.edu/research/srl/projects/mobicloud/ >>> > >>> > >>> > On Sat, Sep 8, 2012 at 2:50 PM, Javier Guerra Giraldez < >>> jav...@guerrag.com> >>> > wrote: >>> >> >>> >> On Fri, Sep 7, 2012 at 9:42 PM, Timothy Clemans >>> >> wrote: >>> >> > I've developed a GUI for creating models, see >>> >> > https://github.com/timothyclemans/django-admin-models-editor >>> >> > >>> >> > Would this be helpful for developers? Would it be useful for you? >>> Should >>> >> > I >>> >> > keep developing it? What features would you like to see added? >>> >> >>> >> personally, i much prefer the reverse approach: i write the models, >>> >> and a tool (ie. django-extensions) generates a graphical >>> >> representation. >>> >> >>> >> pros: >>> >> - the final models are exactly what i want them to be. even if the >>> >> graphical tool doesn't support some obscure Django feature, i can >>> >> still use it; it's just not shown graphically. >>> >> >>> >> - i don't have to learn a different (graphical) language >>> >> >>> >> - i keep fluent in the real Django language, so i don't have to >>> >> relearn it when for any reason i don't have to use that tool. >>> >> >>> >> cons: >>> >> - less sexy than not writing code >>> >> >>> >> -- >>> >> Javier >>> >> >>> >> -- >>> >> You received this message because you are subscribed to the Google >>> Groups >>> >> "Django users" group. >>> >> To post to this group, send email to django...@googlegroups.com. >>> >> To unsubscribe from this group, send email to >>> >> django-users...@googlegroups.com. >>> >> For more options, visit this group at >>> >> http://groups.google.com/group/django-users?hl=en. >>> >> >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups >>> > "Django users" group. >>> > To post to this group, send email to django...@googlegroups.com. >>> > To unsubscribe from this group, send email to >>> > django-users...@googlegroups.com. >>> > For more options, visit this group at >>> > http://groups.google.com/group/django-users?hl=en. >>> >> -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/B_asYx8DCAUJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en. <>
Re: Announcement of GUI for Creating Models
Nothing is up yet - we have just been using internally where I work. It came up because we were getting too much work and couldn't find the programmers. A model (and other things) GUI really helped with getting other staff to be able to effectively contribute to app development, and left us to the finer details and more custom features being requested. It is super alpha and we just needed it working before working well - there is no editing because it was just as fast to add the value/label you were going to change to and click the delete on the pre-existing one. That being said - now planning on converting to formsets with ajax, which will allow the editing of all at once. Do you have a way of setting which fields will be associated with which of the models? I am moving onto this aspect next and was thinking of maybe doing draggable divs in a list to make it more interactive. Currently the app supports: BigIntegerField, PositiveIntegerField, DecimalField, BooleanField, RadioButton, CharField, TextField, DateField, TimeField, DateTimeField, EmailField. We use javascript to control the display of appropriate additional information fields (eg. max_length) when creating variables in the form, which is backed up by a bunch of custom validation in the modelform. JD On Sunday, September 9, 2012 5:16:54 PM UTC-6, Timothy Clemans wrote: > > Jondy: > > Is your code online? > > Attached is screenshot of adding choices. After you add a choice in > your implementation, can you change its value and label? > Do/will you support most of the field and model options? > > On Sun, Sep 9, 2012 at 7:46 AM, jondykeman > > wrote: > > with attachment. > > > > > > On Sunday, September 9, 2012 8:46:10 AM UTC-6, jondykeman wrote: > >> > >> Also, I saw on your github that you are looking for choices support. > >> > >> Just to give my insight I have implemented the attached for adding > >> choices. > >> > >> It is ajax via a modal that pre-populates existing options and allows > for > >> creation and deletion of options for that field on the fly. > >> > >> JD > >> > >> On Sunday, September 9, 2012 8:37:48 AM UTC-6, jondykeman wrote: > >>> > >>> Timothy - I am implementing something similar (Model GUI.png attached) > >>> that is within a larger structure that not only generates models.py, > but > >>> registers them to the admin, builds the modelforms, and generates JS > logic > >>> etc. > >>> > >>> Rather than such a thing being useful for developers I have found it > >>> great to be able to use non-programmers to basically build the first > 70% of > >>> apps I work on. > >>> > >>> Also, fyi - Mezzanine comes with something similar (also attached), > but > >>> more dynamic in the sense that the models are never actually written > out - > >>> they are stored in a table, the forms are rendered off the table, and > the > >>> information is saved FK to the field in a separate table. > >>> > >>> Let me know if you want to discuss what we each have done a little > more > >>> to see if we can learn anything from each other's experiences. > >>> > >>> JD > >>> > >>> > >>> On Saturday, September 8, 2012 8:31:00 PM UTC-6, Alec Taylor wrote: > >>>> > >>>> Kurtis: That looks very interesting; just finished reading it. > >>>> > >>>> I wouldn't recommend this for Timothy though; it looks like something > >>>> which will require a large team to develop. > >>>> > >>>> Maybe submit it as a project proposal to Canonical? > >>>> > >>>> Or post on Django-Dev [and here] to see if you can get a large + > >>>> skilled enough team to build such a system. > >>>> > >>>> On Sun, Sep 9, 2012 at 6:41 AM, Kurtis Mullins > > >>>> wrote: > >>>> > You could take it a few steps farther and reproduce some work done > by > >>>> > a > >>>> > doctor(now) I used to go to school with. > >>>> > > >>>> > http://knoesis.wright.edu/research/srl/projects/mobicloud/ > >>>> > > >>>> > > >>>> > On Sat, Sep 8, 2012 at 2:50 PM, Javier Guerra Giraldez > >>>> > > >>>> > wrote: > >>>> >> > >>>> >> On Fr
Re: Announcement of GUI for Creating Models
It might only come up in the context of my work, but we do a lot of data collection, and so when using the GUI all of the variables we create as destined to be part a of specific modelform. As such, we way want to end up with two forms (eg. Baseline, Purchase History) each of which will be represented in a model. We create all of the fields, and the next step is to assign which fields should go with each form ie. what models will the new fields live under, what order should they be rendered in, and what is the logic within forms. JD On Sunday, September 9, 2012 6:21:34 PM UTC-6, Timothy Clemans wrote: > > If you could open source it I would appreciate it. > > > Do you have a way of setting which fields will be associated with which > of > > the models? I am moving onto this aspect next and was thinking of maybe > > doing draggable divs in a list to make it more interactive. > > I don't understand this. Could you give examples? > -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/U5L_1Gz_qboJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
complicated permissions
Hi Everyone, I was hoping to get some input on how other people deal with complicated permission situations. I have banged my head against these concepts I think I need some fresh eyes. - User accounts can create and manage their own content. - Users that are part of the same company can view the content created by Users at the company; however, they can only edit if given permission. - Users from different companies can share their content as either read or read/write with Users at other companies. Things I have thought about are: - Of course using object level permissions - Maybe using many-to-many to assign all of the different layers groupings a record would fall under. - How to allow sharing of content outside the company - should they be able to send an invite based on e-mail to share the content? as a lookup of everyone in the system wouldn't be appropriate. - How to control the read vs. write views Any kind of help would be greatly appreciated. I have struggled to wrap my head around the "right" way for a long time. JD -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/uVfk-78yaFEJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Request for comments - django-cutemodel (model logging and field change auditing)
Hello,
I am in a very similar situation. I would in an environment that deals with
sensitive data collection. Everything has to be two-factor authenticated,
in the secure server zone etc. As part of this we need logging of every
action ever taken, by whom, when, and what the changes were.
At first I implemented my own custom solution which was less than ideal,
but it worked. That was a model of creating a new record for each field any
time there was a change to the value, but via a lot of manual checking
code.
I am not starting to migrate to a slicker solution. I am taking advantage
of django-reversion.
https://github.com/etianen/django-reversion
This provides row level auditing out of the box, and then you just need to
take advantage of the pre_commit_signal to track field changes as well.
@receiver(reversion.pre_revision_commit)
def it_worked(sender, **kwargs):
currentVersion = kwargs.pop('versions')[0].field_dict
pastVersion =
reversion.get_for_object(kwargs.pop('instances')[0])[0].field_dict
changes = set(currentVersion.items()) - set(pastVersion.items())
changedVars = []
for var in changes:
changedVars.append(var[0])
comment = "Changed: %s" % ", ".join(changedVars)
revision = kwargs.pop('revision')
revision.comment = comment
revision.save()
kwargs['revision'] = revision
Rather than the string tracking which fields I am going to switch to a dict
of changed or not for each variable.
I will check out cutemodel for sure and let you know.
Thanks,
JD
On Tuesday, September 11, 2012 3:46:54 AM UTC-6, Cal Leeming [Simplicity
Media Ltd] wrote:
>
>
>
> On Mon, Sep 10, 2012 at 11:07 PM, Kurt Pruhs
> > wrote:
>
>> Hey Cal,
>>
>> This looks like a great tool. I know I've implemented code like this in
>> another project. I was planning on doing a field change audit module for an
>> application I'm currently working on. I will definitely look at
>> django-cutemodel and see if it works for what I need, and how I can
>> contribute.
>> My current project is a time clock system for human resources to manage
>> hourly workers. We need field change auditing for security, we need the
>> ability to produce reports from it, and ability to restore from audit
>> history (in case of record tampering).
>
>
> I think django-cutemodel would be a pretty good fit for this requirement,
> although it doesn't yet have any sort of administration interface to
> produce reports, and the documentation isn't exactly great.
>
> Restore from audit history functionality is something we need for
> ourselves too, so I've raised an issue (will prob fix that sometime this
> week);
> https://github.com/foxx/django-cutemodel/issues/1
>
> We also need to have the ability to bind the Django User objects together
> with the event/field change - but some of our clients don't use the Django
> built-in user/auth stuff - so I need to have a little think about how to
> satisfy both.
> https://github.com/foxx/django-cutemodel/issues/2
>
> Basically, all actions are logged and nothing is deleted or over-written.
>> When changes are made, the original record is marked as a parent archive.
>> The modified record is a dup of the parent, but with the changes.
>>
>
> The approach of duplicating the row individually could work in some cases,
> but if there was any unique index constraints then I'm guessing the rows
> would have to be moved into a different table. If this were the case, you'd
> need twice the amount of tables, which in itself may be undesirable, plus
> another which stores the change relationships, plus any changes would have
> to be done twice.
>
> Instead, django-cutemodel doesn't require a sub-table for every model, and
> the tables don't need to be modified if one of your models changes - it has
> the following;
>
> - table map (stores unique table names) - allows for super fast lookup
> instead of full text scan
> - model map (stores unique model + app + db names) - allows for super fast
> lookup instead of full text scan
> - fieldchange (stores fieldname+old/new value, target model+pk, and
> timestamp)
> - event (stores event message, log level, target model+pk and timestamp)
>
>
>> Anyway, I'm rambling. If you would like to chat about this let me know. I
>> will update this group, or contact you when I start working on the change
>> audit code
>>
>
> Sure thing, if you think of any additional changes please feel free to
> fire them over (it'd be great to see others using this in the wild!)
>
>
>>
>> Kurt Pruhs
>> Utah State University
>> Programing & Design Team
>>
>>
>>
>>
>> On Monday, September 10, 2012 1:43:17 PM UTC-6, Cal Leeming [Simplicity
>> Media Ltd] wrote:
>>>
>>> Hi guys,
>>>
>>> We have just released a new module that allows for lightweight/easy
>>> relational event logging and auditing field changes.
>>>
>>> Our use case was to satisfy four main requirements;
>>>
>>> * Log events directly from models, whilst keeping a relational link to
>>> the row that triggered th
Re: java script alert from view after sucessfull opreation
You can feed variables back through HttpResponse() using json serializer.
eg.
from django.utils import simplejson
response = {'Name': Name, 'Email': activeUser.email}
json = simplejson.dumps(response)
return HttpResponse(json, mimetype="text/json")
You should really look into AJAX as suggested earlier.
JD
On Monday, September 17, 2012 1:29:46 AM UTC-6, JirkaV wrote:
>
> > how to use java script alert from view after sucessfull opreation in
> view
>
> Simplest way is to set some context variable (a.k.a. "flag") in the
> view (e.g. "operation_successful = True") and have a piece of JS code
> in your template that runs only when this flag is set, e.g:
>
> {% if operation_successful %}
>
> alert("operation was successful")
>
> {% endif %}
>
> There is a lot more ways to do this, at some later point you will
> probably want to read about AJAX calls.
>
> HTH
>
> Jirka
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/-mPy0os1zokJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Extending templates
Can you put the code of the template you are extending this one with?
What I would guess from what you said is that you might be using {% block
head %} {% endblock %} in the other template that extends this one.
In that case you would override that for loop. If you want to add to the
head and also retain that for loop you will need to move the for outside of
the block in the base template, but will be able to tell better once seeing
the other template's code.
JD
On Monday, September 17, 2012 1:15:25 AM UTC-6, Satinder Goraya wrote:
>
> I want to extend a template file into the other file. I get fine
> results when done simply but whenever I use the template containing
> 'for' tag into the other, it does not show any results.
> My code for template which is to be extended is here :
>
> #template file to be extended into the other
>
>
> {% block header %}
>
> {% for organisations in organisation %}
> >{{organisations.name}}
> {{organisations.address}}
> {% endfor %}
>
>
> {% endblock %}
>
> {% block content %}{% endblock %}
>
> Please see where I am going wrong.
>
> --
> Satinderpal Singh
> http://satindergoraya.blogspot.in/
> http://satindergoraya91.blogspot.in/
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/wTGigHz33vYJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Extending templates
So the header for loop is the one that is not working?
Is organisation being fed to the view properly?
If you put in {{ organisation }} in the section that is rendering properly
is it showing up as you expect?
JD
On Monday, September 17, 2012 10:59:16 AM UTC-6, Satinder Goraya wrote:
>
> On Mon, Sep 17, 2012 at 7:31 PM, jondykeman >
> wrote:
> > Can you put the code of the template you are extending this one with?
> Here is the file that is extending:
>
> {% extends "report/report_header.html" %}
> {% load i18n %}
>
>
> {% block content %}
>
>
>
> Date of testing : align="left">{{Date_of_testing}}
>
>
> Type of Structure: align="left">{{Type_of_str}}
>
>
> Site location: align="left">Latitude: {{Latitude_N}}Longitude: {{Longitude_E}}
>
>
>
> Tested in Presence of: align="left">{{Presence_1}}, {{Presence_2}}
>
>
> Report Submitted to align="left">{{Submitted_1}}, {{Submitted_2}},
> {{Submitted_3}}
>
>
>
>
>
>
> {% endblock %}
>
> You can see full file at:
> http://202.164.53.122/~satinderpal/report_ok.html
>
> > What I would guess from what you said is that you might be using {%
> block
> > head %} {% endblock %} in the other template that extends this one.
> No, i used {% block content %} {% end block %} for that
>
> > In that case you would override that for loop. If you want to add to the
> > head and also retain that for loop you will need to move the for outside
> of
> > the block in the base template, but will be able to tell better once
> seeing
> Here is the base file :
> http://202.164.53.122/~satinderpal/report_header.html
> > the other template's code.
> http://202.164.53.122/~satinderpal/report_ok.html
> >
> > JD
> >
> > On Monday, September 17, 2012 1:15:25 AM UTC-6, Satinder Goraya wrote:
> >>
> >> I want to extend a template file into the other file. I get fine
> >> results when done simply but whenever I use the template containing
> >> 'for' tag into the other, it does not show any results.
> >> My code for template which is to be extended is here :
> >>
> >> #template file to be extended into the other
> >>
> >>
> >> {% block header %}
> >>
> >> {% for organisations in organisation %}
> >> >> >{{organisations.name}}
> >> {{organisations.address}}
> >> {% endfor %}
> >>
> >>
> >> {% endblock %}
> >>
> >> {% block content %}{% endblock %}
> >>
> >> Please see where I am going wrong.
> >>
> >> --
> >> Satinderpal Singh
> >> http://satindergoraya.blogspot.in/
> >> http://satindergoraya91.blogspot.in/
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups
> > "Django users" group.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msg/django-users/-/wTGigHz33vYJ.
> > To post to this group, send email to
> > django...@googlegroups.com.
>
> > To unsubscribe from this group, send email to
> > django-users...@googlegroups.com .
> > For more options, visit this group at
> > http://groups.google.com/group/django-users?hl=en.
>
>
>
> --
> Satinderpal Singh
> http://satindergoraya.blogspot.in/
> http://satindergoraya91.blogspot.in/
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/gF9AcKpbRWsJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Can I simply disable the CSRF? crazy
+1 For doing it right from the beginning.
I was tempted to disable when trying to deal with AJAX especially early on.
Below is some code with jQuery so that you won't need to manually feed the
token through your AJAX.
jQuery(document).ajaxSend(function(event, xhr, settings) {
function getCookie(name) {
var cookieValue = null;
if (document.cookie && document.cookie != '') {
var cookies = document.cookie.split(';');
for (var i = 0; i < cookies.length; i++) {
var cookie = jQuery.trim(cookies[i]);
// Does this cookie string begin with the name we want?
if (cookie.substring(0, name.length + 1) == (name + '=')) {
cookieValue =
decodeURIComponent(cookie.substring(name.length + 1));
break;
}
}
}
return cookieValue;
}
function sameOrigin(url) {
// url could be relative or scheme relative or absolute
var host = document.location.host; // host + port
var protocol = document.location.protocol;
var sr_origin = '//' + host;
var origin = protocol + sr_origin;
// Allow absolute or scheme relative URLs to same origin
return (url == origin || url.slice(0, origin.length + 1) == origin
+ '/') ||
(url == sr_origin || url.slice(0, sr_origin.length + 1) ==
sr_origin + '/') ||
// or any other URL that isn't scheme relative or absolute i.e
relative.
!(/^(\/\/|http:|https:).*/.test(url));
}
function safeMethod(method) {
return (/^(GET|HEAD|OPTIONS|TRACE)$/.test(method));
}
if (!safeMethod(settings.type) && sameOrigin(settings.url)) {
xhr.setRequestHeader("X-CSRFToken", getCookie('csrftoken'));
}
});
On Monday, September 24, 2012 7:07:09 AM UTC-6, Mulianto wrote:
>
> hi, better use csrf for your application security.
>
> it is easier to disable it, but security for your app what you will think
> after it running later.
>
> do it correctly now or later .
>
> Rgds,
>
> Mulianto
>
> On Mon, Sep 24, 2012 at 2:56 PM, yati sagade
> > wrote:
>
>> Remove {% csrf_token %} from the form AND leave the csrf_exempt decorator
>> as it is in the view. Everyone faces challenges while learning a new thing.
>> The key is to face it head on and not to move to somewhere you think there
>> will be no challenges :)
>>
>>
>> On Mon, Sep 24, 2012 at 1:14 AM, puneet loya
>> > wrote:
>>
>>> Hi
>>>
>>> I was trying to disable csrf . I am calling post using ajax.
>>>
>>> I have used the csrf token placed it below the form.
>>>
>>> In my views file i m using the csrf exempt.
>>>
>>> I am still getting the network forbidden error. :(
>>>
>>> If you require more information i will share it :)
>>>
>>> On Thursday, 19 August 2010 06:49:02 UTC+5:30, chenge wrote:
On 8月18日, 上午4时29分, Rolando Espinoza La Fuente
wrote:
> On Tue, Aug 17, 2010 at 8:01 AM, chenge wrote:
> > I'm new to django. CSRF let me crazy!
>
> Can't use {% csrf_token %} tag inside your 's?
>
> See csrf_exempt decorator:http://docs.**djangoproject.com/en/dev/ref/
**contrib/csrf/#exceptions
>
> Regards,
>
> Rolando Espinoza La fuentewww.insophia.com
Thanks, I decide try flask first, that seems simple. Maybe I'll try
the exempt.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django users" group.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msg/django-users/-/BQ5RpafQK3EJ.
>>> To post to this group, send email to django...@googlegroups.com
>>> .
>>> To unsubscribe from this group, send email to
>>> django-users...@googlegroups.com .
>>> For more options, visit this group at
>>> http://groups.google.com/group/django-users?hl=en.
>>>
>>
>>
>>
>> --
>> Yati Sagade
>>
>> Software Engineer at mquotient
>>
>> Twitter: @yati_itay | Github:
>> yati-sagade
>>
>> Organizing member of TEDx EasternMetropolitanBypass
>> http://www.ted.com/tedx/events/4933
>>
>> https://www.facebook.com/pages/TEDx-EasternMetropolitanBypass/337763226244869
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To post to this group, send email to django...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to
>> django-users...@googlegroups.com .
>> For more options, visit this group at
>> http://groups.google.com/group/django-users?hl=en.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-
Intensive View Tracking
Hello, I'm looking for some conceptual input. I am starting to plan the development of an app utilizing highly confidential data that will need to meet certain governmental requirements. I had dealt with auditing of the data etc, but it ends up they will require a timestamped history of ever action taken by ever user. ie. User1 logged in at x. User1 went to view page. User1 used the search and searched for "Y" etc ... I searched for any pre-existing work but all I found was counting page views etc. Obviously the easiest to think of and most hideously hack job approach would just to custom save the info into a tracking table as part of every view, but this isn't the path I would like to go down. I was thinking of tying into all of the signals, but will have to look more into if this will give full coverage. Do you think signals will be the way to go? Or maybe a MiddleWare of some sort? I am hoping someone has had experience with something related. Thanks for your help, JD -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/guYY52zdFlMJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
