Em Terça-feira 14 Abril 2009, às 23:26:40, mdipierro escreveu:
> 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.
Hi,
Whats the current status of this feature ?
> 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
-~----------~----~----~----~------~----~------~--~---
