Hi Massimo -
I will be at choir tonight (it's a "in one house" rehearsal w/ several
choirs) and go to Poor Phils, but I will need to ride home tonight (Joan
wanted "a break, with no phone calls" -- I have no idea what is going on...)
I have been tired / exhausted this past month, so I will not stay late.
Hope to see you!
Regards,
Yarko
847-668-8985 (cell phone)
On Tue, Apr 14, 2009 at 9:26 PM, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> 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
-~----------~----~----~----~------~----~------~--~---
