Wagtail - passing queryset to inline
up vote
0
down vote
favorite
I am facing a problem from days, but, no matter how much I keep searching, I could not find any solution here or anywhere in the web.
So here it is: I am developing a website for some sort of institution which offers teaching courses. I am using WAGTAIL and I am structuring the classes this way:
class Course(Page):
...
content_panels = Page.content_panels
class Exam(Page):
#fields
content_panels = Page.content_panels + [
#fields
InlinePanel('preparatory_exam', heading='Preparatory Exams'),
]
class PreparatoryExam(Orderable):
page = ParentalKey('Exam',
on_delete=models.CASCADE,
related_name = 'preparatory_exams',
)
name = models.ForeignKey(
Exam,
on_delete=models.CASCADE,
blank=True,
null=True,
related_name = 'preparatory_exam',
)
I also structured the ADMIN section PAGES this way:
COURSE_1_PAGE
-----------EXAM_1
-----------EXAM_2
------------------Prep exam 1
------------------Prep exam 2
-----------EXAM_3
...
COURSE_2_PAGE
-----------EXAM_1
-----------EXAM_2
-----------EXAM_3
....
So, the problem is: is there any way to pass a custom queryset to the inline dropdown box when choosing the preparatory exams for a certain one? What I want is to restrict the set to the exams present in the same Course.
I could do that with a limit_choices_to added to the foreignkey field, but AFAIK, it would be a "static" filter, because it would be related to the model and not to its istances, so it would be the same for every newly instantiated exam...
One first- highly unsatisfactory - solution would be to change the InlinePanel with 2-3 FieldPanels (generally an exam does not need more than 2-3 other prep exams)...
Another UGLY solution would be explicitly defining Course_1, Course_2 and so on classses, but the problem here is that every year I would have to add another class, because they set up a new course every year!
So it leaves me not a lot of choices: overriding somehow (but i'm in the dark) the InlinePanel object behavior, or change the way I designed the site.
Can anyone help me? Thank you very very much!
django wagtail
add a comment |
up vote
0
down vote
favorite
I am facing a problem from days, but, no matter how much I keep searching, I could not find any solution here or anywhere in the web.
So here it is: I am developing a website for some sort of institution which offers teaching courses. I am using WAGTAIL and I am structuring the classes this way:
class Course(Page):
...
content_panels = Page.content_panels
class Exam(Page):
#fields
content_panels = Page.content_panels + [
#fields
InlinePanel('preparatory_exam', heading='Preparatory Exams'),
]
class PreparatoryExam(Orderable):
page = ParentalKey('Exam',
on_delete=models.CASCADE,
related_name = 'preparatory_exams',
)
name = models.ForeignKey(
Exam,
on_delete=models.CASCADE,
blank=True,
null=True,
related_name = 'preparatory_exam',
)
I also structured the ADMIN section PAGES this way:
COURSE_1_PAGE
-----------EXAM_1
-----------EXAM_2
------------------Prep exam 1
------------------Prep exam 2
-----------EXAM_3
...
COURSE_2_PAGE
-----------EXAM_1
-----------EXAM_2
-----------EXAM_3
....
So, the problem is: is there any way to pass a custom queryset to the inline dropdown box when choosing the preparatory exams for a certain one? What I want is to restrict the set to the exams present in the same Course.
I could do that with a limit_choices_to added to the foreignkey field, but AFAIK, it would be a "static" filter, because it would be related to the model and not to its istances, so it would be the same for every newly instantiated exam...
One first- highly unsatisfactory - solution would be to change the InlinePanel with 2-3 FieldPanels (generally an exam does not need more than 2-3 other prep exams)...
Another UGLY solution would be explicitly defining Course_1, Course_2 and so on classses, but the problem here is that every year I would have to add another class, because they set up a new course every year!
So it leaves me not a lot of choices: overriding somehow (but i'm in the dark) the InlinePanel object behavior, or change the way I designed the site.
Can anyone help me? Thank you very very much!
django wagtail
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I am facing a problem from days, but, no matter how much I keep searching, I could not find any solution here or anywhere in the web.
So here it is: I am developing a website for some sort of institution which offers teaching courses. I am using WAGTAIL and I am structuring the classes this way:
class Course(Page):
...
content_panels = Page.content_panels
class Exam(Page):
#fields
content_panels = Page.content_panels + [
#fields
InlinePanel('preparatory_exam', heading='Preparatory Exams'),
]
class PreparatoryExam(Orderable):
page = ParentalKey('Exam',
on_delete=models.CASCADE,
related_name = 'preparatory_exams',
)
name = models.ForeignKey(
Exam,
on_delete=models.CASCADE,
blank=True,
null=True,
related_name = 'preparatory_exam',
)
I also structured the ADMIN section PAGES this way:
COURSE_1_PAGE
-----------EXAM_1
-----------EXAM_2
------------------Prep exam 1
------------------Prep exam 2
-----------EXAM_3
...
COURSE_2_PAGE
-----------EXAM_1
-----------EXAM_2
-----------EXAM_3
....
So, the problem is: is there any way to pass a custom queryset to the inline dropdown box when choosing the preparatory exams for a certain one? What I want is to restrict the set to the exams present in the same Course.
I could do that with a limit_choices_to added to the foreignkey field, but AFAIK, it would be a "static" filter, because it would be related to the model and not to its istances, so it would be the same for every newly instantiated exam...
One first- highly unsatisfactory - solution would be to change the InlinePanel with 2-3 FieldPanels (generally an exam does not need more than 2-3 other prep exams)...
Another UGLY solution would be explicitly defining Course_1, Course_2 and so on classses, but the problem here is that every year I would have to add another class, because they set up a new course every year!
So it leaves me not a lot of choices: overriding somehow (but i'm in the dark) the InlinePanel object behavior, or change the way I designed the site.
Can anyone help me? Thank you very very much!
django wagtail
I am facing a problem from days, but, no matter how much I keep searching, I could not find any solution here or anywhere in the web.
So here it is: I am developing a website for some sort of institution which offers teaching courses. I am using WAGTAIL and I am structuring the classes this way:
class Course(Page):
...
content_panels = Page.content_panels
class Exam(Page):
#fields
content_panels = Page.content_panels + [
#fields
InlinePanel('preparatory_exam', heading='Preparatory Exams'),
]
class PreparatoryExam(Orderable):
page = ParentalKey('Exam',
on_delete=models.CASCADE,
related_name = 'preparatory_exams',
)
name = models.ForeignKey(
Exam,
on_delete=models.CASCADE,
blank=True,
null=True,
related_name = 'preparatory_exam',
)
I also structured the ADMIN section PAGES this way:
COURSE_1_PAGE
-----------EXAM_1
-----------EXAM_2
------------------Prep exam 1
------------------Prep exam 2
-----------EXAM_3
...
COURSE_2_PAGE
-----------EXAM_1
-----------EXAM_2
-----------EXAM_3
....
So, the problem is: is there any way to pass a custom queryset to the inline dropdown box when choosing the preparatory exams for a certain one? What I want is to restrict the set to the exams present in the same Course.
I could do that with a limit_choices_to added to the foreignkey field, but AFAIK, it would be a "static" filter, because it would be related to the model and not to its istances, so it would be the same for every newly instantiated exam...
One first- highly unsatisfactory - solution would be to change the InlinePanel with 2-3 FieldPanels (generally an exam does not need more than 2-3 other prep exams)...
Another UGLY solution would be explicitly defining Course_1, Course_2 and so on classses, but the problem here is that every year I would have to add another class, because they set up a new course every year!
So it leaves me not a lot of choices: overriding somehow (but i'm in the dark) the InlinePanel object behavior, or change the way I designed the site.
Can anyone help me? Thank you very very much!
django wagtail
django wagtail
asked Nov 21 at 9:01
Pappice
11
11
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
One pragmatic option might be to use "ordinary Django views" to build this particular part of the application, borrowing Wagtail visual designs freely so that everything continues to look the same to the end-user. Given that you are building a display of a very rigid data-structure - course, exam
, etc., as opposed to "free-form content," this is probably how I would choose to do it.
(Note that Wagtail template tags might or might not work properly when Wagtail isn't the one driving the page display. I'd recommend implementing your own, of course freely copying from the Wagtail source-code for inspiration.) In the end, the user would not perceive a difference, and you can very freely develop URLs that would send the user to a Wagtail-managed target page, e.g. the course-descriptions and exams themselves.
Another pragmatic option is to use Django template-tags to construct portions of the display that are otherwise managed by Wagtail, although this gets maybe a bit more complicated. Since Django is underneath the whole thing, "Django rules still apply."
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
One pragmatic option might be to use "ordinary Django views" to build this particular part of the application, borrowing Wagtail visual designs freely so that everything continues to look the same to the end-user. Given that you are building a display of a very rigid data-structure - course, exam
, etc., as opposed to "free-form content," this is probably how I would choose to do it.
(Note that Wagtail template tags might or might not work properly when Wagtail isn't the one driving the page display. I'd recommend implementing your own, of course freely copying from the Wagtail source-code for inspiration.) In the end, the user would not perceive a difference, and you can very freely develop URLs that would send the user to a Wagtail-managed target page, e.g. the course-descriptions and exams themselves.
Another pragmatic option is to use Django template-tags to construct portions of the display that are otherwise managed by Wagtail, although this gets maybe a bit more complicated. Since Django is underneath the whole thing, "Django rules still apply."
add a comment |
up vote
0
down vote
One pragmatic option might be to use "ordinary Django views" to build this particular part of the application, borrowing Wagtail visual designs freely so that everything continues to look the same to the end-user. Given that you are building a display of a very rigid data-structure - course, exam
, etc., as opposed to "free-form content," this is probably how I would choose to do it.
(Note that Wagtail template tags might or might not work properly when Wagtail isn't the one driving the page display. I'd recommend implementing your own, of course freely copying from the Wagtail source-code for inspiration.) In the end, the user would not perceive a difference, and you can very freely develop URLs that would send the user to a Wagtail-managed target page, e.g. the course-descriptions and exams themselves.
Another pragmatic option is to use Django template-tags to construct portions of the display that are otherwise managed by Wagtail, although this gets maybe a bit more complicated. Since Django is underneath the whole thing, "Django rules still apply."
add a comment |
up vote
0
down vote
up vote
0
down vote
One pragmatic option might be to use "ordinary Django views" to build this particular part of the application, borrowing Wagtail visual designs freely so that everything continues to look the same to the end-user. Given that you are building a display of a very rigid data-structure - course, exam
, etc., as opposed to "free-form content," this is probably how I would choose to do it.
(Note that Wagtail template tags might or might not work properly when Wagtail isn't the one driving the page display. I'd recommend implementing your own, of course freely copying from the Wagtail source-code for inspiration.) In the end, the user would not perceive a difference, and you can very freely develop URLs that would send the user to a Wagtail-managed target page, e.g. the course-descriptions and exams themselves.
Another pragmatic option is to use Django template-tags to construct portions of the display that are otherwise managed by Wagtail, although this gets maybe a bit more complicated. Since Django is underneath the whole thing, "Django rules still apply."
One pragmatic option might be to use "ordinary Django views" to build this particular part of the application, borrowing Wagtail visual designs freely so that everything continues to look the same to the end-user. Given that you are building a display of a very rigid data-structure - course, exam
, etc., as opposed to "free-form content," this is probably how I would choose to do it.
(Note that Wagtail template tags might or might not work properly when Wagtail isn't the one driving the page display. I'd recommend implementing your own, of course freely copying from the Wagtail source-code for inspiration.) In the end, the user would not perceive a difference, and you can very freely develop URLs that would send the user to a Wagtail-managed target page, e.g. the course-descriptions and exams themselves.
Another pragmatic option is to use Django template-tags to construct portions of the display that are otherwise managed by Wagtail, although this gets maybe a bit more complicated. Since Django is underneath the whole thing, "Django rules still apply."
answered Nov 22 at 16:15
Mike Robinson
3,92221021
3,92221021
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53408434%2fwagtail-passing-queryset-to-inline%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown