But adding the attributes to the Field object doesn't help -- I do not get
the Field when the SQLFORM is built using the "formstyle" function. Since
it has no access to Field it can't see the extra attributes -- its only
access is the tuples passed from SQLFORM.
But I agree the DIV() helper is an awesome workaround! I could even use
jquery to automatically add the [?] icon to the comment string of the
fields that have the help DIV. I hadn't thought of structuring the comment
field before you and Anthony mentioned it. There is sooooo much under the
covers it's hard to think of all the possibilities.
-- Joe
On Thursday, December 13, 2012 9:22:55 AM UTC-8, Massimo Di Pierro wrote:
>
> 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.
>>>
>>>
--
