Mind that nothing prevents you form doing this:
db.define_table('mytable',Field('myfield'))
db.mytable.myfield.label = 'myfield name'
db.mytable.myfield.comment = 'comment about the field'
db.mytable.myfield.help = 'help about the field'
db.mytable.myfield.popup = 'popup info about the field'
etc.
The fact that label and comment can be specified in the Field(...) args and
they are used by SQLHTML does not mean you cannot attach other attributes
to the field. You can also do:
db.mytable.myfield.comment = DIV('comment about the field',DIV('help about
the field',_class='hidden help'),DIV( 'popup info about the
field',_class='hidden popup'))
and use jquery/css to handle help and popup classes.
On Thursday, 13 December 2012 11:18:02 UTC-6, Joe Barnhart wrote:
>
> The website I am replacing has a "third tier" of info -- it has the field
> label, the field comment, AND a popup (which can be more than one
> paragraph). If I just store the extensive help in the comment field, I
> will lose the comment itself. Anthony has opened my eyes regarding the
> comment field and how it can be used.
>
> My main comment to you is -- extensible. The design of webXpy needs to be
> easily extensible to accommodate changes we don't think of at the time we
> create the software. The 4-tuple is a hard limit and it will forever
> constrain what we can do between Fields, SQLFORM, and formstyle. If that
> were an object instead of a tuple it would be extensible and could handle
> unforeseen issues.
>
> This is more of a philosophical comment that a proposal for any immediate
> change. I know you are thinking about web3py and I wanted to make a case
> for keeping interfaces extensible instead of limited. As you can no doubt
> tell, I'm reasonably new to this world of web programming but I've been
> doing Smalltalk programming professionally for 20 years. In my Smalltalk
> job I have also used the pattern of "tuples" (arrays) to pass information
> between Smalltalk objects and it often needs overhauling at some point to
> accommodate changes.
>
> The simplest way to transfer the information is usually by handing over
> the object that has the info -- the Field in this case -- rather than
> making a tuple. Handing the Field object itself costs nothing -- you don't
> even need to create and garbage-collect the tuple -- yet it opens the door
> to letting the formstyle access everything the Field knows.
>
> But like I say, it breaks the "compatibility" contract between web2py and
> its users, which is an enormous strength of web2py and I would never
> suggest giving that up. But one day there will come a time when it will be
> necessary to do a "python3" of our own. When that day arrives, that would
> be the time to re-examine the interfaces inside web2py to see if they can
> be opened up.
>
> -- Joe B
>
> On Thursday, December 13, 2012 6:31:14 AM UTC-8, Massimo Di Pierro wrote:
>>
>> I am not not convinced we need both comment and help. I think one can
>> simply strore the commend in help (without being a dict) and use jQuery to
>> turn the visualization of the comment (help) into a popup.
>>
>>
--
