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 the detail for a
> > > highlighted record is displayed in the lower part of the view via AJAX
> > > 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 and AJAX helpers, 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 web2py AJAX helper 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 web2py AJAX helper 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.
