Upon further reading of the source code in html.py and sqlhtml.py
I see now that the widgets in sqlhtml.py are very elegantly built upon
calls to the 'HTML Helpers' which are in html.py.
It was the HTML Helpers which I was referring to as 'controls'.
NOTE however that I have been able to use an 'INPUT' HTML Helper from
within the View markup,
so it looks like the HTML helper can in some way behave like a widget:
<form action="" enctype="multipart/form-data" method="post">
<table>
<tr id="testtable_testfield1__row">
<td>
<label for="testtable_testfield1"
id="testtable_testfield1__label">Testfield1: </label>
</td>
{{if session.action == "update":}}
<td>
{{ =INPUT(_type='text', _id='testtable_testfield1',
_name='testfield1', value="abc", requires=IS_NOT_EMPTY())}}
</td>
On May 3, 9:39 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> not sure I understand what you mean by widgets then. for me a widget
> is an object that represents a field in a form. INPUT is not a widget.
> widgets in web2py are
>
> class IntegerWidget(StringWidget):
> class DoubleWidget(StringWidget):
> class TimeWidget(StringWidget):
> class DateWidget(StringWidget):
> class DatetimeWidget(StringWidget):
> class TextWidget:
> class BooleanWidget:
> class OptionsWidget:
> class MultipleOptionsWidget:
> class PasswordWidget:
> class UploadWidget:
>
> and they are defined in gluon/sqlhtml and, of course, they completely
> undocumented.
>
> Massimo
>
> On May 3, 5:34 pm, dlypka <dly...@gmail.com> wrote:
>
>
>
> > Even though there are existing widgets, do they handle the specific
> > issue
> > of working with the CRUD Error framework? i.e. is class INPUT
> > considered to be a widget?
> > I suspect we need a variation of CRUD that generates widgets
> > internally instead of INPUT instances etc,
>
> > On May 3, 5:51 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > we have widgets already. Look into gluon/sqlhtml.py for examples. The
> > > only thing missing is a repository for third party widgets. It would
> > > be great is somebody were to take care of that and maintain a
> > > repository.
>
> > > Massimo
>
> > > On May 3, 4:11 pm, dlypka <dly...@gmail.com> wrote:
>
> > > > I think it is a great idea to be started the sooner, the better.
>
> > > > Plus, I also recommend creating a "wig2py" (widget 2 py) for GUI
> > > > Controls similar to the idea of ASP.NET controls
> > > > to solve the problem of using custom forms with CRUD. So I believe 2
> > > > critical web2py framework projects needs to be taken on ASAP.
>
> > > > By the way, Microsoft has recently released their 'Entity Framework'
> > > > (which I use every day at work now)
> > > > and so bascially there is a Kind of DAL choice in their architecture:
> > > > ADO.NET style
> > > > or
> > > > Entity Framework style
>
> > > > So if they can do it, so can web2py..
>
> > > > On May 3, 4:05 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
>
> > > > > the question of non-relational DBs is an interesting one, and
> > > > > increasingly
> > > > > will become so in the years to come.
>
> > > > > I think DAL is structured to make web2py apps portable - allow you to
> > > > > run
> > > > > your design without regard to backend storage. Clearly, that is
> > > > > biased
> > > > > towards relational databases which are prevelant today.
>
> > > > > But non-relational data stores are increasingly becoming prevelant -
> > > > > big
> > > > > tables being the perhaps most influential example, but also Apache has
> > > > > interest in several: Hadoop, couchDB..
>
> > > > > Clearly, the playing field is still expanding in this area, and it is
> > > > > exciting times.
>
> > > > > The question is not about stoping progress - the question is what
> > > > > path to
> > > > > take to lead / follow / influence progress.
>
> > > > > Since DAL imposes little enough on you for portability (a goal), it is
> > > > > unique in being able to map to _some_ BigTable functionality.
>
> > > > > The question is how to procdeed.
>
> > > > > I think DAL should follow the objectives which Massimo set out;
> > > > > extensibility may be useful for Relational use, but peripheral. What
> > > > > remains interesting is central portability in the domain of
> > > > > relational data
> > > > > stores; GAE is at the edge of that.
>
> > > > > A perhaps more interesting suggestion is to have a DAL project which
> > > > > writes
> > > > > a non-relational data store abstraction, and begins to put the
> > > > > structure of
> > > > > things like BigTable, ... I don't know what others would fit into the
> > > > > "same
> > > > > kind of" class, or what a useful union for a non-relational DAL would
> > > > > be -
> > > > > perhaps Hadoop, CouchDB, MongoDB, etc.
>
> > > > > But to do that would require people who are familiar with the broader
> > > > > uses
> > > > > of those other dbs, and interested in abstracting to create a new,
> > > > > non-relational DAL: DALnr?.
>
> > > > > For starters, I suggest a useful excercise might be to consider the
> > > > > interfaces within web2py, and how to make a DALnr that starts as
> > > > > SPECIFIC to
> > > > > one backend, to gain familiarity with it, and to work out the details
> > > > > of how
> > > > > this changes interfacing w/ web2py --- this excercise would free
> > > > > someone to
> > > > > explore the non-relational backend more thouroughly, and would second
> > > > > be a
> > > > > refactoring driver for web2py DAL integration... eventually leading
> > > > > to the
> > > > > ability to choose which KIND OF DAL your project uses.
>
> > > > > Perhaps some unification between these two - so that applications can
> > > > > be
> > > > > portable accross both types - will emerge, and this would be useful.
>
> > > > > But I think the first step is to cleanly, intentionally separate the
> > > > > two
> > > > > kinds of back ends and see where that leads.
>
> > > > > What does everybody think?
>
> > > > > - Yarko
>
> > > > > On Sun, May 3, 2009 at 12:38 PM, dlypka <dly...@gmail.com> wrote:
>
> > > > > > When I evaluate a database framework, the first thing I look at is
> > > > > > the
> > > > > > field types.
> > > > > > Right now I see web2py supports these types:
>
> > > > > > •db.Field(name, 'string')
> > > > > > •db.Field(name, 'text')
> > > > > > •db.Field(name, 'password')
> > > > > > •db.Field(name, 'blob')
> > > > > > •db.Field(name, 'upload')
> > > > > > •db.Field(name, 'boolean')
> > > > > > •db.Field(name, 'integer')
> > > > > > •db.Field(name, 'double')
> > > > > > •db.Field(name, 'time')
> > > > > > •db.Field(name, 'date')
> > > > > > •db.Field(name, 'datetime')
> > > > > > •db.Field(name, db.referenced_table) # reference field
>
> > > > > > My vote would go to extending the web2py types to include some non-
> > > > > > relational types and
> > > > > > the first one would be that GAE ListProperty type.,..
> > > > > > Perhaps there needs to be some type of type-extension feature. NET
> > > > > > has
> > > > > > it.
> > > > > > So then the developers can develop and plugin their own types.
> > > > > > And there can be a pass-thru or 'raw' query mode which will pass a
> > > > > > native query down to the actual database handle.
>
> > > > > > We can't stop progress...
>
> > > > > > On May 3, 12:31 pm, Tim Michelsen <timmichel...@gmx-topmail.de>
> > > > > > wrote:
> > > > > > > Kless wrote:
> > > > > > > > I'm more interested into a framework backed by a non relational
> > > > > > > > db,
> > > > > > > > mainly MongoDB [1]. By that reason I discard Django, and to
> > > > > > > > Pylons
> > > > > > > > because it hasn't a plugin system that lets reuse/share
> > > > > > > > applications.
>
> > > > > > > > Is web2py ready to use non-relational databases?
>
> > > > > > > > [1]http://mongodb.org/
>
> > > > > > > I'd be interested in:
> > > > > > > *http://www.pytables.org
> > > > > > > *http://www.gaia-gis.it/spatialite/
>
> > > > > > > Regards,
> > > > > > > Timmie- Hide quoted text -
>
> > > > > - Show quoted text -- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
