Yarko,

I tried doing this with a DIV, but if I put the whole form within the DIV,
that doesn't seem to work. If you mean just putting the input fields in the
DIV, with the submit button outside of that, then that's what my original
question was about: how to generate a table with labels/inputs by passing a
list of Fields. Or did you mean a different way, I'm all ears :-)
As long as I can use form.accepts to validate just those fields which are
displayed, then it should work for me.
Having said that, I'm past my deadline and struggling for time, and this is
really a nice to have which I can't afford to spend too much time on before
launching. But still, all suggestions are most welcome...


On Fri, Jun 25, 2010 at 9:37 AM, Yarko Tymciurak <
[email protected]> wrote:

> 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..
>

Reply via email to