Masterview devel - Jun 2006 - New init/config stuff ready to be submitted

Jeff - I''m pretty happy with the new init/config stuff now - did one
more
polishing pass over things to today to tinker a bit more with names and
rework a few things that still felt awkward.

doc/configuration.html has a complete (brief) reference for all the
supported config settings and a bit of intro material on how to customize
the config.

Also wrote some test cases to exercise basic default settings for rails and
non-rails usage and test loading of settings.rb and env settings from an app
config dir.  The test fixtures for config settings file provide example of
usage [need to add to the config guide doc]

Look this over one more time and let me know if you want any changes in
naming or approach.

Whenever you''re ready for the cutover, I''ll submit the other
changes that
need to go in to turn this on.  New versions of init.rb, masterview.rb, and
rails_init.rb; plus a few minor changes that rippled into other files.  This
update will include new generated comment facility with template_path var
substitution. 

Client impact: any existing settings customization will need to be moved out
of plugin init.rb into config settings files, with notation changes to
convert from module var refs to setting config values.  (pretty
straightforward).

I''ll add something to changes notes for the next release when this goes
in.

~ Deb

Deb,

I took a look through the changes. It is looking real good. A couple things
I think we should do before the release:

* create sample configuration file with the available options commented out,
so they can simply copy this file and uncomment anything they want to
change. No mispellings and hunting for options, they would all be there. Put
this in examples/config/masterview/settings.rb??

* update README file mentioning how to customize, recommending copying the
example config file to ___ location (making sure to spell out exactly what
filename path). Mention how to do environment specific customization, simply
by specifiying file ____, etc.

* update init.rb to mention where to go to configure options (what config
files) and where to get sample, similar to README. Existing users will be
going there so they will see this and many plugin users have been accustomed
to looking in there, so just want to make sure they know where to go to
customize.

* slight rewording of inializer.rb, from reading the comments it was a
little unclear. I suggest we just cut to the chase and mention customize by
editing file config/masterview/settings.rb and for environment
(development,test,production) settings edit file
config/masterview/environments/{environment}.rb (ie. development.rb, test.rb,
production.rb)

* update masterview_version

* update CHANGELOG if not already done

* test as a gem

I will send you a separate email with my current release steps, so if you
would like to do the release you are welcome to do so.

Jeff









On 6/6/06, Deb Lewis <djlewis at acm.org> wrote:
>
> Jeff - I''m pretty happy with the new init/config stuff now - did
one more
> polishing pass over things to today to tinker a bit more with names and
> rework a few things that still felt awkward.
>
> doc/configuration.html has a complete (brief) reference for all the
> supported config settings and a bit of intro material on how to customize
> the config.
>
> Also wrote some test cases to exercise basic default settings for rails
> and
> non-rails usage and test loading of settings.rb and env settings from an
> app
> config dir.  The test fixtures for config settings file provide example of
> usage [need to add to the config guide doc]
>
> Look this over one more time and let me know if you want any changes in
> naming or approach.
>
> Whenever you''re ready for the cutover, I''ll submit the
other changes that
> need to go in to turn this on.  New versions of init.rb, masterview.rb,
> and
> rails_init.rb; plus a few minor changes that rippled into other
> files.  This
> update will include new generated comment facility with template_path var
> substitution.
>
> Client impact: any existing settings customization will need to be moved
> out
> of plugin init.rb into config settings files, with notation changes to
> convert from module var refs to setting config values.  (pretty
> straightforward).
>
> I''ll add something to changes notes for the next release when this
goes
> in.
>
> ~ Deb
>
>
> _______________________________________________
> Masterview-devel mailing list
> Masterview-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/masterview-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-devel/attachments/20060607/76738ec4/attachment.htm

Jeff - good points, I''ll make another pass over comments, doc, provide
fullly commented-out sample of settings config files per your suggestions.
 
I''m stil finding and patching up places that have rails-specific
assumptions
bolted down about templates being located in app/views (there are several
scattered around the code that I''ve got fixed in my local working copy,
just
found yet another in tasks/masterview.rake last night that I''m still
patching)
 
Process note: committing to trunk != publishing release.  Believe we should
*not* do another public release build until useful set of new functionality
is completed, committed to trunk for development team use so we''ve both
looked it over, and confirmed stable after we''ve run with the new code
base
for a while.
 
[unless there''s some bug fix that you need to get out to users for some
reason]
 
~ Deb

  _____  

From: masterview-devel-bounces at rubyforge.org
[mailto:masterview-devel-bounces at rubyforge.org] On Behalf Of Jeff Barczewski
Sent: Wednesday, June 07, 2006 4:42 AM
To: masterview-devel at rubyforge.org
Subject: Re: [Masterview-devel] New init/config stuff ready to be submitted


Deb,

I took a look through the changes. It is looking real good. A couple things
I think we should do before the release:

* create sample configuration file with the available options commented out,
so they can simply copy this file and uncomment anything they want to
change. No mispellings and hunting for options, they would all be there. Put
this in examples/config/masterview/settings.rb?? 

* update README file mentioning how to customize, recommending copying the
example config file to ___ location (making sure to spell out exactly what
filename path). Mention how to do environment specific customization, simply
by specifiying file ____, etc. 

* update init.rb to mention where to go to configure options (what config
files) and where to get sample, similar to README. Existing users will be
going there so they will see this and many plugin users have been accustomed
to looking in there, so just want to make sure they know where to go to
customize. 

* slight rewording of inializer.rb, from reading the comments it was a
little unclear. I suggest we just cut to the chase and mention customize by
editing file config/masterview/settings.rb and for environment
(development,test,production) settings edit file
config/masterview/environments/{environment}.rb (ie. development.rb,
test.rb, production.rb)

* update masterview_version 

* update CHANGELOG if not already done

* test as a gem

I will send you a separate email with my current release steps, so if you
would like to do the release you are welcome to do so.

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-devel/attachments/20060607/505b8b38/attachment.htm

Agreed.


On 6/7/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  Jeff - good points, I''ll make another pass over comments, doc,
provide
> fullly commented-out sample of settings config files per your suggestions.
>
> I''m stil finding and patching up places that have rails-specific
> assumptions bolted down about templates being located in app/views (there
> are several scattered around the code that I''ve got fixed in my
local
> working copy, just found yet another in tasks/masterview.rake last night
> that I''m still patching)
>
> Process note: committing to trunk != publishing release.  Believe
> we should *not* do another public release build until useful set of new
> functionality is completed, committed to trunk for development team use so
> we''ve both looked it over, and confirmed stable after
we''ve run with the new
> code base for a while.
>
> [unless there''s some bug fix that you need to get out to users for
some
> reason]
>
> ~ Deb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-devel/attachments/20060607/acf6f1df/attachment.htm