I have been thinking about this. Even if I do not like your proposal
Yarko, I think you have a better point than you think. In fact
form_factory would not work with my proposal syntax but it would work
with yours and that is a big plus in your favor.
I am tired so I think I am going to sleep on this.
Massimo
On Apr 14, 12:23 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
> On Tue, Apr 14, 2009 at 11:18 AM, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > but the user can already define its own
>
> > parse(text)
>
> > and use it
>
> > db.define_table(*parse(text))
>
> Hmmmm.... not pre-this discussion. Anyway, if you are talking about parsing
> to create one string so that your chosen solution is in gluon, then
> technically you are right. More to the point, you can NOW do this - parse a
> single string to create the equivalent SQLField calls for define_table()!
>
> > I am talking about *forcing* a new syntax to our users instead of
> > having everybody come up with their own shortcuts.
>
> ugh!
>
> We are talking about the same thing - only I want per-field syntax to be
> defined, and you want per-table - at the gluon level, this is the only
> difference.
>
> Per table, I argue, is too brittle, over-specified; I argue that per-field
> is the natural choice for this; you disagree.
>
> IF you really want to "force" this ("no choice"), then you do you want to
> drop SQLField and db.Field too?
>
> > The solution I propose introduce a simpler syntax to define tables and
> > set defaults.
>
> No difference in simplicity between what you suggest (per table) and what I
> suggest (per field tokens); in fact, I think per-field is simpler for a
> broader range of uses - you see this simplest for your intended use, but I
> argue it will narrow the scope of uses (what I mean by "brittle").
>
>
>
> > db.define_table('dog: name unique, owner person by name')
>
> One parser for tables - more complex, more difficult to define and explain,
> more difficult to validate, more difficult to change / extend (too coupled
> of a design - and I don't see any compelling reason!) --- for me this is a
> strong consideration. Perhaps you have defined a grammar to show that it is
> extensible, maintainable. In such case, my concerns become weaker.
>
> > The solution you propose allows users to do
>
> > db.define_table('dog', 'name unique', 'owner person by name')
>
> Yes - and ONLY this!
>
> > db.define_table(parse('dog: name unique, owner person by name'))
>
> Massimo - you are fishing for arguments, but your fishing hook still has
> only a worm on it! :-) You can do this now - you are right, no reason you
> cannot parse this string into a sequence of appropriate db.Field() calls
> now.
>
> > db.define_table(your_own_parser('dog: name unique, owner person by
> > name'))
>
> Of course, you do not need to type the calls literally --- you can do this
> now; actually, you can do BOTH of these last two now --- so I do not see
> any point here...
>
> 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.
>
> I do not see substance backing this - your argument for the last 2 of your
> three examples applies equally any web2py release, so it is merely an
> emotional argument (not a technical one).
>
> You are arguing for a new API for table definitions. I started by
> questioning the granularity of it. The 2 ways to define fields NOW is
> already not clear to web2py group ("Massimo - why do you use db.Field() and
> not SQLField()? What is the difference? When do I use which?" --- you will
> now add a third option; let's not build a PERL!).
>
> > 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.
>
> I do not understand why you bring in changing the constructor of SQLField
> objects or exposing functions --- I would merely cut by 1/3 or more what you
> already have in autofields(), no more than you have (only less), and leave
> the table-naming login in one place (take the duplication out of
> autofields()). No more. Maybe not even that.
>
> You added a private call to define_table; my suggestion only simplifies it.
> What I am suggesting is precisely less pervasive - but the least pervasive
> of all would be .... this has already turned un-interesting for me, not
> based on technical merrit, so I will not fuel that...
>
> Clearly, you REALLY want what you want. Fine. I have argued that it's too
> rigid from one perspective, and offered an alternative. I could also argue
> that it's superfluous, but am less convinced (haven't thought about that).
> I sort of like this suggestion, and am trying to understand what
> interesting uses / possibilities it might open. In thinking that, I see
> problems with the single-string concept getting buried down into gluon.
>
> I cannot change how you think or see things. I can only tell you what I
> see, why I think what I think.
>
> Kind regards,
> Yarko
>
>
>
> > 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
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---
