appadmin str method call on custom field type

[Alan Etkin]

There's a probable bug at the new appadmin.py in the record form edit section. If your db field has an <Python object> type, you'll get a ticket because there a <field>.type.some_string_method call. I'm not sure if it was introduced with the new release or it was there already, but I think we should fix that. In general, the gluon code shouldn't call string methods directly with field.type attributes.

[Alan Etkin]

Sorry, wrong file. The error is raised at sqlhtml

Traceback (most recent call last):

  File "/home/alumno/web2py-git/gluon/restricted.py", line 217, in restricted
    exec ccode in environment
  File "/home/alumno/web2py-git/applications/myemail/controllers/appadmin.py", line 635, in <module>
  File "/home/alumno/web2py-git/gluon/globals.py", line 378, in <lambda>
    self._caller = lambda f: f()
  File "/home/alumno/web2py-git/applications/myemail/controllers/appadmin.py", line 323, in update
    f='download', args=request.args[:1]))
  File "/home/alumno/web2py-git/gluon/sqlhtml.py", line 1098, in __init__
    elif field.type.startswith('list:'):
AttributeError: type object 'list' has no attribute 'startswith'


And I think there could be other file sections with the same issue.

[Niphlod]

sorry alan, I'm missing the issue .... type should be always a string ('boolean', 'string', 'text', and so on). When does it bring a python object ?

[Anthony]

It can also be a SQLCustomType, but that class does have a .startswith() method.

Anthony

[Alan Etkin]

It can also be a SQLCustomType, but that class does have a .startswith() method.

Anthony

On Sunday, September 15, 2013 4:56:43 AM UTC-4, Niphlod wrote:

sorry alan, I'm missing the issue .... type should be always a string ('boolean', 'string', 'text', and so on). When does it bring a python object ?

I'm searching for a reference in the web but unless I'm missing something DAL has been supporting field.type = <Python built-in>. Also, I have recently modified the dal imap adapter so it defines dict object types because it deals with compound data for message parts. Should I rewrite those field definitions to use string types?

EDIT: the imap adapter defines two list object field types

[Massimo DiPierro]

On Sep 15, 2013, at 8:20 AM, Alan Etkin wrote:

It can also be a SQLCustomType, but that class does have a .startswith() method.

Anthony

On Sunday, September 15, 2013 4:56:43 AM UTC-4, Niphlod wrote:

sorry alan, I'm missing the issue .... type should be always a string ('boolean', 'string', 'text', and so on). When does it bring a python object ?

I'm searching for a reference in the web but unless I'm missing something DAL has been supporting field.type = <Python built-in>.

I believe this was your patch. It is aslo true that web2py relies on field.type.startswith(...).

Also, I have recently modified the dal imap adapter so it defines dict object types because it deals with compound data for message parts. Should I rewrite those field definitions to use string types?

--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to the Google Groups "web2py-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py-develop...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Alan Etkin]

I believe this was your patch. It is aslo true that web2py relies on field.type.startswith(...).

Do you mean I introduce an unsupported feature?. Anyway, I don't mind changing this again to suit the dal standard types. I just though it was compatible code because I think I saw an example with a list type definition.

BTW: In sqlhtml there are sections that are aware of field types not always being strings and other's that are not (wether they implement string methods or not), so I think this is because actually gluon did not always relied on string field types.

[Massimo DiPierro]

I need to take a second look at the code. If you say type int and then you convert it to type = 'integer' than no problem. If you leave it as type = int than this will break something.

where?

[Anthony]

BTW: In sqlhtml there are sections that are aware of field types not always being strings and other's that are not (wether they implement string methods or not), so I think this is because actually gluon did not always relied on string field types.

Maybe this was just to accommodate SQLCustomType. 

[Massimo DiPierro]

what's the model here. field.type should not be type list.

[Niphlod]

if we did, we should remove it promptly.
There are tons of code depending on type being always a string ... having to turn everything to check with isinstance() will leave too many open points.

[Massimo DiPierro]

@Alan,

I only see this in the IMAPAdapter:

      Field("content", list, writable=False),

      ...

      Field("attachments", list, writable=False, readable=False),

I have to admit I have not looked at the code of this adapter in sufficient detail. Can we safely replace list with "list:string" here? What else should be changed?

Massimo

On Sep 15, 2013, at 9:07 AM, Alan Etkin wrote:

[Alan Etkin]

if we did, we should remove it promptly.
There are tons of code depending on type being always a string ... having to turn everything to check with isinstance() will leave too many open points.

I have not checked all gluon, just sqlhtml.py, and there are a couple of lines that do:

if isinstance(field.type, str) and <whatever>

This is why I'm saying problably gluon did allow defining a field type as Python object (although it seems it is not documented in any way). I'm not against removing the type check and not supporting Python field types, maybe it's enough to announce it in case anyone else is using it.

[Alan Etkin]

I have to admit I have not looked at the code of this adapter in sufficient detail. Can we safely replace list with "list:string" here? What else should be changed?

I think it would make the imapadapter not to retrieve or render any message part. I would leave that code as it is until I have the time to rewrite the part retrieval logic (using a custom type). I don't think the current code affects anything in the core except using sqlform and including content or attachment fields (not available by default)

[Massimo DiPierro]

A field type can be a string or can be a CustomType. They both have startswith(...) method. 

[Massimo DiPierro]

OK.

On Sep 15, 2013, at 10:09 AM, Alan Etkin wrote:

I have to admit I have not looked at the code of this adapter in sufficient detail. Can we safely replace list with "list:string" here? What else should be changed?

I think it would make the imapadapter not to retrieve or render any message part. I would leave that code as it is until I have the time to rewrite the part retrieval logic (using a custom type). I don't think the current code affects anything in the core except using sqlform and including content or attachment fields (not available by default)

[Anthony]

I have not checked all gluon, just sqlhtml.py, and there are a couple of lines that do:

if isinstance(field.type, str) and <whatever>

This is why I'm saying problably gluon did allow defining a field type as Python object (although it seems it is not documented in any way).

That doesn't necessarily mean any arbitrary object is allowed, just that there is the possibility of at least one non-string-type object (e.g., SQLCustomType). Note, there are also places where it does field.type.startswith() without making a type check, implying the type is at least expected to have a .startswith() method (as SQLCustomType does).

Anthony