SQLFORM without tables
Alexandre
mdipierro
form=SQLFORM(...)
form.components=[row[1][0] for row in form[0].components]
You can try variations
> FoG -http://fog.icmc.usp.br
> IM Team - AIESEC
Thadeus Burgess
for quite a while :)
For now, sqlform.custom is the way to go
http://web2py.com/AlterEgo/default/show/205
-Thadeus
> --
> 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+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
>
>
>
>
mdipierro
HTML representation.
data has different representations depending on its status in the
system. For example in a submitted mime multipart form a file is a
FieldStorage object with a file and a filename attribute. A file in
Python is just an object with read/write methods. A file in the DAL is
just a temporary name into a Field(...'upload') and the data is stored
somewhere else, usually on the filesystem, perhaps in a Field
(...'blob').
A validator is an object that takes the data in a form format and
converts it into DAL format. It fails to convert, it modifies the HTML
form to include error messages.
Think for example of the IS_IMAGE validator. It acts on a FieldStorage
object.
Think also about error messages. Currently they do not have to be
strings. They can be helpers. They can contain links or other
structure.
Validators are two-way filters. Think about IS_DATE. It converts a
date from the string representation choose for the HTML form into
datetime.date format used by the DAL and vice versa when the data is
extracted from the DAL and put into an update form.
Validators since they are filters can be piped.
The all process is designed to take an HTML form, validate it, convert
it, store the data in DAL or return a different form with errors.
Breaking this process in two layers (an abstract form and a form
representation) would require decoupling the role of validation from
the role of converting the data. This is logically complicated. This
may also be practically complicated for the user.
This the reason why so far we have been unable to validate
import_from_csv_file since you cannot use validators for that purpose.
Web2py was designed with the 80-20 rule in mind: make it easy in the
80% of the cases at the expense of making more complex in the 20% of
the cases. You can make things easy for that 20% at the expense of
making things more complex in the other 80% but I do not think that is
what we want.
Anyway, I do think the current system can be improved and made more
general. I do not see how this decoupling can be done. Perhaps it is
just me. I will be happy to see proposals.
Massimo
Jonathan Lundell
I think what he really wants is the same thing I have been discussing
for quite a while :)
For now, sqlform.custom is the way to go
http://web2py.com/AlterEgo/default/show/205
SQLFORM (starting with rev.726) now keeps the values retrieved from the DB in custom objects that can be referenced by field name and used directly in custom forms without the need to re-access the DB.
mdipierro
Alex Fanjul
"Decoupled, Custom and Tableless Forms". I'd say it would involve lot of
changes for "default" things that web2py does now very well, and that is
the problem.
Alex F
El 06/01/2010 0:13, Thadeus Burgess escribi�:
> I think what he really wants is the same thing I have been discussing
> for quite a while :)
>
> For now, sqlform.custom is the way to go
>
> http://web2py.com/AlterEgo/default/show/205
>
> -Thadeus
>
>
>
>
>
> On Tue, Jan 5, 2010 at 4:25 PM, mdipierro<mdip...@cs.depaul.edu> wrote:
>
>> I think this should do it:
>>
>> form=SQLFORM(...)
>> form.components=[row[1][0] for row in form[0].components]
>>
>> You can try variations
>>
>> On Jan 5, 4:18 pm, Alexandre<airm...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I would like to get SQLFORM without tables, just one field on top of the
>>> other, is that possible?
>>>
>>> It would be nice if instead of a table, we could iterate through the fields
>>> in SQLFORM, so that we could represent it anyway we would like.
>>>
>>> Thanks,
>>> Alexandre Rosenfeld
>>>
>>> Eng Comp 06 - USP S�o Carlos
>>> FoG -http://fog.icmc.usp.br
>>> IM Team - AIESEC
>>>
>> --
>> 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+un...@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
>>
>>
>>
>>
>>
--
Alejandro Fanjul Fdez.
alex....@gmail.com
www.mhproject.org
Thadeus Burgess
validation/forms/filters are written...
See you explain this system that each part relies on another part
working a certain way... when I analyze this through my
programming filter to solve this problem this is what I see...
A class for filtering (parsing html values into python values)
A class for validation (validating already parsed data), this could be
used anywhere within web2py, even import_from_csv_file!
A class for data structure (just the data of a form, like a rows
object, and the types of data)
A class for representation (this will take a data structure, and parse
it into a representable format... like a form, or a table)
Each of these classes could use the others, but they don't rely on the
others.... you could use the filtering without validating the data...
or create a form that can validate, but doesn't represent itself.
-Thadeus
Thadeus Burgess
I just havn't had the time to sit down and figure out a real workable
solution that can integrate into everything else web2py does.
Your right, the defaults are integrated into everything, everything
from default widgets set by the DAL/Fields so that a SQLFORM can
display them.
So the question is, what changes could be made to the DAL to separate
it from data representation.
-Thadeus