Massimo, can you please comment on the points that I mentioned. I'm still
interested in that solution and using out-of-trunc code is not very
convenient if upgrading.
There were 2 main points:
1) Is there recommended approach for _reusing_widgets_ generated by SQLFORM?
Current code contains only means to cache labels, input values and display
values so one still have to construct <input/>s himself in the view. My
approach allows one to just have {{=form.trows['fieldname']['widget']}}
though I already see why this is wrong - to stay consistent with current code
I had to use {{=form.custom.widgets.fieldname}}. But it would be easy to
fix...
2) Is there a bug in current code, here:
if hasattr(field, 'widget') and field.widget\
and request_vars.has_key(fieldname):
self.trows[fieldname][1][0].components = \
?
Shouldn't it be just self.trows[fieldname][1]= and what is the purpose of this
part?
On Tuesday 19 May 2009 12:35:43 Alexey Nezhdanov wrote
> Version 2 of the patch
> I discovered that I messed up self.custom.dspval contents with previous
> patch. And having both functions (do_custom & do_standard) is more
> convenient - this way used can decide where he wants standard fields to go
> -
> before his ones of after them.
>
> On Tue, May 19, 2009 at 11:44 AM, Alexey Nezhdanov <[email protected]>
wrote:
> > Here is it. Small, nice, tested and documented.
> >
> > One downside though. I tried hard but failed to understand the original
> > self.trows purpose. While I preserved default functionality, I'm not
> > sure if I missed something subtle.
> >
> > And, btw, use of trows seemed buggy for me.
> > Here is my best guess:
> > trows is intended to remove validation errors from widgets that were
> > manually assigned to the database fields. If so - then it fails it's
> > purpose because
> > self.trows[fieldname][1][0].components
> > addresses components of the <INPUT/> and not of <TD/>. To fix it you
> > need to remove [0]:
> > self.trows[fieldname][1].components
> >
> > On Tue, May 19, 2009 at 7:52 AM, Alexey Nezhdanov <[email protected]>
wrote:
> >> Hello.
> >>
> >> Reading the SQLFORM sources doesn't give me any insight on
> >> how to do custom form layout w/o modifying web2py source
> >> AND writing extensive wrappers around it.
> >>
> >> I found these pages while googling:
> >> http://groups.google.com/group/web2py/browse_thread/thread/39c0bd5e01860
> >>eb/fecc0f6edbb3885f?lnk=gst&q=custom+sqlform+layout#fecc0f6edbb3885f
> >> http://www.wellbehavedsystems.co.uk/web2py/examples/custom_forms.html
> >>
> >> As I can see - it was an unofficial solution, proposed about a
> >> half-year ago. Is it a recommended approach atm? If not - is
> >> there one? If yes - is it going to be included?
> >>
> >> I am personally didn't like it too much - it's what I referred to
> >> as 'extensive wrapper'.
> >>
> >> If there is no support in current SQLFORM yet I'll probably end
> >> up writing something myself, hopefully something simpler.
> >>
> >> Currently I think of something like this (in SQLFORM.__init__):
> >> 1) iterate over fields, generate widgets (it does that already),
> >> 2) put generated widgets into a Storage(input_name:input_widget)
> >> 3)
> >> self.components=[]
> >> self.do_custom_layout() # by default does nothing, can be redefined in
> >> derived clases self.do_standard_layout() # populates table with fields
> >> remaining in the Storage fields
> >>
> >> do_custom_layout (when redefined) will pop widgets out of
> >> said Storage and put them into some HTML, adding it to self.components
> >>
> >> --
> >> Sincerely yours
> >> Alexey Nezhdanov
--
Sincerely yours
Alexey Nezhdanov
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
