---

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

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 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.

CRUD generation is making text_description, get_orm_helper, and
get_model_name methods.

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.

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?

--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.

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

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

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

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.

---

Remaing 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 probabaly not in the spirit of tentmaker anyway, but some
docs might be nice, like [does NOT apply to base_controllers].

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:

    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."

    generate app_navigation with proper links in W::C::Gantry.
        App navigation has rightly moved to the app specific wrapper.
        While a generator for it might be nice, most of it is really
        the css and layout of the hosting site.

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

Bug fixes:

    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:

    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` => `philcrow2000@yahoo.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()

