You need to think about this --- On Jun 22, 11:15 am, mdipierro <[email protected]> wrote: > This is no longer a client issue. I think you do handle the problem > correctly client side. > The problem is that if some fields exist in db but you do not want to > insert them you need to change the validator from > > db.table.field.requires=blabla() > > into > > db.table.field.requires=IS_EMPTY_OR(blabla()) > > You can do this conditionally: > > if request.vars.selectorfield='whatever': > db.table.field.requires=IS_EMPTY_OR(blabla())
Two things about this suggestion: - it will validate an empty field, and insert an empty value (if that's ok, great!) - it is runtime: where you put this matters (put before form.accepts()); You would _hope_ that there was consistent behavior, and that you could alternatively mark the appropriate fields read-only (after-the- form is created, so that the fields are made - but before form.accepts) so that it is not stored, that is you would hope that you could do: db.table.field.writeable=False just as easily as you can do: db.table.field.required= something_new I would expect this to also not validate those fields... ... but unfortunately, right now that's not how it works... A bit of refactoring of SQLFORM might help - I've been looking at this for a while... it's not clear where / how deeply this validation trigger is buried. I have played around a bit in SQLFORM.accepts(), tried removing self.field if it's not writable, and additionally removing it from request_vars.... That is not enough, and it's not obvious to me where this is buried, or how it's different from what SQLFORM.__init__ does; maybe Massimo can shed some light, help make this behavior consistent with ...field.requires Depending on what you need to do, one or the other might be appropriate. - Yarko > > On Jun 22, 9:56 am, Andrew Buchan <[email protected]> wrote: > > > > > Hi Massimo, > > > I posted the code below before checking if the form would actually submit. > > What now happens is that all the fields are put through validation, > > including those which I hid with JQuery, and needless to say, most of them > > fail because they're empty! > > > There's no way I can do away with the validators, and I'm struggling to > > find-out how to make it not validate those fields I hid. If I can't then > > I've just thrown away a crucial 5 hours on JQuery, nice learning experience > > but if I have to start again with a different approach I won't be a happy > > bunny and neither will my client :-| > > > Any suggestions? > > > On Tue, Jun 22, 2010 at 2:27 PM, Andrew Buchan <[email protected]> wrote: > > > Massimo, > > > > Thanks for that, I was about to reply saying that JQuery can't do what I > > > want it to, then thought I'd test my statement before making it. Here's > > > the > > > code for anyone who's interested: > > > > Its all in the controller, as I pretty much use only one single > > > multi-purpose view for all my pages :-) > > > > #### > > > > #Fields to be visible for all departments > > > commonFields = [ > > > 'Details', > > > 'Suggested_Action' > > > ] > > > form = SQLFORM.factory(db[TableName]) > > > > #Create dict of department-specific fields, this is where you make > > > changes when departments change the fields they require.... > > > #Note: must all exist in table def in model, exclude common fields in > > > list above. > > > DepartmentFields = dict() > > > DepartmentFields['IT'] = ['Contract_Number', 'Details'] > > > DepartmentFields['Projects'] = ['Work_Order_Number', > > > 'Sales_Order_Number', 'Client'] > > > > #Create javascript/JQuery string for department select's onChange > > > event... > > > deptchange = "$(\"TR[id^=no_table]\").hide();" +\ > > > "var selectedDept = $('#To_Department :selected').text();" +\ > > > "var fieldsToShow = [];" +\ > > > "switch(selectedDept){" > > > for dept, fields in DepartmentFields.items(): > > > fields.extend(commonFields ) > > > deptchange += "case '%s': fieldsToShow=%s;break;" % (dept, fields > > > ) > > > deptchange += "default: fieldsToShow=[];};for (f in > > > fieldsToShow){$('#no_table_' + fieldsToShow[f] + '__row').show();};" > > > > #Create the department select html control and insert at the top of > > > the > > > form (place this wrong and you will get very strange results when hiding > > > parts of the form) > > > DepartmentsRows = db(db.department.id >0 ).select() > > > Departments = [DepartmentsRows[i]['department_name'] for i in > > > range(len(DepartmentsRows))] > > > form[0].insert(0, TR(TD('To Department: '),TD( > > > SELECT( Departments , _name='To_Department', > > > _id='To_Department', _onChange=deptchange ), > > > ))) > > > > I agree it's not ideal storing part of the logic in python, and part in > > > JQuery, but at least this way the dict representing the variable data can > > > be > > > kept in python (we do this for the DAL so why not...). > > > > I would still like to know the answer to me first question though: can I > > > create INPUT/SELECT/TEXTAREA bits directly from the table definition field > > > without going via SQLFORM? Anyone? > > > > ------------------- > > > > On Mon, Jun 21, 2010 at 5:35 PM, mdipierro <[email protected]>wrote: > > > >> This is what I would do > > > >> - make a single for that contains all fields you need > > >> - use jQuery in the view so that depending on the selected department > > >> some fields are hidden > > > >> On Jun 21, 3:38 am, Andrew Buchan <[email protected]> wrote: > > >> > Hello, > > > >> > I am trying to make a form for inserting a new record representing an > > >> > internal complaint against a given department. Depending on which > > >> department > > >> > is selected, different fields must be completed. > > >> > The way I'm planning on doing this is with a simple form with a select > > >> box > > >> > for the department, a DIV, and a submit button. On changing the > > >> department > > >> > selection, the DIV will be refreshed to display only those fields > > >> applicable > > >> > to that department (all of which correspond to a field in the DAL). > > > >> > 1. Where I'm having trouble is in generating the HTML fields based on > > >> the > > >> > names of a field in the DAL. I have previously always just used SQLForm > > >> and > > >> > sized it down to suit by passing a list of fields, but think that in > > >> this > > >> > situation, and many others, it would be useful to build a form from > > >> fields > > >> > obtained by passing the name of a field in the DAL and getting the > > >> > validators brought through automatically. > > > >> > 2. Also, if I manage to do this, will there be an issue with the fact > > >> that > > >> > some of the fields in the form are nested in a DIV, will the fields > > >> still > > >> > auto-validate? From recollection placing a whole form within a DIV > > >> doesn't > > >> > work so didn't want to do that... > > > >> > Cheers..
