but the user can already define its own
parse(text)
and use it
db.define_table(*parse(text))
I am talking about *forcing* a new syntax to our users instead of
having everybody come up with their own shortcuts.
The solution I propose introduce a simpler syntax to define tables and
set defaults.
db.define_table('dog: name unique, owner person by name')
The solution you propose allows users to do
db.define_table('dog', 'name unique', 'owner person by name')
db.define_table(parse('dog: name unique, owner person by name'))
db.define_table(your_own_parser('dog: name unique, owner person by
name'))
thus breaking what could be a new unified syntax into two levels where
some of it is specified by web2py and some is left to the user.
moreover what now was implemented by only defining only one private
function called only by define table, would become something more
pervasive, requiring to change define_table, the constructor of the
SQLField objects and require one exposed function.
Any other options on this matter?
Massimo
On Apr 13, 7:22 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
> On Mon, Apr 13, 2009 at 7:04 PM, Yarko Tymciurak <yark...@gmail.com> wrote:
> > On Mon, Apr 13, 2009 at 5:28 PM, mdipierro <mdipie...@cs.depaul.edu>wrote:
>
> >> I can see lots of typos in people trying to do
>
> >> db.define_table('name','name string','birthdaty datetime')
>
> > Well - if the main goal is to have people type less, then this is not a
> > problem - can do this from an application / user interface;
>
> > If this is a way to store a table definition on GAE, then this doesn't
> > matter;
>
> > If this is a way to allow people to write programs (easily) to define new
> > tables (think of an issue tracking system, for example, where you can create
> > a tracked project, and describe custom tables) then this (multiple strings
> > vs. one string) is probably a better solution.
>
> > In any case, I'm not arguing for what you want - but your arguments are
> > "all over the place" - people typing; GAE storing....
>
> > I am arguing that all of these are possible, and have an appropriate place
> > - and that the CORE (gluon) level should be to handle PROGRAMMATIC INPUT
> > which is easily derived from user input (thru a controller), or easily
> > coalesced into whatever you may want for GAE storage of table meta-data.
>
> > I think that is what is at issue here - one of abstraction level, and which
> > is the right place to put what.
>
> If you add all the "kinds of things" --- GAE, user easy typing,
> programmatic table generation - the one thing they all have in common is:
> some text notation to describe a field. (Also, all the kinds of
> applications / use cases you haven't thought of yet would have this in
> common).
>
> It is this common factor that belongs being handled in gluon.sql - not
> application / use-case level stuff. That's what I am saying.
>
>
>
> >> vs
>
> >> db.define_table('name: name string, birthdaty datetime')
>
> >> I think we can support both notations. What do you think?
>
> > See my comments above. If you support both at the GLUON level, then I
> > argue you will have code bloat, and one piece that will be used by .... you?
> > classroom? people on the list who will ask you to make modifications,
> > instead of writing controllers / user interfaces / logic themselves? .....
> > in other words, I think it's possibly but now how I would do it.
>
> ..._not_ how I would do it. And more, I suggest (rather strongly) against
> the way you are proposing because I think it will reduce (rather than
> increase) uses, reliability, etc.
>
> > This comment:
>
> >> > for table in db(db.meta.id>0).select():
> >> > db.define_table(table.shorthand())
>
> >> I did not understand. table here is a record and table.shorthand would
> >> be a string value.
>
> > Correct - and my point was --- what do you care if
>
> Maybe it would be clearer to you if I said, for this application you put
> forth, what do you care if you have:
>
> - db.define_table(table.shorthand_string) # where gluon.define_table
> calls yet something else to parse, which application writer cannot ....
> CANNOT ever modify or change (e.g. result is something overspecified by
> web2py!!!!)
>
> or:
>
> - db.define_table(parse( table.shorthand_string)) # you can provide
> default parser at app level; I can write my own, but point is:
> gluon.define_table only deals with the common denominator: a token
> pattern for describing one field, and no more. That is well defined,
> easily extended by web2py, and leaves appropriate flexibility at
> application
> level.
>
> - Yarko.
>
>
>
> > - you provide a string, which then a gluon-level ("don't ever change
> > because of backward compatibility!!!") function will parse (and this
> > will
> > be brittle, because you cannot change or add without all the "usual"
> > concerns, so why do this at all?)
> > - or you provide a "standard" contributed function which at application
> > level will parse
>
> > In other words, the only thing that belongs in gluon.sql parser is for
> > single field definitions - write a grammer to handle that, and that's the
> > appropriate level for gluon.
>
> > Anything else YOU want (eg. one strting) can be processed at application
> > level to easily give the gluon functions the basic tokens.
>
> > This also leaves the door open to other kinds of uses which are the same
> > KIND of thing - like programmatic generation of table descriptors, user
> > interfaces for users to define tables, etc.
>
> > This is the better approach. (This is my strong argument).
>
> > Make sense?
>
> > Regards,
> > Yarko
>
> >> Massimo
>
> >> On Apr 13, 3:49 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
> >> > On Mon, Apr 13, 2009 at 2:11 PM, mdipierro <mdipie...@cs.depaul.edu>
> >> wrote:
>
> >> > > I agree that the syntax you propose is cleaner but why are we doing
> >> > > this?
>
> >> > > For me the reason is move functionality out of T3.
>
> >> > Ok.
>
> >> > > In particular we need a way to store a model in another model (think
> >> > > of a table of table descriptions) in order to be able to create models
> >> > > on GAE without going through the local development environment. The
> >> > > shorthand notation for me is just a bonus.
>
> >> > > Having the entire table represented as a single string accomplishes
> >> > > this:
>
> >> > > for table in db(db.meta.id>0).select(): db.define_table
> >> > > (table.shorthand)
>
> >> > Ok - but you are still talking higher level functionality here (single
> >> > string);
> >> > What do you loose from this:
>
> >> > for table in db(db.meta.id>0).select():
> >> > db.define_table(table.shorthand())
>
> >> > Nothing - it's just a matter of how much you push down into the core.
> >> > Putting _too_ much higher level assumptions low just blocks other,
> >> similar
> >> > (or unanticipated) uses.
>
> >> > ['table_name', 'field_name:field_type:field default'] ==> "table_name;
> >> > field_name:field_type:field default;"
>
> >> > Put another way, you are pushing a particular persistent storage issue
> >> down
> >> > into gluon (wanting a single string) - I question this.
>
> >> > There are numerous ways to store, so being explicit about what _kinds_
> >> of
> >> > uses you are targetting is important. You have stated one (and until
> >> now,
> >> > at least on this thread and in the code, it has been implicit; it's
> >> good to
> >> > make it explicit).
>
> >> > In any case, if you intend to write a single blob, it would be good
> >> exercise
> >> > to implement a parser, and then think about where each piece belongs.
> >> (this
> >> > actually looked interesting, as I scanned for parser generators:
> >>http://www.acooke.org/lepl/) <http://www.acooke.org/lepl/>
>
> >> > > Massimo
>
> >> > > On Apr 13, 1:59 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
> >> > > > On Mon, Apr 13, 2009 at 1:53 PM, Yarko Tymciurak <yark...@gmail.com
>
> >> > > wrote:
> >> > > > > On Mon, Apr 13, 2009 at 1:40 PM, Yarko Tymciurak <
> >> yark...@gmail.com
> >> > > >wrote:
>
> >> > > > >> I have a couple of immediate comments:
> >> > > > >> [1] - with this syntax, you do not process and fields or migrate
> >> > > > >> statements (but you _could_; suggest you do)
> >> > > > >> [2] - the autofields() function seems to mash concerns in other
> >> ways
> >> > > also:
> >> > > > >> it handles tablename update (? why here) in addition to
> >> "autofields";
> >> > > for
> >> > > > >> one thing, it does NOT do cleanup() (as define_table otherwise
> >> does) -
> >> > > this
> >> > > > >> is the beginnings of handling things differently in different
> >> > > conditions
> >> > > > >> (and a typical symptom of blurred boundaries of concerns).
>
> >> > > > >> Suggest you DO table name handling in _one place_, and field
> >> > > processing
> >> > > > >> (as you have) in one place, and consider that you only ADD
> >> > > "autofields" as a
> >> > > > >> new syntax for defining fields.
>
> >> > > > >> Having said that, it occurs to me that a comma separated text
> >> string
> >> > > is
> >> > > > >> just one layer of this, and it would be good to split this out,
> >> so
> >> > > that
> >> > > > >> web2py application developers could create things more
> >> automatically,
> >> > > to
> >> > > > >> wit:
>
> >> > > > >> [3] in sql.autofields() ==> for field in fields.split(',') ---- I
> >> > > would
> >> > > > >> make this do NO MORE than call an individual field processing
> >> function
> >> > > > >> (separate this functionality)
>
> >> > > > >> [4] I would add / allow a list to be passed (that is, allow the
> >> > > > >> application developer to _already_ have split the field
> >> definitions to
> >> > > "the
> >> > > > >> new text specification format") --- this will be much handier for
> >> > > automated
> >> > > > >> processing. There are a couple of ways you could handle this,
> >> one
> >> > > being
> >> > > > >> parsing *fields in define_table() to first split them out to
> >> string
> >> > > (or
> >> > > > >> list?) vs. function types, process all the string types by some
> >> > > > >> autofields_parse() function, collect and pass the rest to
> >> > > SQLTable(self,
> >> > > > >> tablename, *fields)...
>
> >> > > > > ... as I think of this, and of application developers I would ONLY
> >> > > process
> >> > > > > lists for the "new" syntax - there is no useful reason to have a
> >> string
> >> > > that
> >> > > > > the CORE then splits on ',' and only complicates the core....
> >> this is
> >> > > the
> >> > > > > kind of niceity that better belongs at the application level -
> >> either
> >> > > for
> >> > > > > the app writer, or in an admin (or other higher level function).
>
> >> > > > > So I now would prefer to see *fields argument to define_table()
> >> > > handle
> >> > > > > all field definitions, and based on type of ...field in fields'...
> >> I
> >> > > would
> >> > > > > collect them and process accordingly. If you _really_ want, you
> >> could
> >> > > > > insist that the fields list passed to define table be already
>
> ...
>
> read more ยป
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
