Changes between Version 1 and Version 2 of Ticket #20267, comment 2


Ignore:
Timestamp:
Apr 16, 2013, 2:22:09 PM (12 years ago)
Author:
clime

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #20267, comment 2

    v1 v2  
    1111
    1212
    13 Now there were actually two problems. The first one was with with the initial value for crag_type. Filtering should be done by GET requests, I believe, so I simply did this in my view:
     13Now there were actually two problems. The first one was with the initial value for crag_type. Filtering should be done by GET requests, I believe, so I simply did this in my view:
    1414
    1515{{{
    … …  
    4141which I don't like at all but it was the simplest solution.
    4242
    43 But I have work on and discovered yet another problem with order_by and order_asc fields. These fields are not part of the frontend form (by graphic design and provided templates) but it seemed natural to put them into the backend/logic form anyway so that I can simply pass these parameters to model with others and then in models differentiate what to put as param of .filter() and what to put as a param of .order_by(). This approach simply makes view simpler (which is good, I think). Backend form does not "match" the frontend form but it was possible to do it like this without any javascript hacks and it all worked well. Except initial values because checking if request.GET is empty before passing it to the filter was no longer working. Basically, if querystring has not been populated, submitting the form trashed initial values for filter params and submitting the ordering trashed initial values filtering. In the end I needed to do something like this in view:
     43But I have worked on and discovered yet another problem with order_by and order_asc fields. These fields are not part of the frontend form (by graphic design and provided templates) but it seemed natural to put them into the backend/logic form anyway so that I can simply pass these parameters to model with others and then in models differentiate what to put as param of .filter() and what to put as a param of .order_by(). This approach simply makes view simpler (which is good, I think). Backend form does not "match" the frontend form but it was possible to do it like this without any javascript hacks and it all worked well. Except initial values because checking if request.GET is empty before passing it to the filter was no longer working. Basically, if querystring has not been populated, submitting the form trashed initial values for filter params and submitting the ordering trashed initial values filtering. In the end I needed to do something like this in view:
    4444
    4545{{{
Back to Top