pending...
On May 12, 10:19 pm, Douglas Soares de Andrade <dsandr...@gmail.com>
wrote:
> 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
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---
