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 - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
