Hm.. Doesn't form['_id'] just append an id to the table element? I'm
doing a crud.select to display multiple records, and I need the record
id on each row to uniquely identify it so I can pass the record id to
my ajax call onclick.
I guess I'll just use my own SQLTABLE class for the time-being, but
please keep adding record ids to rows in mind for a core modification.
Thanks.
On Mar 5, 2:07 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> I will think about something like this but you can do
>
> form['_id']= '%s_%s' % (form.table,form.record.id)
>
> and reference the rows by
>
> jQuery('form#tablename_id TR.tablename_fieldname__rows')
>
> Massimo
>
> On Mar 5, 3:13 pm,snfctech<tschm...@sacfoodcoop.com> wrote:
>
> > Thanks for the reply, Massimo.
>
> > Actually, I think I need to use SQLTABLE for my list view - SQLFORM
> > only applies to a single record, right?
>
> > Do you see anything wrong with adding record id's to table rows (if
> > they are provided) in gluon.sqlhtml like so:
>
> > if hasattr(record,'id'):
> > tbody.append(TR(_class=_class, *row, _id=(tablename + '_'
> > + str(record.id))))
> > else:
> > tbody.append(TR(_class=_class, *row))
>
> > That would make things a bit tidier for row/record related JS.
>
> > Any chance of getting this added to the trunk?
>
> > On Mar 4, 7:17 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > true you have a choice but they are all the same:
>
> > > class FORM it is built on helpers
> > > class SQLFORM(FORM) extends a FORM
>
> > > crud.update and crud.create are just two functions that to
>
> > > form=SQLFORM(...)
> > > if form.accepts(...):....
> > > return form
>
> > > so they return a SQLFORM with is a FORM and which can be manipulated
> > > as any other helper, for example
>
> > > form=crud.create(db.mytable)
> > > form.element(_name='myfield')['_class']='myclass'
>
> > > (it adds a class 'myclass' to the INPUT field for field 'myfield')
>
> > > On Mar 4, 11:39 am,snfctech<tschm...@sacfoodcoop.com> wrote:
>
> > > > So the form helpers are only useful for record-level input or basic
> > > > list displays, and everything else needs to be hand-coded? I wish
> > > > there was a way to use the helpers in a more flexible fashion, so
> > > > there could be "one obvious way" to display forms for creating,
> > > > reading, updating and deleting. As it stands, it looks like some of
> > > > my forms will get to live in CRUD, some in SQLFORM, and some in for
> > > > loops with markup. That seems un-elegant to me.
>
> > > > On Mar 4, 9:12 am, Thadeus Burgess <thade...@thadeusb.com> wrote:
>
> > > > > I hand write html, and use tr id="123" or tr record_id="123"
>
> > > > > and use
>
> > > > > jQuery("tr").click(function(){$(this).parent().attr("record_id")})
>
> > > > > -Thadeus
>
> > > > > On Thu, Mar 4, 2010 at 10:56 AM,snfctech<tschm...@sacfoodcoop.com>
> > > > > wrote:
> > > > > > I am fond of a design pattern whereby a list of records (such as
> > > > > > orders) is displayed in the top part of a view and thedetailfor a
> > > > > > highlighted record is displayed in the lower part of the view
> > > > > > viaAJAX
> > > > > > onclick (such as the customer and product details for the order).
>
> > > > > > I like web2py because I want a "higher-level" tool that allows be to
> > > > > > do more with less code. But when I tried implementing my favorite
> > > > > > design pattern with the web2py CRUD andAJAXhelpers, I found the code
> > > > > > to be quite awkward, namely:
>
> > > > > > I give the list view table and id as a CRUD parameter which I use
> > > > > > to
> > > > > > add the onclick event to the table rows on domready:
>
> > > > > > order_list = crud.select(db.os_order,_id='order_list',...
>
> > > > > > and:
>
> > > > > > $('#order_list tbody tr').click(function() {
> > > > > > var order_id = $(this).find('.order_id').attr('id');
> > > > > > ajax('default/orderdetail',[order_id],'order_detail_div');
> > > > > > });
>
> > > > > > But here's the really ugly part of the design:
>
> > > > > > In order to get the record id I have to represent my ID field with a
> > > > > > hidden INPUT element:
>
> > > > > > db.os_order.id.represent = lambda value: (value,
> > > > > > INPUT(_type='hidden', _id=value,_value=value, _class='order_id'))
>
> > > > > > And in order to uniquely identify the element and pass it's value to
> > > > > > the web2pyAJAXhelper I give the record ID as both it's "id" and
> > > > > > "value" attributes. Which leads to the unhappy retrieval in the
> > > > > > controller by means of:
>
> > > > > > order_id = list(request.vars)[0]
>
> > > > > > All of this seems a bit un-elegant, don't you think? I guess I
> > > > > > could
> > > > > > do away with the web2pyAJAXhelper and use a for loop to add
> > > > > > id="order_123" to my table rows, but now I'm back to building forms
> > > > > > from scratch - so what's the point of the web2py high-level helpers?
>
> > > > > > If somebody could point out a way to implement this design pattern
> > > > > > in
> > > > > > a more elegant fashion by still leveraging web2py form helpers, it
> > > > > > would be much appreciated.
>
> > > > > > Thanks.
>
> > > > > > --
> > > > > > You received this message because you are subscribed to the Google
> > > > > > Groups "web2py-users" group.
> > > > > > To post to this group, send email to web...@googlegroups.com.
> > > > > > To unsubscribe from this group, send email to
> > > > > > web2py+unsubscr...@googlegroups.com.
> > > > > > For more options, visit this group
> > > > > > athttp://groups.google.com/group/web2py?hl=en.
--
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
