On Jun 25, 3:24 am, Andrew Buchan <[email protected]> wrote: > Sorry for delay in getting back. I eventually opted for a solution which > does not involve JQuery, instead a department-specific list of fields is > passed to SQLForm, which makes things so much simpler. > The only draw back is that the user has to select a department on one page, > and is then redirected to another page with the 'create' form, but that's a > small price to pay for the simplicity of using self-submitting forms
If that's how you are doing it, then it would be a very small step to make that "other page" an ajax loaded css element on the first page - i.e. first part of form submitted gets the second part of the page loaded. > thereafter (after creating the initial record, 5 other actions can be taken > on it, and for all of those the department is already known, so it's > easier). > Anyway, thanks for the suggestions, and I now know a bit about JQuery which > will no doubt come in useful one day. > Regards, > > On Tue, Jun 22, 2010 at 5:15 PM, 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()) > > > 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..
