Off topic:
    Presentation advice:
        a2ps will convert code to postscript, try:
             a2ps -o vim.ps --pretty-print=perl --prolog=color code_file
        see man a2ps for details

        spod5 takes plain pod and makes an S5 slideshow (browser delivered)
        http://search.cpan.org/~book/spod5-0.02/
        http://meyerweb.com/eric/tools/s5/

        a LaTeX method: beamer
        http://www.ctan.org/tex-archive/macros/latex/contrib/beamer/
        http://sourceforge.net/projects/latex-beamer/

        perrin says that perltidy can make color-coded HTML

Most calls to get_param_hash on Gantry site objects should be replaced
with calls to params instead.  This also needs to change in AutoCRUD
and CRUD plugins.

---

While teaching tentmaker about controller level configs I discovered that
you cannot delete a controller block you made in the current tentmaker
session (full page refreshes might help).  This was a latent bug.

Stas would like docs/app.gantry.conf to by named for his app:
docs/appname.gantry.conf.

Do Controller configs which are distinct from app level configs result
in controller level inits and accessors?  (I doubt it.)  Should they?
Probably.

Tentmaker tests should test what is passed to templates instead of what
those templates produce.
    I simplified the first test in t/tentmaker/04_... so it doesn't check html.
    More work is needed.
    I've gone back to testing just the deparsed output, leaving HTML
    appearance for manual visual inspection.

When Pg8Live is used, your default database should be the PostgreSQL
database you used with Pg8Live.  The user and password should probably
also be recorded in conf.
    This might be hacked in to the new defaulting approach.  Perhaps
    get_minimal_default should receive a style (defaulting to kickstart),
    it could then deflect to a method in the style (passing all command
    line args?)

---

Stas noticed that the app.cgi script does not have a useful master conf
file and it ignores the one in the Conf Gantry block.
    I got this wrong.  He actually objected to the default name.  If you
    change it in the Conf Gantry block, it will work.
    I'm not overly concerned about this, as you probably want to use
    a single system wide Gantry master conf file, not one for each app.

Stas suggests that form fields should be generated into a file lexical
variable so they don't have to built as method lexicals on each call.

Augment Keywords.pm so it has detailed docs for all non-deprecated keywords.
    There are two parts to this.  First, an even shorter description is
    needed for the latex (and possibly web) table.  Second, a longer
    description taken from the existing book.

Merge tentmaker ref with Bigtop Syntax book chapters with new generation
script based on a template of the book text.

Write a doc about table perms.
    specifying the perms
    making them work to limit header and row options links
    using them with CRUD

We need new intro docs to feature:
    kickstart
    Gantry::Conf
    named config blocks
    life cycle (app.server <-> mod_perl)
    moxie templates

Stas says deleting fields does not remove them from the data statements
table.  But adding data statements always sends a clean and correct table.

Stas wants better tabbing order in the data statements table (so tab
moves down).  This may not be so easy as the tabbing order is now default.
    Maybe the data statements table should just stop fighting the current
    and have its data across instead of down.  The only disadvantage
    to that is excessive use of screen width.  The disadvantages to the
    current approach are numerous.

Stas thought using -c should move the source bigtop file into the
docs directory instead of copying it and inform the user of the move.
I'm still mulling this.

---

We should also load all the backends one at a time and see what keywords
they register.  And document the backends.
    This is two separate issues.  First, who registers which keyword.
    The solution to that might be to pass the registering class to
    Bigtop::Parser and have it provide the accessor to the all docs hash.
    Or it might be to simply put an array or hash called 'registered_by'
    in the keywords file.
    Or, we could have the registration code moved to a method called in
    the BEGIN block which the doc script could also call.
    Second is what backends are available and what conf vars do they
    understand.  That information is available by loading them and
    calling what_do_you_make and backend_block_keywords.
        The second one is done by skip/backends

Tentmaker ought to allow import list control for used modules.

Provide some mechanism for generating useful join table row insertions
(select many).

Allow a field to be marked html_form_type file, then in the template
present a file upload browse button and in the gen module, autocreate
add and edit post actions.

We should generate more for table1<->table2...
    Tag row option
    inherit do_tag from plugin? or implement one

When in limit by...
    all row option links should have the limiter's id as a trailing arg
    the form should be made aware of the limiter's id (if present) and
    switch to a display only field in that case

*> should generate limit_by for the many table?

*> should generate a pseudo-field (not for Model or SQL) of type
has_many, it would lead to the cool new Django like has many sub form.

AutoCRUD should pass all extra args through to all of the callbacks.
    This is a gantry issue, which I think Tim solved.

The genwrapper has a body tag with an id that has a blank value, which is
not allowed by xhtml.  It also follows that with a <br /> that doesn't
validate.
    I don't know what to do about the <br /> we need the spacing.
    And, this is a Gantry issue, since the genwrapper is just a straight
    copy of sample_wrapper.tt from Gantry's root dir.

The mysql SQL backend should have a config block param called engine.
Use of it would add ENGINE=value after each create table statement.

I don't think database defaults are working from forms.  The problem
is probably that the autocrud form handler is setting empty fields to '',
so the default is not taking.  Perhaps there should be special cleanup
for add only which would remove blank fields?

When two fields from the same table are marked as dates, the javascript
for calendar_month_js is being added twice by tentmaker support in the parser.
This happens even when date select text is edited, even if it was already
marked a date.
    We might want to address this by moving to an entirely new approach to
    pop-up date entry.

---

I should probably change tentmaker to jquery.  Among other things this
would facilitate changing the text from edit to done on show/hide hrefs.

app.server could get a GEN module of gen conf and gen locations which
users could augment.

Do something for generation of AjaxCRUD users.

Teach tentmaker about join table field blocks and table and join table
data statements.
    Repeat this for join tables (or make them more like tables)
    Left for table data statements support:
        x when a new field is added, add a row to data statements table
        deleting fields does not remove them from the data statement table
        x new data statements are not supported:
            x replace warning with code in Parser (line 2254)
            x add another column to the table when the empty one is used
        x when the last column of a statement is blanked, remove the statement
        x switch to testing for '' instead of truth for removing column keys
    I think we need to regenerate the data edit box from a template whenever
    an update occurs, or at least when a statement is added or removed,
    or at very least when a statement is added.

Teach tentmaker about controller level literals.

Pg8Live script help style does not support join tables.
    It probably won't, since join tables don't get to have controllers.

In ascii art, if you ask for id without giving a type, you currently get
varchar.  You should get the default int4, primary_key, auto.
    You should just take the id given to you, smile and ask for another.

Should a table name change cause a cascade of field name changes for
all the foreign keys which point to it?

Why do controllers have to have locations?  Shouldn't the backends that
assign locations just skip them?

Boolean means nothing to bigtop.  If the field's type is select and
it 'is' boolean, bigtop should make options (unless the source has them
hard coded):
    options => [
        { value => 't', label => 'Yes' },
        { value => 'f', label => 'No'  },
    ],

CRUD generation is making text_description, get_orm_helper, and
get_model_name methods.
    Investigate this, it doesn't always happen, see:
        t/gantry/playship/Apps-Checkbook/lib/Apps/Checkbook/GEN/PayeeOr.pm

When you change a method or controller type, tentmaker should completely
refresh the statement edit div so the statements applying to the new type
are the only ones visible.
    Please figure out how to do the right thing with AJAX instead of
    a refresh.  Asking the user to remember to refresh is better than
    doing it for them.  At least then their sliders stay put.

Could column name changes lead to the immediate construction of an alter table?
    I think tentmaker should print the alter table statements to stdout,
    but the backend should also append them to a log in the docs dir.
    You'd have to read the log carefully, but the commands would be there.
These would just be side effects of renaming or adding things in tentmaker.

When a table name changes, spew table alterations as for field name changes.

When you change engines in tentmaker, should it also magically change
backends?  CGI->mod_perl would unclick CGI backend and click corresponding
HttpdConf backend and vice versa.  If CGI backend had generate root
checked, add a root var to conf with build dir html as an absolute path.
In the other direction, do the opposite and always check generate root.
Generate root should be superceded by an genuine root conf var?

Table field blocks should allow accessor which tells the ORM to use that
name for the accessor.

---

It might be nice if foreign displays in main listings linked to details
for the other table.  (But then, not all controllers have details.)

Remaining issues with base_controller blocks:
    These errors could be reported:
        using a rel_location in a base_controller block
        using an app level location and a base_controller location
        app level uses statements are ignored if you have a base_controller
    tentmaker does not indicate which method statements apply to *links methods
    tentmaker does not indicate which controller statements apply
        The last two are now solved by tentmaker showing only appropriate
        controller and method keywords based on types.

A stray semi-colon after a config block yield a crummy error, without even
a line number.

Build.PL's default for tentmaker template installation dir should be
drawn from system installed TentMakerPath.pm if there is one.

tentmaker should be taught to make and manage controller level config blocks.

Factor gantry specific code out of the parser.

Skip Config in HttpdConf Gantry is a duplication of supplying a Conf
Instance.
    This is not quite true, since you could be using Frank's approach
    without Gantry::Conf, but then there should be a flag for it too.

tentmaker does not support controller level literals (GantryLocation of
HttpdConf).
Worse, deparser ignores them.
    Deparser knows about them now, but there is still no way to make them
    in tentmaker.

Make a way for literal SQL to be backend specific.
    literal SQL for Backend
This requires a slight grammar change to add an optional for Backend
clause.  It would then have to associate that backend with the tree node.
Some change to make_output might be in order.  Or the backends literal
block could be asked to add the gaurd.
When you fix this, change Bigtop::Docs::Syntax to reflect it.
    We could also do this by moving to:
        literal Postgres
        literal MySQL
        literal SQLite
    while keeping
        literal SQL
    to mean for all of them

Should bigtop --create default to all build?  Should it always default to all?

Allow rearrangements of app body blocks via ajax drag and drop.

When values are entered in tentmaker input boxes which are currently
triggered by buttons, add respect for carriage returns.

When a backend is selected in tentmaker, read in all the text boxes and
set them as statements in the backend block in the top level config block.

Make a scheme similar to the backend what_do_you_make scheme for Gantry
Engines and Template Engines, so tentmaker can dynamically provide its
'Bigtop Config' choices.
Make tentmaker sense all Gantry::Engines on the box.

Allow for multiple config blocks with user defined types:
    config for default {}
    config for dev     {}
    config for prod    {}
    config for phil    {}
    config for tim     {}
and a way to pick one of these during generation:
    bigtop --config=phil --create file.bigtop all
or generate them all and give app.server a flag to pick among them

Why is a missing controls table only a warning?  Could it refuse
to build the stub iff there is a main_listing, form, or crud_form but no
controls_table statement?

    Allow cells in main_listings to be hrefs.  (See customer search page
    of Quixote.)
        This requires a change to Gantry's results.tt.

    handle internal alignments, e.g. in schema.sql it should be like
        name    varchar;
        address varchar;
    not
        name varchar;
        address varchar;
    This would really require only a bit of extra work.  Consider.
    Assume a width for the keyword on the left.  If the actual word
    is longer tough, but everything else would still be aligned.
    The templates can make adjustments like this.
        Low.

    Make the grammar report better errors.
        Place holder for problems found in the future.

    Keep the vim syntax file up to date.
        Place holder as a reminder.

Not to be Done:

    Tentmaker should discourage people from creating fields with
    duplicate names.
        Warnings of this type are not really in tentmaker's nature.

    Further, -> is model only foreign key => is both model and SQL.
    But the goal is to pull this from Postgres as well.
        I decided that -> will just give you a genuine foreign key.  If you
        don't want that, edit the result.  Same goes for Postgres.  If the
        database you are loading has foreign keys, so will the generated SQL.

    bigtop -n AppName
    without a table list is generating, but not generating everything.
    In particular, it does not make app.cgi, app.server, or anything in
    lib.  Immediately running bigtop docs/appname.bigtop all makes those things.
        I think this is correct behavior.  while you could immediately build,
        that would make stubs

    A heart beat to the server might be nice when you do things in the browser,
    to make sure the server is up.
        The recommended way to stop the server is now from within the browser.
        This lets the browser set a server down flag to prevent you from
        thinking you are working when you are not.

    app.server is always calling the db app.db, even when the config says
    something else.
        You can use flex_db and provide -n on the command line:
            ./app.server -n dbname

    Comments could be incorporated into the grammar.  They could become
    statements or blocks which could then survive tentmaker deletions of
    neighboring blocks.  Or I could just stop worrying about them.

    When the tentmaker reloads, it would be nice if the focus could return to
    any create box next to a create button that triggered the action.
        tentmaker no longer reloads

    We need more tests of how tentmaker builds and modifies the tree rather
    than just whether deparser can make the proper sense of the result.
        Now that deparser is complete, I don't think this is a real issue.

    When the tentmaker reloads, it would be nice if the focus could be in...
        I take that back.  There is no reasonable place to put it.
        The field you just left is bad because of recursive triggers.
        The next field is just as bad because leaving it will trigger.

    Remove or down case prepositions when forming default names based
    on a table name.
        Overly magical and surprising.  Bound to cross someone up.

    Make auto crud update created and modified times by default (in Gantry).
        Ruled out.  I couldn't find a database indepenedent way to do this.

    Clean up the app pair statement code.  It could probably be integrated
    into the regular app statement change code.
        While there is some duplication, the call workflow is clearly separated
        currently.  Integration would require changing the code which updates
        non-pair statements.

    Move keywords registered in Parser.pm to a more logical place.
    Consider Init.pm or Conf.pm.
    Some of these should really be in the Control.pm (think engine
    and template_engine).
        I don't think there is a backend type that everyone can always
        be expected to load.

    Fatal errors from bigtop should be trapped and reported as warnings.
    This allows the rest of the gen to work.
        There is no harm in fixing the error and rerunning.  Anything
        that wasn't already written is written at that time.  Anything that
        worked stays.

    Unify the naming of AST node keys so that code can be shared across
    packages.  Move common code into two or three non-node ancestor
    packages.
        Nice, but only affects Bigtop::Parser which already works.
        Note that not everything can be shared in obvious ways.
        In particular, direct inheritence is generally useless since it
        leads to too much sharing.

    Make a way for Build.PL to be regened (MANIFEST has a target in Build.PL)
    with knowledge of what was gened.
        Low priority.  These changes are infrequent and minor.
        No.  This must be hand maintained to catch things like prereqs.

    factor setup_template out of the backend modules (into WADL.pm?)
        This turns out to be difficult since Inline::TT normally binds
        to the current package and convincing it to do otherwise was
        beyond me.  I should write to the Inline list for advice.
        Very low, essentially cosmetic in the source code.

    Possibly include do_main (which sets main.tt) in the base module.
        Low.  (but Tim might say otherwise)
        We both thought better of this.

    Possibly include do_default (fallback) routine in base module.
        Low.  (but Tim might say otherwise)
        We both thought better of this.

    Add a force flag scheme so stubs can be regenerated, but only on
    demand.  Backup in this case.
        Medium.

    Add a force command line flag to bigtop or a new script which
    overrides the the no_gens in the file.
        bigtopforce Control:name
    It still shouldn't regen a GEN method marked no_gen.
        No.  If the users wants to regen a stub, they should delete theirs
        (or more likely rename it).  Then regular generation will make a
        new one.  I like being able to say: "It never overwrites a stub,
        full stop."

    Add comment stubs for methods imported from uses statements.
        This is just litter.

Bug fixes:

    When you run tentmaker meaning to start a new project, but omit the
    -n flag, the error message is:
        Couldn't read AppName
    which is OK, but it continues:
        usage: Bigtop::Parser->parse_string(...) at Tentmaker.pm line 49.
            New message:
                Couldn't read 'AppName': No such file or directory
                  perhaps you needed -n?

    The generated app.server should not have the incompatible flags if test.

    Bigtop is no longer generating nav links.

    Stas says data statements in tentmaker cannot take values including
    slashes.
        He was right, data statement values were not being encoded by
        the javascript ajax dispatching function.

    The tent tut and tent ref pods need new screen shots.  The old ones
    got lost in a web site move and they were out of date anyway.

    Stas noticed that attempting to change the engine immediately after saving
    results in:
    error: Can't call method "set_engine" on an undefined value
    at /usr/lib/perl5/site_perl/5.8.8/Bigtop/TentMaker.pm line 352.
        In fact, tentmaker pretty much collapses like a cheap tent after save.
        Fixed by no longer trying to read the just written file.

    Stas noticed that when you inadvertantly click in a text area like
    contact_us, tentmaker makes the statement, but leaves out the value
    entirely.  It should at least make a `` value for it.  Better, it
    should remove statements with blank text values.

    The following were all symtpoms of the same problem:
    Stas got Error changing statement: Couldn't change field statement from
    tentmaker when he tried to remove a constraint previously added to a field.
    Stas said: adding a new field to an existing table in tentmaker and then
    setting it to searchable gave uninit value warning TentMaker line 320.
        Removed work around that dealt with HTTP::Server::Simple bug
        (since corrected in that module) which prematurely unescaped percent
        encoded slashes.

    ASCII art is not properly applying default columns.  Here is the needed
    change:
        When a table is mentioned without columns, never put anything in the
        columns hash.
        When all is finished, add default columns for all new tables which
        are not already represented in the columns hash.

    tentmaker is not showing row option locations.  On mac book see:
        ~/writing/linux-mag/gantry-one/take3/docs/billing.bigtop
    Worse, editing row options ends up loosing the location entirely.
        This was caused by HTML quote confusion.

    tentmaker parameters should be passed via query strings to avoid early
    unescaping by HTTP::Server::Simple which leads to broken URL params when
    slashes are part of the value.
        May not be a problem in the current H::S::S version.
        This is not a problem with 0.27, so I made that the minimum req.

    Tentmaker does not update the field name in the expanded box, even though
    it changes it everywhere else.

    Apparently join table fields are not being added to the model, they only
    appear in the SQL.

    Fix site links and base controller default do main, so they get the slashes
    right.  This also requires removing app_rootp from the genwrapper footer
    nav links.

    Finish fixing tests so they never care what year it is.

    Generation of genwrapper.tt is putting it into the html subdir.  It
    needs to go into the html/templates subsubdir so the generated Build.PL
    can find it.

    Deparser is doubling backquotes on this foreign_display:
    foreign_display `%last_name, %first_name: %user_name (%screen_name)`;
        This happens because of the colon in the value.

    many-to-many generation is wrong:
        job<->skill should have these in job:
        __PACKAGE__->has_many( job_skills => 'JobAd::Model::job_skill',
                               'job' );
        __PACKAGE__->many_to_many( skills => 'job_skills', 'skill' );

    in ~/Bigtop/play/Address on ren:
    bigtop docs/address.bigtop all
    Use of uninitialized value in pattern match (m//) at
    /usr/lib/perl5/site_perl/5.8.3/Bigtop/Backend/Control/Gantry.pm line 2747.
    Use of uninitialized value in concatenation (.) or string at
    /usr/lib/perl5/site_perl/5.8.3/Bigtop/Backend/Control/Gantry.pm line 2755.
        supplied an empty string as the location when none is provided
    Error: no location or rel_location defined for controller base_controller
        instructed SiteLook GantryDefault backend to ignore base controllers

    You can't really mark MANIFEST.SKIP and Build.PL as no_gen in Init Std
    backend, since their names have dots embedded.

    Values in data statments under Deparse are having newlines inserted after
    each comma.

    When config values have colons in them, deparse is not quoting them.

Done:

    Generated CRUD stubs never have any of their do_add, do_edit, or callbacks
    listed in POD => podcoverage failures.
        I'm not sure when this got fixed, but it did.

    Controller level plugins are ignored, if don't need a GEN module.
        Now using controller level plugins always results in a GEN module,
        even if nothing else is in it.  But, you get your plugin.

    Controller level plugins now have a namespace, but it differs from the
    Apps top level namespace, so the top level plugins need to be repeated in
    the controller's list so they can register the callbacks again in the
    proper namespace.

    Generated namespace and schema_base_class methods are not getting docs in
    GEN modules, this leads to pod test failures.

    Tentmaker should treat controller level config blocks as well as it does
    app level config blocks.

    Stas would like gantry conf files to use indentation for readability.
        Thanks to Stas for sending a patch to do this.  Reability is improved.

    Controller plugins don't give you a namespace.

    Now that there are so many generated doc pieces (including vim
    syntax), it would be nice to have a script to run all the automaters.
    If that could be part of ./Build dist, so much the better.

    The QuickStart pod doesn't use the new flags for controlling databases.

    Remove abandoned docs and make TOC more prominent.  Rework Syntax.pod.

    The new instance based scheme is not all that great since is doesn't
    provide an automatic way to change databases at the command line in
    app.server.  You have to manually make a conf block with a name you
    like, then put the dsn in it.  Messy!  This should be automated.
        Solution: foreach model other than SQLite, make a config block in
        default (from script help) named for the database
        We might want to restore the -n and -p command line flags (or not)
            No.  Simpler.  I just restored the old flags to override conf at
            the command line.


    Users can now have their own default.  Place it in a template called
    bigtopdef in the directory from which they run bigtop -n or tentmaker -n
    or (if no such file exists) in ~/.bigtopdef.

    We really want to allow users to provide their own minimal default.
    Key: get rid of get_big_default in ScriptHelp and always use
    get_minimal_default combined with the augmenter.  Then the user's minimal
    default can drop in.
        Actually, get_big_default stays, but now uses get_minimal_default
        and then augments it.

    In tentmaker, config should be a block type you can create.  The config
    tab should go away.  You should also be able to create multiple
    config blocks in controllers (in addition to making methods).

    Whenever bigtop generates use strict; it should generate use warnings;.

    Tentmaker now treats config blocks like other app body blocks.

    Controller level configs are resulting in inits and their accessors going
    to stubs instead of GEN modules.

    Generated bigtop values which include Perl code should always use q or qq
    quoters.  This includes at least the default legend extra key in form
    methods.

    controller_config methods are showing up in documenation link in their
    stub, but not as comments like do_main or form.

    When a method has no type, the bigtop error is strange.  See Dell laptop
    ~/Bigtop/play/error.bigtop

    t/bigtop/01_twotable.t should have a test for Gantry, without which it
    is doomed to fail.  Versioning might be necessary and the best remeady
    may be to exclude that test from the MANIFEST.

    Now that app.server scripts take -i instance and -t type from command line,
    we no longer need to generate multiple versions of them.  app.cgi might
    still be another matter, since presumably each one has a different
    instance.

    Bigtop's plugins top config level keyword is not being used by the
    test generation in Control Gantry backend.

    We have a new bigtop level config keyword plugins which affects everything.
    We need that at the controller level, so individual controllers can use
    plugins that would interfere with other controllers (like SOAP plugins do).

    All uses keywords should show in tentmaker as being pair optional.  Test
    to see what the values need to be.

    Sequence creation should be retired from tentmaker.

    Tentmaker should never use labels for keywords.  It should just use
    the keyword itself.  This will simplify descriptions in the book and
    in other docs.
        It still uses labels in the html for app body creation and display.

    We need a new main_listing keyword: row_option_perms which takes a list
    of pairs.  The keys are link text of row_options, the values are
    'create', 'update', 'retrieve', or 'delete'.  These override the following
    defaults.
        Edit            is update
        Update          is update
        Delete          is delete
        everything else is retrieve

    Stas thinks tentmaker backends tab could be clearer if the center column
    was narrower and the right column had name, input element, descr on one
    line.  Or perhaps the description could be in the second column to move
    it out from under the names.  Or perhaps there could be a miny hr under
    between the keywords.

    We need to have config for TYPE { } blocks which make seperate files.
    There would be a governing config block (the existing one).  It would
    fix the accessors and init work.  All other config blocks would get
    the values from the controlling config block, unless they supplied
    the same name to override it.  This should apply to controller level
    config blocks as well, but that could wait.  It would only work for Gantry
    conf, all others would still get only what is in the main config.
        All of these backends handle conf:
            Xx CGI       Gantry
            x Conf      Gantry
            - Conf      General (deprecated, not updated)
            Xx HttpdConf Gantry
        Each of them should write additional files for each additional conf
        block, using the conf block name in the generated file name.
    We need to revise this so it works for controller level literals as well.
    What I really want is for Parser.pm to build a structure that has all
    the conf by location and type.  Then every backend can call that and use
    it without having to separately walk the tree for it.

    Stas suggests that re-clicking edit when finished edit (to conceal the edit
    box) is counter-intuitive.  When a show_or_hide is revealed, the text on
    the href trigger should probably change from 'edit' to 'done' or 'hide'.
    Alternatively, an ever present done link would work too.
        I just changed the link to read 'edit or hide'.

    Stas points out that app.cgi and app.server should complain (probably
    during generation) if the engine selected is not CGI, without which they
    cannot function.  Do two things:
        1. warn during generation that CGI backend must use CGI engine not MP??
        2. generate app.cgi and app.server with CGI engine regardless
        The warning:
        You have requested engine MP20 and CGI Gantry.
        app.cgi [and app.server] must use CGI engine not MP20.
            No warning.  You couldn't really want that and you might want
            to keep the stand alone server for faster dev restarts after
            selecting mod_perl for deployment.

    Stas renewed an old request: have Bigtop's build reinstall to the existing
    template directory if there was one.

    Stas wants the browser to pop to the top of the first tab whenever you move
    to it.  Perhaps it is time to hide the bigtop source dump.  He also wants
    more save buttons littered around on other pages (perhaps next to the last
    tab).  Save as would still be on the first page.

    Stas suggests that when generated app.server, the #! line should use
    the current perl path ($^X) and not just slam /usr/bin/perl in it.
        I also did this for app.cgi.

    The auto documenters should definitely use templates, probably inline ones.
        I take that back.  It's really six to one, half a dozen to the other.
        See the current /skip subdirectories for examples of each.

    Bring vim file up to date.  Add docs for all new keywords to relavent
    places.  These include:
        doc_rootp           \______ conf vars (in gantry docs)
        show_dev_navigation /
        html_...
        order_by \_____ main listing
        limit_by /
    This is done in vim file.  But the docs still need updating.  See the
    svn log for the vim file for a list of new keywords.

    Write an automated documenter that will pull the information from
    Bigtop::Keywords and display it in a reasonable way, say an
    expanding/collapsing javascript widget of some sort.  Or perhaps
    just a pod that is updated with sections for each keyword type and
    an =over/=back set for all the keywords there.
        Perhaps a doc should just explain that Keywords.pm is definitive
        and let programmer read for themselves.  This might require adding
        a 'long_descr' to the Keywords hash keys and possibly 'examples'
        as well.
    It still might be nice to add long_descr.

    There should also be a script which uses Bigtop::Keywords and makes the
    vim syntax file.

    Bigtop should put its own version number into the changes file for the
    initial build.

    Provide a better way of sharing a form between AutoCRUD and CRUD or
    at least provide some help for public vs. private forms.
        Forms should always go in the gen module.  You can override them
        as needed.  Gantry::Utils::FormMunger works wonders.

    Foreign keys should lead to has_many statements in the foreign key table's
    model.
        There is a new refered_to_by keyword for tables.
        Command line tools generate this for all foreign keys in -n and
        -a modes.

    Main listings should have order_by.

    In the generated do_main, any calls to foreign display should be wrapped
    with evals and warnings issued with default blank.

    Tim wants *> as a synonym for <- in ASCII art.

    You should be able to type your ASCII art into a file and feed it to the
    program.
        If there is only one parameter to -s Original, and -f for it is true,
        that file is used.  If there are no args?  (see if there is anything
        on stdin?)
        I decided against taking standard in since these scripts cannot be
        meaningfully used as filters.

    The generated app.server should have static in it by default, including
    the conf needed to make it work (doc_rootp => '/static').

    Expand the generated root to html:html/templates not just html/templates.

    Add a file_filter_ok to Test::Files, so copyright year can be fully done.

    Perhaps we should add on_delete and on_update which would be
    honored when using refers_to's pair form.

    I want to add a really_refers_to keyword for tables which would generate
    a genuine foreign key in SQL in addition to making the column behave that
    way in the model.
        I opted for making refers_to take an optional pair:
            refers_to table_name;
        gives old behavior, while:
            refers_to table_name => col_name;
        adds REFERENCES table_name(col_name) to SQL column definition.
        The pair form is the form used for all command line table creation.

    When bigtop is invoked with a backend type name which is mispelled,
    it quietly does nothing.  If it doesn't find anything to do, it should
    tell you with a warning and offer a list of choices.

    Make sure new ascii art is documented.  Do it in only one place (the
    Original script help style).  Replace other sections with references
    to the one true place.

    More ascii art:
        'table1(req_field,+optional_field,field_with_default=value)
    so leading + makes a field optional.  Independently = gives a default.
    get_db_layout should report default and optional as new keys in the
    columns subhash (along with the existing keys name and types).  This
    also affects Pg8Live.  It should clean the default so it can become
    an HTML form default in addition to a database default.

    Move all modules in docs from .pm to .pod.

    I want to expand the ASCII art to this:
    table1(col1:type;col2:type)->table2(col1:type;col2)

    I want tentmaker and bigtop to admit new replacements for ASCII art.
    Proposed syntax:
        tentmaker -n App --style Original 'table1->table2'
    Original would be the default style.  Each style would be a module in the
        Bigtop::Tentmaker::Style::...
    namespace.  The module would have to have a sub called get_db_layout,
    which would receive all remaining command line arguments in one array ref
    and the right to consume standard in.  It would return a structure or
    structures yet to be designed.  For a start that structure could just be
    what the current parse_ascii_art script from Bigtop::ScriptHelp returns.
        Step 1.  migrate the existing code to depend on B::T::Style::Original
        Step 2.  expand the returned structure to include optional column names
        Step 3.  ... and types
        Step 4.  add support for genuine foreign keys
        Step 5.  make a Postgres parser

    The new --style scheme should support specifying column names, types,
    genuine foreign keys, and other valid SQL column declartion clauses.  The
    thought is to bridge from existing databases to bigtop.  Doing this would
    provide both controllers and models for the database tables.
        Foreign keys are still never put into the generated schema files.

    Current ascii art allows types, but they must not contain spaces, since
    those are used earlier to split the relationships.  The bigger problem
    is internal parens as in varchar(15).  If you need spaces, just use extra
    colons.  It'll look funny but come out in the wash.
        I should switch to Text::Balanced for extraction of column name/type
        info.  This was of course in the back of my mind, but once again I
        naively thought, "I'll never need to nest the parens."
            I did switch to Text::Balanced.  There are still problems, but
            it works more than 90% of the time include for varchar(12).

    Have tentmaker trim leading and trailing whitespace from ASCII art before
    trying to use it.

    tentmaker should die if -a is used with no file instead of just warning
    about it.
        all errors during tentmaker startup are now fatal.

    Something is wrong with literal insertions in tentmaker.  This got cut
    off after the first paren:
        use lib qw( /home/phil/Bigtop/examples/Kids );
    when I tried:
        use lib '/home/phil/Bigtop/examples/Kids';
    it got cut off after the first '.  Perhaps slashes are not being properly
    encoded?  They were being prematurely decoded by some versions of
    HTTP::Server::Simple.

    Generated do_mains should allow control of which rows are included,
    possibly based on extra_args to the sub.
        there is a new keyword: limit_by for main_listings.  Use it to
        specify a single foreign key to limit results by.  If a parameter
        is passed to do_main, it will be the single foreign key value to
        show in the listing.  If no parameter is passed, all rows are
        shown as before.

    Bigtop and tentmaker don't know how to add html_form_raw_html.

    When a field has form_type select -- and it is not a foreign key -- appears
    in the main_listing, its values should be mapped via the options hash so
    they show up on screen as they were selected and not as they are actually
    stored in the database.
        The model should get a hash and a method:
        my %select_map_for = (
            NAME => {
                dbval  => 'label',
                dbval2 => 'label2',
            },
            NAME2 => {
                dbval  => 'label',
                dbval2 => 'label2',
            },
        );
        sub NAME_display {
            my $self = shift;
            return $select_map_for{ NAME }{ $self->NAME };
        }
        Then the main listing can do something like what it does for
        foreign keys:
            data => [
                #...
                $row->NAME_display,
            ]

    When fields are deleted, the users of them are not updated.  This should
    include:
        controller main_listing cols
        controller form fields or all_fields_but
        table foreign_displays
            call update_foreign_display with old_value equal to name removed
            and new_value equal to ''.

    --create does not try to make the sqlite database (if you are using
    that backend) nor does it give advice on how to start the app.
        Since SQLite is the only one which might work, it is the only one
        that should be tried.  This should be in same manner as -n.

    tentmaker needs to convert to query string parameter passing for method
    parameters, not least because HTTP::Server::Simple version 0.22 forcebly
    unescapes %xx in urls before Gantry can get hold of it making Save As
    paths break (they look like multiple pieces instead of one path).
        Actually, it just needs to join path pieces with OS path separator in
        do_save.

    You should be able to use data statements in a join_table.

    You should be able to add extra fields to a join table, perhaps it should
    really be a synonym for table which allows joins and name statements.
    Perhaps tables should have types like methods do and the types would start
    as regular (default) and threeway.
        I just hacked these into the grammar, it wasn't too painful.

    CRUD generation should make the do_add, do_edit and do_delete to do
    the most normal thing with DBIx::Class.  You can't use them with an
    arbitrary ORM anyway.  This might also apply to the callbacks.
        This already happens, since the following item was fixed.

    CRUD generation for do_edit is still assuming cdbi.  It should be neutral.

    tentmaker is slow starting on systems with big @INC paths.  Make a new
    method in Bigtop::TentMakerPath which returns the @INC path where the
    backends were stored.  By default, look only there.  Provide a flag to
    add dir and another to search all of @INC.
        Example to get your started:
        #!/usr/bin/perl
        use strict; use warnings;

        use Bigtop;

        foreach my $key ( sort keys %INC ) {
                print "$key : $INC{$key}\n";
        }

    tentmaker should have a --help and -h which give the three common starting
    forms:
        If you already have a bigtop file and don't need new tables:
        tentmaker filename.bigtop

        If you already have a bigtop file but need new tables:
        tentmaker -a filename.bigtop 'new_table->old_table'

        If you are starting from scratch:
        tentmaker -n AppName [ 'table_list->including_relationships' ]

    The dist includes examples which aren't in the Bigtop::Examples namespace.

    I want a way for tentmaker keywords to know what types they apply to.
    Then the statements should only appear if the type matches.  If you change
    the type, I'm not going to worry about existing inapplicable statements.
    They are not syntax errors, they are just ignored.  If you bumped the
    type changer, you can recover by moving it back.
        The problem is that when you change the type nothing in the statement
        box changes.  We need an ajax response for that.  Yet, I want this
        feature, since I think type changes are rare.  For now, if you change
        the type, you must do a manual full refresh to get the additional
        statements.

    We need more testing of base controllers.

    Finally, we need to verify that the statements really apply to their type.
    This is particularly important for base controllers.

    10_run.t is not handling base controllers correctly.  It is always putting
    a / Base location in, and when there is a base controller, it is making
    a App::base_controller location.
        it needs to respect skip_test
        it needs to omit the base_controller duplicate
    In fact 10_run.t never respects location (which makes sense, since the
    stand alone server can't handle them).

    I'm wondering how wise it is to explicitly ask for imports in gen modules,
    since the stub also usually uses the same modules and the exports are
    then taken twice: once at the GEN (parent) level and again at the stub
    (child) level.
        There should really be two statements: stub_uses and gen_uses you
        should never get both for free.  Existing uses statements should be
        treated as gen_uses since stubs can't be regened.
        Actually, I don't object to having three statements: stub_uses,
        gen_uses, and uses (both).
        Note that magical uses caused by controller type are not affected,
        since they are only brought in to the stub.
    All three statements are now available.

    When a join table is created in tentmaker, the name boxes are not both
    red.  It works fine if the table exists or is created during start up.

    Tim reminds me that buried below is a request for an app level block called
    base_controller which would affect AppName.pm and GENAppName.pm.  This is
    especially useful for one controller apps.  It would subsume the app level
    location and uses statements (if you had them at the app level they
    would be ignored).  But, it would add the ability to include methods.
    This is mainly for one controller apps.
        It could be controller AppName is base_controller {}.
        Or, is could be base_controller { }
        Or, as it turned out controller is base_controller {}.
    At first I liked:
        base_controller {}
    thinking that it was separate.
    But the more I think, the more I like:
        controller is base_controller {
        }
    So it is a regular block.  So much of what is legal in it and what it needs
    to do is similar to the other controllers, this makes the most sense.
    Questions:
    1   What do we do with legacy bigtop files which don't have a controller of
        type base_controller?
        We spoof one.
    2   What about things that are not legal in base_controllers:
            rel_location comes to mind (ignore it, possibly with a warning)
    3   How do we handle their locations?
        If a base_controller is used, it may have a location (or you keep using
        the app level one).  rel_location won't have the desired effect.
        Currently no errors are called here.  But some that should be include:
            using a rel_location in a base_controller block
            using an app level location and a base_controller location
            app level uses statements are ignored if you have a base_controller
    Can tentmaker provide some assistance with this (by say indicating that a
    controller statement can only occur for a certain type of controller?
    If we had a general solution to that, we could leverage it into method
    statements.  All of that might just be overkill.

    Original version of request above:
    There should be a special top level controller block like
        root_controller [ is type ] {
        }
    which can take all the statements and blocks a regular controller can
    take.  This will put code into the app's base module.  (Syntax is
    subject to discussion, but I object to bare words at the app level like
    controls_table etc.  Although there is already a location directive, but
    since you have to have it (or take the default) and in other controllers
    you must have exactly one of location or rel_location the app level
    can't really function as a controller block without more work.)
        These keywords should move from the app level into the root controller:
            location [ defaults to / ]
            uses
        These keywords should be introduced for the root level controller:
            controls_table
            text_description
            autocrud_helper
        The legal root controller types would be the same as the controller
        types.  The root controller could have method blocks just like
        other controllers.

    Reorganize the sql_block subrules so they are more like the control_block
    ones.  Namely, stop blessing different kinds of things into the same
    class, then if testing on attributes to tell them apart.
        This has largely been done as of about 0.16.

    Find a way to wedge bigtop syntax in the tent maker reference chapter in
    the gantry book.  Or have a chapter on it.
        There is a chapter for it: bigsyntax

    Continue work on improving the AST.  Read the Modules doc and the
    gantry book chapters about the tree, concentrate on things marked awkward.

    When tentmaker sets the paged_conf it could magically add the conf var
    with a good default.
        Work flows:
            paged_conf added as a new statement
                see if there is a conf statement of the same name
                if so, leave it alone
                if not, make one set its value to 20
            paged_conf removed as a statement
                do nothing
            paged_conf is changed
                see if there is a conf statment of the same name
                if not, add a statement with the same name

    Add paging as the default behavior of main listings.
        This requires a Gantry change to: Gantry::Utils::DBIxClass, but could
        be an additional method there and control in bigtop for which one
        you use.  Control could be via new controller type: paged_listing
            Looking closer, Gantry::Utils::DBIxClass get_listing already
            returns the result of search (context may be an issue).  If you
            supplied page (and optionally rows) this should give you a
            resultset on which you can call page (to get your rows) and
            pager (to get a Data::Page object).  These can be fed to the
            existing standard templates.
            What we need:
                a new main_listing method statement rows, if true indicates
                paging is desired with the specified number of rows per page.
                then the do_main would admit a page number arg (defaulting
                to 1) and would page with prev and next links.
                We might also allow a paged => conf_var_name, with the number
                of rows taken from conf.

    We need a way for a controller to opt out of the default run tests.

    Incorporate schema support into bigtop.
    x   1. a new schema block:
            schema schname {}
    x   2. allow table names to include a schema name:
            table schname.tblname { ... }
    x   3. SQL backends generate create shema statement.
            Only Postgres does this since both mysql and sqlite don't separate
            the notion of schema from the notion of database.
    x   4. Refers to statement allows schname.table as a value, and converts
        the dot to _.  Or user puts the _ in manually.
        Note that default processes will not make schemas, so no controller
        naming problems need to be addressed.
    x   5. Generatred cdbi code understands schemas.
    x   6. Make -a and -n understand table names with dots.
        Make them generate a schema block.

    Paul said a zero in an ident varchar got canned and did not make it to the
    database.
        This was overly aggressive clean_params in Gantry::Utils::CRUDHelp.

    Since Init Std now thinks of most of its files as stubs, we should stop
    putting no_gen 1; in its backend block under bigtop -n.

    There are occasional javascript errors.  I think these happen when an
    update could have caused a cascade, but did not.  Usually these are
    todo has no props.
        follow_instrustions no longer throws an error when the instruction
        string is blank

    Stop generating use_clean_dates since clean params is already on by
    default.

    There should be a way to stop the tentmaker server from the browser.

    Be more sensible about which files Init Std overwrites.
        README
        Changes
        Build.PL
        MANIFEST.SKIP
    should be stubs.  Only MANIFEST should be updated by default.

    The README should list the Control backend (like Gantry) in DEPENDENCIES.

    The note that bigtop makes in Changes:
        - original version created with bigtop
    could give the flags used

    The following -n worked with bigtop but not with tentmaker (these
    should really be merged, with get_big_default going away):
    -n 'type<-event question->event auth_to_rr answer->question answer->event'
        I tried this again, but it worked both ways.

    tentmaker does not support the new html form type 'display' for
    value which are not in input boxes.  It also knows nothing about
    html_form_foreign statement which allows 'display' fields to convert the
    foreign keys to foreign_display text.

    The Model and SQL backends now understand no primary key and multi-column
    primary key.

    It appears that if one table has two foreign keys in a single ascii art,
    their is a missing semi-colon or other syntax error.
        Actually, it was a foreign key target with an underscore, but only
        under -n with bigtop.

    ScriptHelp has a bug when you augment an app which already has a
    join_table.
    It causes a Pseudo-hash deprecation warning at line 184 and might have
    put the process into deep recursion or other CPU sucking behavior.

    Make the deparser a little kinder to data statements and others likely to
    wrap.

    tentmaker does not display a field keyword for html_form_default_value.
        It was not registered as a legal field keyword.  That has been fixed.

    Convert to new style Gantry::Conf.
        there is a new Conf Gantry backend, CGI Gantry and HttpdConf Gantry
        were modified to work and play well with it.

    bigtop --create should object loudly if the directory looks lived in.

    Make sure all AST packages are hidden from PAUSE indexer (including
    Parser, Deparser, and all the backends).
        I tried.  We'll see.  I think this failed before because the Deparser
        wasn't participating.  I was more careful this time around.
        It was finally notes/Postgres.pm, which is no more.

    Generate the fieldset legend key in CRUD and AutoCRUD forms.

    There should be a dirty flag in tentmaker, so it doesn't prompt on
    control-c if you just saved.

    Deparser does not handle all possible blocks.  It is missing:
        controller_config_block
        controller_config_statement
    and thus it cannot handle controller level config blocks.

    Apparently mysql does not like varchar, so we need to map that to something
    reasonable, like varchar(150).

    If there is an old sqlite, bigtop is trying to create the database with
    it and failing to note the errors.
        Fixed.

    The bigtop script in --new mode should provide details on how to get
    the app running.

    Tests should probably purge their play dir at the top and the bottom.

    Make sure the example presented in Bigtop::Docs::Tutorial is exactly
    billing.bigtop in the examples directory and that it builds as discussed.

    Revise the billing example so it uses sqlite and the stand alone server.

    Deleting blocks (at least fields) should trigger a page refresh so the
    quick edit box and Edit Field pull down can be brought up to date.

    Why do unnamed autocrud forms have names in their return hashes?
        They don't any more, but I didn't look at the template.

    In recent tests, when an autocrud form doesn't validate, the entered
    values are lost.  During add the input fields are blanked, during
    edit they are refreshed from the database.
        This was a problem with Gantry's form.tt.

    I want to consolidate the field boxes perhaps into a pull down list
    of field names and a single expansion window which always shows exactly
    one in detail, or which itself folds out of the way.

    When bigtop is in new or create mode it should summarily die if the
    build directory already exists (or at least if anything is in it).

    crtl-c trap in tentmaker is not prompting, it always saves.
    This is odd because running the one in the scripts subdirectory of the
    build directory works as expected.
    Actually, killing the tentmaker before making changes does wait for input.
    After a refresh change, it no longer waits.  Something is messing with
    standard in, which shouldn't be surprising since that is the post method.
        Started using the profoundly more robust approach of IO::Prompt.

    Generated date popup code doesn't yet pop up the date.
        This was because gen code was not getting the use statement for the
        calendar plugin.  When it did get it, it brought it into the
        wrong namespace.  To fix this I finally made stubs inherit from their
        gens.  That solves other problems as well.  If you want to implement
        your own do_main, you can now simply do so without redefining.

    When a field is changed to a date type (in is or by
    adding date select text to it) verify and set:
        is a date
        html_form_type is text
        date_select_text is 'Select Date'
        module uses Gantry::Utils::Calendar
        form has a name (name it for the table if needed)
        form has extra keys javascript...

    When you change a field to date in tentmaker, the javascript extra_keys
    entry is made correctly by the backend (as you can see by immediately
    viewing the bigtop source dump).  But, the html input field for the
    value stops at the first single quote around the form name.
        I switched input_boxes.ttc to use double qoutes around values,
        allowing them to have embedded single quotes.  If you need to
        embed double qoutes, you must use qq.

    Figure out the literals allowed in Bigtop::Conf::General.  Document
    and test them.

    When tentmaker reloads a page, the current tab is not necessarily selected.

    It would be nice if you could space separate field names in the create box.

    Add an 'Update' do nothing button to the field quick edit box.

    Perhaps the fields in a table should be shown in a little html table where
    you could change the most common things: name, SQL type, optional, label,
    constraint.  Then there could be a checkbox in the optional label which
    would set or clear all the others.

    When a date changes in tentmaker, lots of good things are happening.  But
    there is no page reload, so we can't see them.

    Gantry is not a bigtop prereq.

    Trap control c in tentmaker and offer the chance to save.

    When a table name changes, also change:
        x all refers_to statements
        x all controls table statements (but not for controller names)
            Done, but should we also change the field name (and cascade
            that change) of refers_to fields when the name of the field
            is the name of the foreign table?

    Could there be command line methods for change column names which would
    change them everywhere they appear, including the places below?
        x the name itself
        x the foreign_display if the original name was there
        x the cols list in main listing methods of any controller for the table
        x the fields or all_fields_but list for the table's controller(s)
        x the label if the old label eq ucfirst old name
    tentmaker now does this.  Do we still want a command line way?
        I don't think we need a command line approach as the api would complex:
            bigtop -c file.bigtop 'table1:field_name->new_field_name'
        I couldn't think of anything better.

    Add tests for ScriptHelp.
        More would always be nice, but there are some now.

    If a column name has underscores, form the field label by splitting
    the name into pieces on underscore and capitalizing each piece possibly
    excepting: a, an, the, of, on, etc.  Same for controller names from
    table names, except pack the result back together instead of space
    separating it.
        Mostly done, but not the article/preposition handling.

    If table name has underscores, treat it like a column name with
    underscores.  In other words, form its controller name by capitalizing
    the words and removing the underscores.

    Produce a useful testing script: t/10_run.t which tries to hit each page.
    Make a temp database from the sqlite schema for it to use.

    Generate pod in GEN controllers.

    When the column name changes, the tree updates are working, but the
    tentmaker screen is not be updated.
        Done.  Now not only does the screen update, but the expansions and
        scrolled position are retained.

    When a table is created from the command line, with bigtop, it gets
    a default foreign_display of %ident.  This needs to happen for
    tentmaker start up and when the user pressed Create for a table.

    Fix the screen shots in TentTut.

    Finish the TentRef.

    Find a good syntax for database independent type for datetime.  Tell the
    SQL backends about it.  Then use it in Bigtop::ScriptHelp and in the
    Bigtop::TentMaker for the created and modified fields.
        Is it just datetime which they all understand?  Try it for all three.
        Yes, they all understand that, but their notions of now are
        subtly different.  In Postgres you can just use the string 'now'
        as the value, in the others you have to call a function passing
        it now as a value.  That rules out automatic management.

    If there is an old sqlite, bigtop is trying to create the database with
    it and failing to note the errors.
        Perhaps we should abandon the fantasy of auto-generation of databases.
        I didn't give, up.  I just tried harder to collect errors and
        added a straight up version 3 requirement.

    When you make a field in tentmaker, it should default to:
        is varchar
        label ucfirst name
        html_form_type text

    Add pod to backends.

    During Bigtop::ScriptHelp default building, always make a foreign_display
    with value `%ident`.

    Split Model.pm and App.pm into stub and generated bits.  The Model.pm
    needs to have its table names updated on every Model build.  The base
    module needs new site_links whenever controllers are added.

    Put template statements in the docs for all backends which understand it.

    Make sure all examples are up to date.

    Make tentmakers tabbed pane region taller?

    Move the chatter boxes in tentmaker.  The user activated box should
    go under the save as button (not inside the current bigtop section).
    The debug chatter should go outside the tab panes.

    Add something in the tenttut about the app.server command line flags.

    Add a title above the tabs in tentmaker.

    When Bigtop::ScriptHelp makes a foreign key from ascii art, it doesn't give
    it a label.

    Add pod to generated app.server.

    Bring the vim syntax file up to date.

    When app level blocks don't have names, the error message is odd.

    The DBIx::Class GEN modules don't use __PACKAGE__ for has_a.  Could they?
        the method is called belongs_to and yes, they now do.

    The bigtop script needs a --add flag.  You must use it from a build
    directory.  It modifies docs/*.bigtop by insertion of new tables and
    controllers.  Suppose you started with:
        bigtop --new Hiring 'pos->job job<->skill'
    From the Hiring directory you can now add additional table/controller/etc
    blocks like this:
        bigtop --add doc/file.bigtop 'app->pos resume<->app'
    This happened for the tentmaker too.

    Make join_table available in tentmaker.

    Teach deparser to understand join_table blocks.

    join_table blocks should be regularized so they can have multiple
    statements, but we should check to make sure only one joins statement
    is allowed (not that other blocks do that -- but then they don't walk
    for statements).  In particular I want a names statement for the
    join_table:
        join_table fox_sock {
            joins fox   => sock;
            names foxes => socks;
        }
        The names would default to table . s (as in foxs).

    Multiple joins statements in join_table blocks produces a bad
    error message.

    Error messages don't report the possibilty of join_table (they say
    I was expecting..., but don't mention join_table as a valid block).

    The bigtop script in --new mode should allow ascii art table relationships:
        bigtop -n Contact 'family<-bday'
        or
        bigtop -n Contact family bday 'bday->family'
        different model:
        bigtop -n Store 'tshirt<->color'

    There should be a new app level block of sql type called join_table,
    joining_table or something similar.  It should have one statement:
        joins tshirt => color;
    The order of the tables wouldn't matter.  This would give the standard
    three table setup:
        +--------+                  +-------+
        | tshirt |                  | color |
        +--------+                  +-------+
                \                /
                +--------------+
                | tshirt_color |
                +--------------+
    Where the tshirt and color tables would have to be defined by regular
    table blocks.  When any table block is processing, it would have to look
    for any joining_tables.  If it saw its own name in one, it would have to
    make a has_many.
        The join_table block has been added.  And bigtop support the above:
            bigtop -n ShirtStore 'tshirt<->color'

    Descide what to do about sequences.  Perhaps we should just stop
    using them everywhere.  I think Gantry can get along without them
    if they are never generated.  The postgres backend needs to distinguish
    between auto when a sequence is defined and when it is not.
        Just make sure this works as expected.

    The bigtop script in --new mode should provide details on how to get
    the app running something like this:
        I just made a subdirectory called App-Name for App::Name.
        Change to that directory now.

        Then create your database using the generated schema.  I know about
        SQLite, Postgres and MySQL.  Here's how to build your database with
        each one:

        SQLite:
        sqlite appname < docs/schema.sqlite

        Postgres (supply passwords as needed):
        createdb appname -U postgre
        psql appname -U regular_user < docs/schema.postgres

        MySQL:
        ...

        Note that postgres needs passwords which are not in place...
    Bigtop abandoned default sequences.

    The app.server script should allow a command line flag --dbd=Pg along
    with --dbuser --dbpass, it would just use these in conf if they are passed
    or continue with dbd=SQLite and no user or pass if not.

    Make sure the generated schema.mysql works.

    The Postgres SQL backend needs to sense whether a sequence is given for
    an auto primary_key.  I think it currently dies if not.  It needs to change,
    so it instead changes the field type to serial (even if it is int).
    In other words, int4 and auto will now be incompatible when there is no
    sequence defined.
        Actually, if int4 is used with a sequenceless auto, it is discarded
        silently by the postgres sql backend.

    When the app has default location, the controller has rel_location, and
    a page_link_label is used, the resulting link has a doubled slash which
    interferes with relative dispatching.

    Add site links to do_main.

    Add Available urls loop to generated app.server.

    Correct build_backend_list in TentMaker module, so it isn't unix specific.

    Always name the database app.db.

    Drop blib from the app.server use lib statement.

    CRUD generation is making stubs that work only with CDBI.  They should
    just put comments in place for the user to fill in.

    Make these proposed changes happen.
    - Added more default behavior to tentmaker: making a sequence also
    makes a table and a controller, making a table also makes a controller,
    new tables have created and modified fields in them, new controllers
    have are AutoCRUD with form and do_main methods.
      - when you auto create a table because a sequence was created,
        make sure that the sequence statement for that table has the
        name of the sequence.
            done
      - when you auto create a table, add created and modified date fields
        to it (no html_types)
      - when you auto create a controller from table or sequence creation,
        make:
            a controls_table statement x
            a rel_location statement
            a page_link_label statement
            a do_main
            an AutoCRUD form
    Make the stub base model have a do_main with links to the other pages
    (if it is just site nav) do anything to keep the top page from returning
    an error.

    The author name and email should be deterimined as h2xs does.

    Began taking advantage of Gantry's new Gantry::Init which tells Gantry
    backends (and Gantry apps) where to look for templates.
    Three things are changed in the tentmaker default:
        1. root conf param is gone
        2. SiteLook GantryDefault no longer has a gen_wrapper path
        3. CGI Gantry backend has gen_root (which should also be in
           HttpdConf Gantry and Config General)

    Generated foreign_display routines should provide '' defaults for false
    return values to eliminate undef warnings.

    When a bigtop file is initially loaded by tentmaker, literal strings
    are not filling in their input boxes.

    When tentmaker makes a new literal block it has type None.  It should
    either be a good type or show in the box that a selection is needed,
    instead of looking like it is already of type Location.

    Generate some stub pod for models so pod tests don't complain.
    Remember to include method lists and to document both stub and GEN.

    You should be able to specify the model base class as a keyword in
    the model backend instead of (or in addition to) at the table level.
        Now the backend itself has a default which can be overridden by
        including the model_base_class keyword in that backends block.
        Then tabel level model_base_class statements override either the
        backend default or the one from the block.

    Change docs to reflect the move of all backends to the Backend namespace.

    When there are multiple authors, there should be multiple email addresses.
    These should be generated correctly on separate lines with line breaks
    so Module::Build does not become confused.
        Probably the email should just be a value for the name key:
            authors `Phil Crow` => `crow.phil@gmail.com`,
                    `Tim Keefer` => `tkeefer@gmail.com`;
        Then the email link would be added below the authors list and could
        be a block of text inviting mailing list subscriptions or a simple
        url or mailing list address.
            This really needs its own section.
                which it got with the new contact_us keyword and the
                corresponding CONTACT US pod section in the root module.

    Fully document Bigtop::Keywords syntax (let the keywords speak for
    themselves).

    If you list multiple compatible backends, they should all do their things.

    Implement DBIx::Class support.

    Tests need to be skipped if modules the generators target are absent.
    In particular, if there is no gantry, the t/gantry and t/ganmodel tests
    should just be skipped.
        Actually, the only ones that were problems were the gantry control
        gen tests because they produce full import lists for
        Gantry::Plugins::AutoCRUD when it is installed and empty lists when
        it isn't.
        Those tests are now skipped.

    Add meaningful response to bigtop --help

    Build.PL needs to test for the presence of Gantry before dealing with
    the tentmaker.

    Figure out how to install tentmaker so it can find its templates and
    javascript.

    Allow port to be specified from command line in stand alone server.

    Make CGI Gantry work with Gantry::Conf.

    Add an app level uses statement which will add use statements to the base
    module.

    Improve the generated Build.PL so it installs templates, etc.
        improviing as Tim uses it, but still needs testing

    When a config statement has an extra semi-colon the config block is
    rejected with an indirect error message:
    config {
        #...
        root `/long/path/to/apps/html/directory:/with/path/to/gantry/root`;
                no_accessor;
    }
    Yields:
        Error: invalid keyword 'config' (line 18) near:
         {
        I was expecting one of these: ..., or a valid block (... config, ...)
    The emphasis here belongs on the work 'valid' the config block is not.
        This now reports as bad config statement, possible extra semicolon...

    When generating stubs, skip (or comment out) the init sub if their are
    no parameters to fish for.

    Make a backend which understands config blocks and makes Gantry::Conf
    files.  Add not_for to config blocks to control which backends see
    the config (so I can say not_for HttpdConf to avoid set_vars).
        Using not_for is a bad idea, since it looks just like another
        set var statement.  Instead, any conf backend can have a statement
        in its block in the bigtop config section with skip_configs or
        skip_set_vars or whatever makes sense for it.

    We need control over where the engine and template engine config statements
    go.  They might be better as app level statements.  Backends that could
    care about them should declare their intentions in their config blocks.
        There is a new config_instance statement in the config section of
        Bigtop files.  There are full_use statements for the Gantry control
        and httpd conf backends.

    Add field level keyword which allows for control of Data::FormValidator.
    And/or allow for some other validation procedure.
        the word is html_form_constraint

    Change set_vars to config everywhere (with set_vars as a synonym as
    appropriate).

    docs:
        developer docs for those who want to write their own generators
            requires quite a bit of effort, must explain the basics of:
                the grammar
                the lookup hash
                the package mixin scheme
            remember to mention setup_template and Inline::TT

    Misspelled literals do not result in quality error messages, they are
    just ignored.
        literal types became regular keywords which backends must register

    Misspelled block names result in strange errors about expected
    simple statements.
        The list of expected items now include ..., or a valid
        block (controller, sequence, set_vars, or table).

    Allow for use statements with explicit exports in controllers.

    We need more literals:
    1. Perl block in httpd.conf (immediately after the #! line or at the end)
        literal PerlTop
        literal PerlBlock
            Done.  This was really a minor rearrangement, since PerlBlock was
            already there.
    2. Full apache access between controller locations.
        literal HttpdConf
    3. use libs and other preamble statements in cgi scripts.
        Done.  I just made the CGI backend for Gantry honor PerlTop literals.

    Allow for mulitple data sources (more than one database connection).
        Connections are actually controlled by the modeler.  To make
        an extra connection one needs to create a subclass of
        Gantry::Utils::Model or Class::DBI for it.  Then you can simply put
        a model_base_class statement in the bigtop for that table.

    Add use_clean_dates to the generated crud constructor call for controllers
    of type CRUD.

    Frank suggested moving from mixin to inheritance for the GEN modules.
    I agree.  Then you can override GEN methods at will without sub redefine
    warnings.  We need some docs explaining where to look for an explanation
    of the scheme and a diagram of the inheritance tree.
        This will not work smoothly with Class::DBI since the methods it
        generates are bound invocant package.
        Implemented for hand rolled models.

    Tim wants more help with non-auto CRUD.
        created controller types: stub (like now), AutoCRUD (just puts in
        a uses Gantry::Plugins::AutoCRUD statement for you), and CRUD
        (generates a single crud object and all the methods it uses, you
        still have to define the form, but it senses the name).

    Have bigtop remove _Inline directories on completion.

    make a backend which outputs hand rolled data model modules

    retrieve_all_for_main_listing could be a little more helpful if
    it took an option hash (or hash ref, one or the other not both).
    If that list was supplied, it would use search instead of retrieve.

    We need more control over how the models get generated.  For example,
    we need to be able to define an auth_groups table and have a controller
    for it, but locate the table in a different database and access it with
    a different dbh.  Currently, all tables are thought to live in one
    database and all models use the same base class and therefore share
    a dbh.
        This is probably as simple as combining a new keyword with
        not_for SQL in the table.  The new keyword could be used like so:
            model_base_class Gantry::Utils::AuthCDBI
        whose default value is chosen by the Model backend (e.g.
        Model GantryCDBI uses default Gantry::Utils::CDBI while
        Model Gantry use default Gantry::Utils::Model)

    When set_vars are marked no_accessor, they should also be left out of the
    init method.  The presumption is that Gantry.pm is handling them.

    in main_listing, include a column_labels option that allows both
    Label, Label
        and
    Label => link, Label => link, unlinked_label, Label => link
    ( This is to support Tasks.pm style from Billing sample app. )
        Low.

    Make a way for there to be controller level set_vars.  These would
    be processed by the controller backends, and would land in the
    controller's location block in the httpd.conf.
    You should also be able to feed arbitrary data into the location block
    and to the top level Perl block.  But, set vars need accessors somewhere.
    Make sure that location level init methods are only generated if there
    is something for them to do (the same might go for app level, but
    do nothing inits seem less likely, at least for us).

    Rename url keyword to location and rename location at the controller
    level to rel_location.  Implement absolute location at controller level.

    Generate the CGI dispatching script which replaces httpd.conf for
    cgi environments.

    Allow direct statements to feed into Perl block and Location blocks
    of httpd.conf.  (This allows for loading of common modules on startup
    and directives like require valid-user.  Thus, removing much potential
    magic.)
        Medium.

    Allow sql statements like index creation.

    Fix the granularity of no_gen so all app level block have one
    and the backends pay attention to it.
    Deal with regeneration with non-overwrite protection.
        We need better granularity.  We need to separate the models
        into two pieces like the controllers.
            Done
            no_gen now works for these levels:
              . the whole app nothing is gened, no backends are even called.
              . backend type, marked in config block for the backend
                the gen_* for that backend is not called
              . controller, nothing is gened for the controller (neither
                stub nor GEN module)
              . individual files made by Init
              . models (requires table keyword not_for)
              . individual controller methods (so they don't go in the GEN
                module and result in a redefinition warning)
            no_gen needs to work for these:
            not_for needs to work for:
              . SQL backend (maybe, low priority)
            Further, Init backends should only be called in --create mode.
                Done if you use --new to make the app initially

    When Init::Std is run on docs/name.bigtop it complains that the
    that file and its destination are identical.  It should keep quiet.
    Actually, it shouldn't overwrite that file.
    In fact, Init modules should never work outside of --create mode.
        The final answer: Use bigtop --new App::Name.  It generates
        the stub of your .bigtop file with Init marked no_gen.

    We still need a way to generate a working location from thin air:
        bigtop --new App::Name
    builds App-Name under the current dir, makes a bigtop file in docs:
        config {
            Init Std {}
        }
        app App::Name {
        }
    and does build all there.

    Change the name of the generation script to bigtop everywhere.

    Add a config param for the license which will go into the readme
    and into the Build.PL file.
        Low. h2xs never did this

    The name statement in AutoCRUD_form method blocks should be called
    form_name.

    Controllers with names like Name::Subname, the stub is correctly
    generated, but the GEN file is not (presumably because the proper
    GEN subdir is not made).

    Controllers must have a body at present.  It should make a stub
    for any controller, even if there is nothing in it.

    Though not normally needed, some apps need to have the model disagree
    with the database.  Our auth_users table needs an id column to make
    the auth modules happy, but the internal model for the table should not
    include it, since that confuses CDBI (it thinks all primary key columns
    should be called id).  So, a new statement for fields should be:
        not_for Model;

    Allow abbreviated flags for bigtop:
    GetOptions(
        'new|n=s'       => \$grace_template,
        'create|c'      => \$help
    );

    The docs for extra_args in B::Control::Gantry are made false by the
    code.  Make the code match the docs.

    The base_dir scheme is not good for general use.  It should work like
    this:
        The script should be called bigtop.
        Running bigtop file.bigtop all builds all files relative to current
        directory, so users are responsible for making the build home.
        Running bigtop --create=/path will make the path, then build.
        If the current directory doesn't smell right, a warning is issued:
            Bigtop is not built here yet, are you sure you want it to? [N/y]
        Almost.  --create expects base_dir and app_dir to be defined in config
        otherwise base_dir defaults to '.' and app_dir defaults to the h2xs
        subdir name based on the app name.

    Bigtop::Control:: modules should not make the GEN file if there are
    no methods to put there (if the export list is empty, don't make the
    file).  And, the stub should not use the module that was not GENed.

    Warnings are chattering.  There should be a way to make it quiet.
    There should also be a way to make it say what all it is building
    or even what it would build (like make -n).

    A vim syntax color file would be nice.

    MANIFEST.SKIP does not skip vim litter files start with . and
    end with .swp.

    Allow an app level keyword license_text.  If it's there, use it
    instead of the Perl boilerplate which is the default.

    Gen better doc stubs.
    Namely, the pod should list all generated methods.
    Make a SEE ALSO that lists all the modules that are used.

    SiteLook should not call a fatal error if a controller has no
    page_link_label, it should just leave it out.

    When there are no controllers, but you ask for SiteLook GantryDefault,
    it has no links to insert into the wrapper and warns as a result.
    It should avoid the sub if it has nothing to insert.

    When a method block is empty (which is not really an error for a stub)
    it should either work or note the real cause of the problem not:
    Error: invalid keyword 'controller' (line 355) near:
        I just made empty blocks legal.  They make sense for stubs.

    In Init::Std, look for file no_gen statements.

    Tease apart the generated bits of the models from a stub file where
    users can put their code.

    docs:
        end user tutorial: building a sample app with bigtop
            first draft done
        detailed user syntax for bigtop files
            done, pending normal edits
    Allow h2xs relatives to be controlled by templates.
        This is mostly available now, at least as available as for other
        modules.  What remains is to provide a way for the user
        to specify their template file names and pass those to the
        proper setup_template methods.

    Figure out a way to hide the perldoc in Control::Gantry's 
    module template.  It's coming out with the perldoc for the module.
        Perhaps that module's pod should just come first with a note to
        ignore the template pod that follows.

    Allow templates to be specified in config backend blocks.  Like this:
    Control Gantry { template `/home/user/file.tt`; }

    Add data to the following to the comment in the controller template:
        DESCRIPTION
        AUTHOR

    Remove unix specificity from find_all_files_in in Init::Std.
        This sub was replaced by ExtUtils::mkmanifest.

    Add keywords for where templates live (their directory, their file
    glob, etc.).
        Actually, this is handled via a PerlSetVar in httpd.conf.

    Include a doc stub at the bottom of the main module.
        This is actually more important than it might seem.  Failure to
        include an AUTHOR section in the pod causes Module::Build to
        die.

    Make a tutorial that walks through building an app.  Make sure
    that app runs.

    Use the authors, email, and copyright_holder values in the README.
        It turns out that READMEs usually only have copyright year and
        holder.  So copyright_holder goes into README or first name
        in authors as a default (or blank if neither is given).

    When an arg_element should be quoted we usually get a missing semi-colon
    error.
    This may be fixed, because the last time it happened to me I got the
    far more useful:
        Error: I was expecting an argument or argument list on line n near:
            '$id';

    Figure out what is up with undef dates and make a better solution.
        This was fixed with a new function in Gantry's AutoCRUD.pm

    Correct information about escaping quotes.  You need two in the tests
    because you are interpolating.  Users don't because they aren't.

    Make 'require valid-user' in root location controllable.
        I just decided to leave all auth out of the bigtop for now.

    Allow templates to be specified in the config section.

    Document the syntax of the bigtop files fully.

    Document the various Bigtop modules.

    Make the copyright year on generated modules the year of generation.

    Complete the pod for in Control::Gantry's template.

    Move the keyword registration begin blocks to sharable modules.  For
    example, move the begin block at the top of Bigtop::SQL::Postgres
    to a new module is uses as a base called Bigtop::SQL.  Do the same for
    other categories.  This would create a central place to define a
    defacto api.  But, it would also mean that users might have to look
    in multiple places to find the available keywords.

    Add an error message when anything but space comes between a registered
    keyword and its value:
        foreign_display => `%descr`;
    results in rejected table, making table an invalid app keyword.

    Rename Bigtop::Model::CDBI to Bigtop::Model::GantryCDBI.

    Second and following use statements in httpd.conf are indented one
    extra space.

    Add a blank line between Location directives in httpd.conf.

    Allow a data section in the table block (possibly a block) so users
    can populate type names from the bigtop file.
    Make data table keyword functional.  It is a repeatable statement
    with data to put into the table.

    Stop generating Model.pm use Gantry::Utils::Model in the models.

    make controllers generate test stubs
        There is a compile only test, but no individual tests.

    Have gen_Init copy the bigtop source file into the build dir.

    Correct the is handler, is main_listing, ... so they don't take $r.

    When Data::FormValidator doesn't like something, all data is lost.
    This could be an error with Gantry or its autocrud.
        This was an error with communication between Gantry, its autocrud,
        and class dbi.

    Add -- Select -- to foreign key selection in Model.pm.

    Add method heads to class accessors in controller stubs.

    Remove all gen_all methods, they are no longer called.

    Default edit and delete links did not have ids on them.

    Generated Location urls could have duplicate slashes if the user
    types some.

    Correct the spacing when a uses entry has includes (use some
    standard module that has exports for the test).

    Add an error message when type in: method name is type {}
    is not one of the known types.

    all_fields_but is not working when the table has a defined sequence

    in AutoCRUD_form allow an exclude_fields which takes everthing but
    the ones named.
        Done, but the name is all_fields_but.

    automate MANIFEST updates in some nice way at the beginning of a project
    so the steps are simpler than:
        wadlgen --gen=Init
        cd $build_dir
        wadlgen --gen=all
        perl Build.PL
        ./Build
        ./Build manifest
        ./Build realclean
        perl Build.PL
        code away
    This should probably be done by directly using
        ExtUtils::Manifest::mkmanifest()
    as the last step in --gen=all or when the user says --update_manifest
    Then the above steps reduce to:
        wadlgen --gen=all --update_manifest
        cd $build_dir
        code away
    See ACTION_manifest in Module::Build::Base for how to do this.

    Allow an app level url which sets the root for all the other urls.

    Make a way for there to be engine level set_vars.  These would not
    be processed by the controller backends, but would land in the root
    location block in the httpd.conf.
        app level set_vars can now be marked => no_accessor.

    Add set var control to the grammar.  This should be at the app
    and/or controller level at the user's option.

    Generate init in the base module which fishes out all the set vars.
    This is part of a general effort to handle set vars.

    make a backend which outputs data model modules for Class::DBI
        But Frank might come forward with this piece

    Make the grammar report better errors.  Example when it doesn't see
    a semi-colon at the end of a simple statement, that should fail close to
    the error not at the block level.
        This particular example seems to be solved, but there are likely
        others.

    Correct Model.pm so that its get_select_lists produces output
    the template will actually take.

    Change the test that uses Gantry::Plugins::AutoCRUD to use something
    that is not installed, so we don't get one result on systems that
    have it and another on systems that don't.

    clean up after Init::Std test (think purge dir)

    Add generation of text_descr and get_model_name to controllers.

    Change the name everywhere.

    Add check during controller generation so stubs don't get overwritten.
        Each backend is reponsible for keeping track of what is a stub
        and what is a generated piece.  Stubs should not be overwritten
        if present on the disk (but maybe there should be a force option).
        Gen pieces are always overwritten unless the backend has a true
        no_gen flag in its config section.

    make command line tool
        Include a way to add keywords to the grammar in case only some
        of the back end modules will be loaded.
            NO.  All back modules are always loaded, but not all have their
            gen_* method called.

    Make it possible to mark gen modules as no_gen in the config section.
    This is needed so their keywords are still registered, but the user
    controls whether what they gen could ever be overwritten.
    Maybe config items should be like app section items.  That is, they
    could be simple statements or named blocks.  But, the block names
    could be any valid backend.
        I decided on that later with one minor exception, all simple
        statements take a single item, not a list.

    make the files that h2xs makes:
        A directory based app name Module::Name -> ./Module-Name
        check Changes
        check Build.PL
        check MANIFEST
        check MANIFEST.SKIP
        check README
        check t/
        check lib/

    split controller generation in W::C::Gantry so generated bits are
    separate from the user editable stub.

    make a backend which outputs controller modules

    Make the cols option in main_listing methods accept things like
    company_id.name.
        Done, but I opted for noticing that the field refers_to another
        table, then generated $row->col_name->foreign_display()
        allowing the model for the foreign key's table to care for
        what displays there.

    Make it possible to use values which are not simple ints or valid idents.
        Anything in backquotes is taken literally.

	make the grammar check keywords

    make it possible to change legal keywords in grammar

    do for controller_keyword what you did for field_keyword

    Convert walk_postorder to collect objects instead of strings.  The
    gen methods will stringify the result as needed.

    Convert method_keyword, controller_keyword, etc to keyword('type') in
    the grammar.

    Move to a two D hash for keyword validation.

    Add method type keywords to the keyword validation.

Issues that needed resolving (with resolutions):
    Allow refers_to to take table.column instead of assuming column is id.
        This doesn't really apply.  Gantry assumes all tables have unique id
        as the single primary key.  Class::DBI doesn't care so long as the
        has_a value points to a table with a defined primary key.  The key name
        doesn't matter.
        Other backends can add a different field keyword like foreign_key
        to handle the situation.

    What should the name be.  Candidates:
        WAFL   - Web App Framework Language (or W. Australia Football League)

        bigtop - one place where almost all the action is
                 think perl-bigtop.org or maybe even bigtop.perl.org.
            THIS IS THE ONE.

        GCS    - Grand Central Station where all the Perl apps on rails
                 gather for departure

        PSC    - Perl Space Center

    Question: How does AutoCRUD_form name differ from controls_table's value.
        controls_table's value is the name of the controlled table.
        AutoCRUD_form's name is the name of the form for javascript purposes.
        While it might be nice to provide the table name as a default,
        I don't see any compelling reason to do so.

    Question: Should methods list the fields they want to see, or should
    the fields say which methods should host them.
        A. All field data should be in the field block of the table.
           This makes a central place to look for all things relating to
           the field.
        B. Methods are the natural place to look for why a method's output
           is wrong.  Field blocks are a less natural starting point.
    Conclusion:
        Methods should list the fields they want.  The field should not
        know who is looking at it, only how it should look in different
        circumstances.  There could be two different forms for a table
        (say one for CSR and one for Admin).  One form could have fewer
        fields.  You shouldn't need to change the field block because the
        second form was created and you sure shouldn't have to register
        a new keyword for the new form.

    Problem: Single quotes need to be escaped in some cases.  In particular,
    if the wadl file backquoted string will be single quoted, any single
    quotes in it must be escaped.  Likewise for double quotes bound for double
    quoting.  Options:
        Blindly escape quotes embedded in text strings in the grammar's
        token action
            This is almost sure to lead to visible backslashes in the output.
        Do it for the user in the template with filters
            This seems best, after all the template is where the final
            double or single quotes appear.  But it would require installing
            non-standard template plugins.  Further, the templates generally
            appear in the code files or are supplied by casual developers.
        Do it in the code generators
            This is tedious, but provides control in a reasonable place
            and requires effort on the part of deep developers.
        Loudly tell user to do it
            This provides the most control and these things lead to compile
            errors in the generated code.  That's easy to see, but will
            annoy new comers.
    Conclusion:
        Users are the most reliable on knowing when quotes appear and
        will easily notice when they are wrong.  They should not have to
        fight internal magic (too hard) to influence the quotes.

What I had to do to get from
    bigtop bailey.bigtop all
to a working app:

    Created the doc root dir where the templates will live (at
    least during development).  Created the app's TT wrapper.
        I should be generating a basic wrapper and index page with
        the site nav options.

Rebuilt and tried the result:

    Correct the is handler, is main_listing, ... so they don't take $r.

Third attempt:
    A charm (though there may have been a couple of little tries in the
    middle).

Second attempt:
    All the Location urls, except the root, have leading double slashes.
        This was previously noted and is now fixed.

    All of my javascript keys have the same table name it they are all wrong.
        This was user error in the bigtop file.

    app_navigation is still being generated despite it relocation to the
    wrapper.
        Fixed.

Resolved in Bailey rebuild:

    Create a sub directory docs where schema.sql and httpd.conf live.
        DONE.

    Copy the generated files from ~/Apps-Bailey to ~/src/Apps/Bailey.
        This is normal.  bigtop does what h2xs does.  You need to
        move them into the proper checked out svn repo in order to check
        them in.
        But, it might be nice to allow a config parameter that would
        control this.
        I remember now that app_dir already controls this.

    Add use Apps::Bailey to httpd.conf.
        DONE.

    Remove use Gantry from httpd.conf or change it to:
        use Gantry qw{ -Engine=MP13 -TemplateEngine=TT };
    In addition, change Gantry so using it without an engine is a fatal error.
        DONE (except for the change to Gantry, see its todo).

    I made an error in bailey.bigtop.  I should have left out the main
    app url, since we want /.  I had to correct the conf.

    Added our @ISA = ( 'Gantry' ); to Bailey.pm.
    
    Adjusted layout of use statements in controllers.

    Changed the last line of Apps::Bailey init from base_model to
    get_model_name.

    Changed the base Model.pm to fish connection data using accessors
    instead of hash peeking.

    Implemented retrieve_all_for_main_listing in Model.pm.

    Added 1; at the bottom of the model .pm files.

    Added root (and many other Gantry level) set_var.  See Gantry->init
    for a list of the possible variables.
        This would only require changing the bigtop file

    Created wrapper template.

    Decided against having email/event in favor of emailevent (think
    Location directive misordering).  This was really a problem with
    the bigtop file.  If you want subordinate directories, you need
    to put them after their parents.

    Corrected location lookup in do_main to use accessor.

    Replaced _form which was somehow not generated.  This was due
    to the misspelling of AutoCRUD, not to a bug in Bigtop.

    Added _form to the export list of the GEN module and to the import
    list of the stub (this should be an artifact of not generating the
    _form methods via output_AutoCRUD).

    Added quotes around all items on the form which have digits in their
    names.

    Corrected Model->get_form_selections to reflect that
    get_foreign_display_fields returns an array ref.

    Corrected lookup of Apache request object (r) in site object to use
    an accessor in generated _form.

    Corrected lookup of location in options list in row loop of do_main
    for GEN/Customer.pm.

    Added 'require valid-user' in root location block.

    Added javascript => $self->calendar_month_js( 'customer' ),
    to _form's return value in GEN/Customer.pm.
        This is something the user needs to request in the bigtop file.
        They do this with the new (optional) extra_keys method body
        statement.
        The legend should probably be handled this way, to avoid
        magic and give the bigtop author more control.

    Added use Gantry::Plugins::Calendar to Customer.pm.  I think this should
    have been included in the bigtop file, so this is user error.

    Correct MANIFEST errors.  When I build it, nothing is ignored.
    I really should be using the standard approach generate MANIFEST.SKIP
    the use:
        ExtUtils::Manifest::mkmanifest()

