From djlewis at acm.org  Fri Jun  2 11:22:50 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 2 Jun 2006 08:22:50 -0700
Subject: [Masterview-devel] DOS line feeds - can you use unix linefeeds
	in your editor for new files?
Message-ID: <20060602152252.DWAT5347.fed1rmmtao05.cox.net@DLI92cx797990>

Jeff - thx for spotting that, I was going to warn you to watch out and let
me know if there was a problem with the line endings coming in from my XP
box.  such a pain
 
I'll see what I can do with either my Eclipse IDE settings or SVN config so
that anything I commit into the repository has windows cr/lf's normalized to
*nix LF's.  (and in the meantime I'l check/clean manually)
 
Believe there are some SVN settings that can be used to automate platform
line endings when checking in and out, I'll go look for those when I get a
chance - best would be to have the repository itself set up in a way that
incoming files are normalized to desired state.
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Friday, June 02, 2006 4:46 AM
To: dlewis at glaivestone.com
Subject: DOS line feeds - can you use unix linefeeds in your editor for new
files?


Deb,

I noticed that new files that you created use DOS linefeeds (windows) like
masterview/initializer.rb. Would it be ok to switch your editor to default
to unix linefeeds? Otherwise when unix people open the files depending on
the editor they are using they see a bunch of carriage return chars which
looks pretty ugly. It's not that big a deal and we can always clean up
afterwards using sed but I thought I would ask. 

Existing files that you edit seem to retain whatever characteristics they
had unix vs DOS linefeeds, so it is mainly on new files.

Not a big deal if it causes you any problem.

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060602/8601b709/attachment.htm 

From djlewis at acm.org  Fri Jun  2 11:23:48 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 2 Jun 2006 08:23:48 -0700
Subject: [Masterview-devel] Masterview init rework - one more try
Message-ID: <20060602152350.DXFQ5347.fed1rmmtao05.cox.net@DLI92cx797990>

 > > didn't see your aaasample-config (did it get committed?) 
 
oops, nope.  it's out there now (with LF's)
 
Another possible tweak: not sure if I like the file name
config/masterview/init.rb - kind of implies more than what's intended.  This
file really shouldn't be doing much more than setting values in the config
instance it's given, it's not really intended as a general "write
initialization logic" - if you want to do additional app initialization to
leverage MV once it's installed, that probably does properly belong in your
environment.rb (where it's run when your own app has been initialized and
installed, which isn't the case at the point when the plugin init is being
run)
 
So maybe config/masterview/settings.rb or config/masterview/app_settings.rb
(?config/masterview/config.rb?!) would be a better name to express the
intended scope of what goes in this file.
 
philosophy rant: this might seem like nit-picking, but names *REALLY* do
matter.  Getting the names right early on makes a huge, huge difference in
the comprehensibility of the software, both for the developers and the
users.  Affects how you talk about and think about what's going on.  I find
up-front investment in fussing to get names and concepts right always has
huge payoff over the long-term lifetime of the system.  
 
If you're lazy or get it wrong, it'll hurt your brain every single time
forever after when you have to stop and think "lessee, X... oh yeah, that
means Y"
 
</rant>
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060602/ed0dfa32/attachment.htm 

From djlewis at acm.org  Fri Jun  2 11:31:19 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 2 Jun 2006 08:31:19 -0700
Subject: [Masterview-devel] I am thinking of creating a class to
	encapsulate file reads
Message-ID: <20060602153121.EXEU24290.fed1rmmtao09.cox.net@DLI92cx797990>

believe I like that approach - TemplateLoader or something like that.  I'll
wander around the code a bit more today and see how that "feels" when I've
gotten a bit more oriented to some of the pieces of what's going on.
 
When the new config/init mechanism is committed, we can also start pushing
some of the constants currently bolted onto the MasterView module itself
down into specific classes that they belong to when general scope isn't
appropriate, e.g., maybe proposed TemplateSrcRelativePath should actually
own the MasterView::TemplateSrcRelativePath constant (or whatever it wants
to call it) 

~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Friday, June 02, 2006 8:02 AM
To: dlewis at glaivestone.com
Subject: I am thinking of creating a class to encapsulate file reads


In thinking about your file read problem, I am thinking about consolidating
our file reading to a single class so we can insure that things are being
handled the same everywhere. Also it will make it easy to test since we can
have a hook so that instead of reading from a file it can go to a hash, and
when we start having the ability to store things in db, then it could read
from there. 

I have to flush out the idea a little but I think this would be a powerful
approch and will help us insure that no files are being left open since we
can test that function heavily. I may have to be able to tell it to read
from file system for these types of files and from db for others. We could
also encapsulate all the root path logic in that class as well. Caching
could be done there as well as logging. 

Thus far I was not able to reproduce the problem you described running on my
linux system, but when I create this class then I will test it heavily
including testing lock scenarios.

Jeff

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

From jeff.barczewski at gmail.com  Fri Jun  2 14:03:22 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 2 Jun 2006 13:03:22 -0500
Subject: [Masterview-devel] Masterview-devel post from
	dlewis@glaivestone.com requires approval
In-Reply-To: <19cda190606021101q25a85e58rbe69bca13bf18caf@mail.gmail.com>
References: <mailman.1493.1149261745.25533.masterview-devel@rubyforge.org>
	<19cda190606021101q25a85e58rbe69bca13bf18caf@mail.gmail.com>
Message-ID: <19cda190606021103j8c70da3j4d3fbc8ffd3e9964@mail.gmail.com>

I agree. The better we can name things, the better off we are in the long
run. It will be more intuitive to others and to us when we revisit code we
haven't looked at for a long time. Well worth the time to get it right. Sure
beats having to refactor it later too. I am fine with app_settings.rb or
settings.rb, but of the two I probably like settings.rb slightly better.




> > From: "Deb Lewis" <dlewis at glaivestone.com>
> > To: "masterview-devel" <masterview-devel at rubyforge.org >
> > Date: Fri, 2 Jun 2006 08:09:23 -0700
>
>
> Subject: RE: Masterview init rework - one more try
>  >> didn't see your aaasample-config (did it get committed?)
>
> oops, nope.  it's out there now (with LF's)
>
> Another possible tweak: not sure if I like the file name
> config/masterview/init.rb - kind of implies more than what's intended.  This
> file really shouldn't be doing much more than setting values in the config
> instance it's given, it's not really intended as a general "write
> initialization logic" - if you want to do additional app initialization to
> leverage MV once it's installed, that probably does properly belong in your
> environment.rb (where it's run when your own app has been initialized and
> installed, which isn't the case at the point when the plugin init is being
> run)
>
> So maybe config/masterview/settings.rb or
> config/masterview/app_settings.rb (?config/masterview/config.rb?!) would be
> a better name to express the intended scope of what goes in this file.
>
> philosophy rant: this might seem like nit-picking, but names *REALLY* do
> matter.  Getting the names right early on makes a huge, huge difference in
> the comprehensibility of the software, both for the developers and the
> users.  Affects how you talk about and think about what's going on.  I find
> up-front investment in fussing to get names and concepts right always has
> huge payoff over the long-term lifetime of the system.
>
> If you're lazy or get it wrong, it'll hurt your brain every single time
> forever after when you have to stop and think "lessee, X... oh yeah,
> that means Y"
>
> </rant>
>
> ~ Deb
>
>
> ---------- Forwarded message ----------
> From: masterview-devel-request at rubyforge.org
> To:
> Date:
> Subject: confirm fab40cb4519b52036e143d3fdf9a66cecde7f4cd
> If you reply to this message, keeping the Subject: header intact,
> Mailman will discard the held message.  Do this if the message is
> spam.  If you reply to this message and include an Approved: header
> with the list password in it, the message will be approved for posting
> to the list.  The Approved: header can also appear in the first line
> of the body of the reply.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060602/c4d99e1e/attachment-0001.htm 

From djlewis at acm.org  Fri Jun  2 17:43:42 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 2 Jun 2006 14:43:42 -0700
Subject: [Masterview-devel] Empty element generation, file locking redux
Message-ID: <20060602214346.WYTK5347.fed1rmmtao05.cox.net@DLI92cx797990>

Jeff,

You're right, empty elements are fine (<br/>, <hr/>).  I think my brain got
bent out of shape the other night when I was running before-and-after
compares to check that my original .rhtml pages came back after being
shifted into mv templates: one of my original files actually had bogus old
<br> markup, which MV quite nicely fixed to legal <br/> - guess I forgot
which side of the window was old vs. new.

I do find I miss having the trailing space "<xxx />" in the markup, though,
per the html compatibility guidelines of xhtml.  Maybe I'm just used to
looking at those, but it does make them easier to pick up visually.

What would you think of tweaking Render#simplify_empty_elements to:

          ret << ' />'  # nice little trailing space for visual separation

The problem I've seen where editing a template while the app is running and
subsequently getting a file lock conflict problem seems to be specific to
the HTML editor I use; doesn't happen when I edit the template file in a
diff editor.  

So action item to me to describe this as a trouble-shooting tip that we can
add to the docs.

~ Deb



From djlewis at acm.org  Fri Jun  2 18:29:44 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 2 Jun 2006 15:29:44 -0700
Subject: [Masterview-devel] On target patterns in mv:generate attributes
Message-ID: <20060602222947.ERIS18458.fed1rmmtao10.cox.net@DLI92cx797990>

[long discussion of what's actually a pretty simple notion - could be useful
input to docs as a howto recipe, e.g., "so you just want to get a simple set
of html pages into rails views without having to turn your pages into
disembodied .rhtml fragments"]

The issue: a lot of template files are simple wrappers around a chunk of
content intended to go into a page view within a nice rails layout which
provides standard header/sidebar framing in the site.  The MasterView
template gives me a complete, legal (x)HTML document to edit and view at
design time, possibly with placeholder framing for the headers and sidebars
that gets filled in by the rails app layout in the real site; the main body
of the template is now nicely wrapped for development editing and destined
for an rhtml file in app/views so it can get into the layout's <%=
@content_for_layout %> slot in the usual rails rendering fashion.

e.g., template foo.html is something like:

    <html ...><head>...</head>
    <body>
    <div>Note to self: page header banner and general nav features will go
here</div>
    <div mv:generate="foo.rhtml" mv:omit_tag="">
    ... page content for foo.rhtml goes here ....
    </div>
    </body>
    </html>

Now, I really hate creating a bunch of templates which require that I repeat
the template's file name (and subdirectory structure) within that file in
the mv:generate attribute.  If I change the name or reorganize the
directories, I have to change both the file system *and* the content.  Fails
to achieve the DRY principle.

So I want a notation in the mv:generate attribute value which makes it
simple to specify "use the relative path of this template file within the
template source directory as the generated file's relative path".

And I probably don't want to have to write ".rhtml" in every one of these,
either, so the notation should allow for "and replace the template file
extension (ordinarily '.html') with erb's usual .rhtml file extension" [or
an extension specified by the MasterView::Configuration, if customization is
needed]

Some notational possibilities:

   mv:generate=""
   mv:generate="*"
   mv:generate="{this_page}"
   mv:generate="{this_ref}"
   mv:generate="{rel_ref}"
   mv:generate="{template_ref}"
   mv:generate="*.rhtml"
   mv:generate="{template_ref}.rhtml"

Considerations:

- concise - keep it short and simple

- clear - notation should communicate the intent to someone working directly
with the template markup, not leave them scratching their head in
befuddlement

- allow for the possibility that in the future we might want to provide some
pattern-matching notations in this attribute to specify transformations on
the template file's relative path - possibly some RE notation to express a
transformation of the originating file's reference within the template
directory space.

~ Deb



From djlewis at acm.org  Fri Jun  2 21:30:02 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 2 Jun 2006 18:30:02 -0700
Subject: [Masterview-devel] Running unit tests standalone (indep of rails
	app context)
Message-ID: <20060603013019.XKIW27967.fed1rmmtao08.cox.net@DLI92cx797990>

OK, I've got unit test case execution working with pretty little red and
green bars in my eclipse workspace. wow.

Doing a first pass over all the existing tests to make sure they run
completely standalone - I'm running using a checked-out copy of masterview
trunk that's not inside a rails app directory structure context or rails
runtime env.  

Fixed one problem, still have 2 tests that don't run (template_file_watcher,
template_test) - these both might have something to do with either diffs in
our test setups or platform diffs between *nix and Win32; one failure
involves a file system "permission denied" error.

After I sort those out I'll bring in the new init/config code and fix the
problems that introduces so we have a clean test run.  I can already see bad
assumptions in what I did that need to be cleaned up to accomplish this.
This is a good exercise.

~ Deb



From djlewis at acm.org  Sat Jun  3 02:23:08 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 2 Jun 2006 23:23:08 -0700
Subject: [Masterview-devel] Fix in test/template_file_watcher_test
Message-ID: <20060603062309.OCQ19317.fed1rmmtao03.cox.net@DLI92cx797990>

Jeff - Appears to be a platform issue with using FileUtils.touch on
examples/product.html to force template timestamp update in
test/template_file_watcher_test#test_c_file_changed_run.

Fix is to cobble in a platform check and force the timestamp change
differently on win32.

Changed the technique slightly also, believe this is better: a test case
really shouldn't be changing anything in the deliverable files, so the test
setup in template_file_watcher_test now makes sure there's a separate copy
of the template file available as its test fixture - copies
examples/product.html to test/templates_src/product.html and then uses that
copy of the file for testing the file-changed watcher. 

Do me a favor and rerun that on *nix to reverify, thanks.

There's also a platform issue with test/template_test#test_multi_spec_dir,
which tests generation into a specific target output directory(/a/b).  On
Win32, the mv:generate='foo/bar' directive ends up with the current drive
letter prefixed to the target path, i.e., 'X:/a/b/foo/bar' rather than the
expected '/a/b/foo/bar'.  I'll chase that over the w/e to figure out whether
it's a legit issue or if we just need to write the test case a bit
differently.

~ Deb



From djlewis at acm.org  Sat Jun  3 12:08:09 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 3 Jun 2006 09:08:09 -0700
Subject: [Masterview-devel] Comment template substitution fields proposal
Message-ID: <20060603160810.UGPY27919.fed1rmmtao12.cox.net@DLI92cx797990>

Don't quite like the way the current generated-comment mechanism works.
Right now, the source template file name is bolted onto the end of whatever
generated-comment template is defined, whether you want it or not, and
whether that's where you'd like it presented or not.

Proposal: allow substitution fields in the comment template so users can
make the comment look any way they like.  Source template name isn't
required, though certainly recommended, and now it can be positioned
whereever desired, not just on the last line of the generated comment. 

Support "template_path" reference as a standard substitution target for the
full pathname of the template source file.  

Maybe also consider additional substitution vars to support:

  template_rel_path - relative pathname of the template file in the template
source dir
  ??template_timestamp - last-changed timestamp of the template file
  ??timestamp - timestamp of the generated file

Some sample variations and notation alternatives:

- notation style 1: Ruby variable string substitution notation:

# DO NOT EDIT - generated by MasterView from:
#    #{template_path}
# Changes made to this file will be lost when it is re-generated.

- notation style 2: erb notation:

# -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
# DO NOT EDIT - generated by MasterView from:
#    <%= template_path %>
# -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

I have a working implementation using the first approach #{template_path}.
Note that you do have to be a bit careful about the string literals you use
in this approach so that the variable substitution isn't evaluated while
you're defining the template itself.  But it's a bit more concise and
readable to my eye that the erb style.

What's your preference?  Shouldn't be hard to change if you'd rather go with
the erb-style notation.

~ Deb



From djlewis at acm.org  Sat Jun  3 12:31:01 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 3 Jun 2006 09:31:01 -0700
Subject: [Masterview-devel] test directory structure
Message-ID: <20060603163101.PDFG18458.fed1rmmtao10.cox.net@DLI92cx797990>

Not sure we need to make this change right this instant, but at some point I
think we should reorganize masterview's test directory structure into a more
general form, following the structure in a rails app (and fairly standard
elsewhere, I think):

  masterview
    ...examples, generators, lib, tasks directories...
    test
      fixtures - test fixtures here (template docs created for test
cases...)
      unit - move all our unit test classes here 
      test_helper.rb - helpers go at the main test dir

And tweak the rakefile to differentiate :test_units (run all the unit
tests), and general :test, which right now would just run the unit tests but
in the future might have other flavors of tests to run.

If you like this, I can go ahead and do it now while I'm making a pass over
everything so the new config mechanism works properly.

~ Deb



From djlewis at acm.org  Sat Jun  3 12:49:59 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 3 Jun 2006 09:49:59 -0700
Subject: [Masterview-devel] Time to start a docs subdirectory?
In-Reply-To: <19cda190606030931v747990bflf1eed8c05c4180e0@mail.gmail.com>
Message-ID: <20060603165000.DXSA554.fed1rmmtao11.cox.net@DLI92cx797990>

> > I agree about mentioning something about the locking problem you encou n
tered in the docs somewhere.
 
 Starting to think about breaking up the monolothic index.html into some
useful chunks and adding more stuff.
 
Maybe something along the lines of:
 
   masterview
      index.html - overview, goals, history, index of avialable docs...
      docs
         ?api - subdir to generated plugin docs at some point???
         installation.html - supported platforms, prereqs, installation (gem
or standalone)
         userguide.html - usage
         reference.html - directives reference (builtin directives)
         troubleshooting.html - common problems people might run into, etc
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060603/7f7078b5/attachment.htm 

From djlewis at acm.org  Sat Jun  3 17:15:07 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 3 Jun 2006 14:15:07 -0700
Subject: [Masterview-devel] Time to start a docs subdirectory?
In-Reply-To: <20060603165000.DXSA554.fed1rmmtao11.cox.net@DLI92cx797990>
Message-ID: <20060603211510.ZSNF15447.fed1rmmtao02.cox.net@DLI92cx797990>

I was just about to open a doc sub-directory and get a couple placeholders
dropped in for stuff I want to start writing (troubleshooting.html;
configuration.html to go with the config rework pass I'm doing today), but
now I can't find the message where I think you explained why you just put
that into svn:ignore on the trunk dir.
 
I'd like to back out the ignore on the trunk and install doc, add a couple
files, and change the rakefile rdoc generation task to generate into
doc/rdoc (?doc/api?) rather than directly into the main doc directory, which
then gets svn:ignore="rdoc"
 
Am I missing something here?!
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060603/03689b6b/attachment-0001.htm 

From djlewis at acm.org  Sat Jun  3 18:11:23 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 3 Jun 2006 15:11:23 -0700
Subject: [Masterview-devel] test directory structure
In-Reply-To: <19cda190606031502i2940e21aq96e4dcd53a0af7bc@mail.gmail.com>
Message-ID: <20060603221125.FIWR5347.fed1rmmtao05.cox.net@DLI92cx797990>

yep, that's the idea.  Let's recheck naming convention before changing the
rakefile, however, need to make sure we don't have any name space collisions
with test:.  Thought I recalled seing test_units rather than test:units when
I looked at a rail's task for comparison, but not sure about that.
 
oh, and when we do this the tmp directory used by the test cases can get
pulled under test, i.e., test/tmp, it doesn't need (and probably shouldn't)
be at the root level.
 
I can do this reorg, or let me know if you'd rather.  Think I'd like to get
it out of the way early on rather than deferring, just get it over with.
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Saturday, June 03, 2006 3:03 PM
To: djlewis at acm.org
Subject: Re: [Masterview-devel] test directory structure


That sounds good. Maybe something like this for the rake task names
(borrowing from rails)

rake test                      # Test all units and functionals
rake test:functionals          # Run functional tests


rake test:integration          # Run integration tests
rake test:units                # Run unit tests
As long as they all exist somewhere under the single main test directory I
am ok with it (ie. subdirectories are fine). 

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060603/61237ec9/attachment.htm 

From djlewis at acm.org  Sat Jun  3 18:25:52 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 3 Jun 2006 15:25:52 -0700
Subject: [Masterview-devel] On using your own tools
Message-ID: <20060603222552.VKQZ11027.fed1rmmtao07.cox.net@DLI92cx797990>

thought of the day: we ought to be able to use MasterView to generate its
own documentation

I'm going through the initializer to clean up the (somewhat inadvertent)
assumptions and dependencies about existing solely w/in a rails app context,
which we need to solve so the unit tests run, and working on rdoc commentary
plus separate config guide (doc/configuration.html).

insight 1: it's a worthy goal #4 in its own right to assert that while
MasterView is principally intended for use as a Rails plugin, it ought to be
equally usable independent of rails

insight 2: as soon as I start sketching out more than one doc to go into the
doc dir, I decide... I really want a standard page framing layout on all
these docs (masterview banner, some std nav to link back to the main home
doc so reader can easily jump around between user guide, directives ref,
config guide...).  Wait a minute - MV does that!

Whaddya know - this is exactly the scenario I started out trying to solve
for my own rails app - I want to work on my content pages as complete
standalone html pages, but I want to publish them with a standard layout
across a set of pages (without manually replicating the framing)

~ Deb

p.s. we need a stylesheet for the doc directory at some point



From djlewis at acm.org  Sat Jun  3 18:35:16 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 3 Jun 2006 15:35:16 -0700
Subject: [Masterview-devel] Comment template substitution fields proposal
In-Reply-To: <19cda190606031519g3104ff91w1654bcbc74d3be6a@mail.gmail.com>
Message-ID: <20060603223517.GIWG5347.fed1rmmtao05.cox.net@DLI92cx797990>

RE: long-term goal to eliminate the generated .rhtml erb files
 
oh, lovely indeed.  That's exactly what I started out looking at doing on my
own a few weeks ago, before deciding it wasn't a quick hack - I wanted to
write my app/views as .pt files (as in zope page templates) which just
magically did the right thing through the same caching cleverness that
that's used for .rhtml templates in there now.
 
Wasn't sure if you were ready to hear a proposal for that notion, since
clearly there's plenty of other things to do just with the current scheme.
So - thank you for sharing that thought!
 
Definitely put this in a "future directions" section in the docs.
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Saturday, June 03, 2006 3:19 PM
To: djlewis at acm.org
Subject: Re: [Masterview-devel] Comment template substitution fields
proposal


That sounds fine to me. ruby inline substitution is fine. If you need me to
help with any of this let me know. 

Also just to keep you up to date with my current thoughts, the long term
plan is to eliminate the need for erb generation at all. I started out this
way so that it would be easy to develop and easy to debug. n the future erb
generation will be configurable since it won't technically be needed if we
load the compiled erb directly into the rails erb cache. 

This will eliminate clutter and confusion from having these generated rhtml
files. Of course we could allow it to be configured to generate them anyway.
I also envisioned a way to request the erb file off of the masterview admin
pages or via rake tasks if for any reason one wants to get the files. 

But there are many things to figure out and test before we go down that
path.

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060603/8a025b07/attachment.htm 

From djlewis at acm.org  Sun Jun  4 16:56:38 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sun, 4 Jun 2006 13:56:38 -0700
Subject: [Masterview-devel] test directory structure
In-Reply-To: <20060603163101.PDFG18458.fed1rmmtao10.cox.net@DLI92cx797990>
Message-ID: <20060604205640.QHCC15447.fed1rmmtao02.cox.net@DLI92cx797990>

Done.  Mostly just needed code import refs adjusted for the dir level
change.

  test
    fixtures
    --tmp directory used for execution is on svn:ignore of main test dir
    unit - all the *_test.rb unit tests

Rakefile tasks:
- test:units - run all the unit tests
- test - run all tests (currently only unit tests exist)

One "philosphical" modification: I pulled over copies of
examples/product.html and examples/test.import into test/fixtures.
Rationale: test cases shouldn't be depend on examples being published for
users - test fixtures should be specific to what we;'re trying to test,
shouldn't inadvertantly break tests just because at some point in future we
change the examples for other reasons.

Test cases using these fixtures are: run_parser_test, template_file_watcher,
template_spec_test

[i'll back out if you disagree; don't like duplication of that file, but
maybe we just need a stripped-down variation as the test fixture anyway -
whatever, your call]

Maybe one other change to consider: after working with all these tests, I
thought it would have been mildly helpful if naming convention of the files
differentiated tests focused strictly on the built-in directives from more
general tests, e.g., directive_XXX_test.rb.  Not a big deal, but I'll make
that  change if you think it would be helpful.

~ Deb



From djlewis at acm.org  Sun Jun  4 19:02:22 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sun, 4 Jun 2006 16:02:22 -0700
Subject: [Masterview-devel] Comment template substitution fields proposal
In-Reply-To: <19cda190606031519g3104ff91w1654bcbc74d3be6a@mail.gmail.com>
Message-ID: <20060604230223.SBOC14446.fed1rmmtao12.cox.net@DLI92cx797990>

>> ruby inline substitution is fine
 
ok, if you're happy with that then we'll go with I already have working
 
Just in case I wasn't clear, the variable substitution in the generated-file
comment template occurs at template processing time; it doesn't go into the
template output file as an erb field in the generated rhtml.
 
So the reference  #{template_path} or <%= template_path %> (or
{{{template_path}}}...), depending on our notation choice, is only used when
an app developer sets the MasterView configuration setting for the comment
content and is resolved during template processing - the output rhmtl that's
generated looks exactly like it does now.
 
The only real differentiator is what's the likely mind-set when you sit down
to write a config/masterview/settings.rb file.  When you install a
customized value for the generated-file comment, are you thinking "I'm
writing a ruby string literal that will have double-quote substitution
processing" or is it easier to think "I'm writing a string that's an ERB
template"
 
A MasterView programmer probably has both of those mind-sets, so to me it's
really a tossup.
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060604/71bbe96b/attachment.htm 

From djlewis at acm.org  Mon Jun  5 20:44:05 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 5 Jun 2006 17:44:05 -0700
Subject: [Masterview-devel] ParserHelpers expmt
Message-ID: <20060606004411.HCGD14446.fed1rmmtao12.cox.net@DLI92cx797990>

Jeff - I stored the stuff I've been playing with to handle mv:generate="*"
in the repository.  Read the header comment for some notes and instructions
on where/how I have this hooked up in my local copy of the parser.

I've actually got two variations of magic values that are already useful:

mv:generate="*" - wraps stuff that I'm sending to <%= @content_for_layout %>
slot, so shorthand is "generate an rhtml output file with the same name and
relative dir path as the source template"

and I've got another variation (horrible notation, but it works for initial
my prototype):

mv:generate="*.xxx" - wraps stuff that I'm sending to an output file with
the same rel dir/file base name, but a diff extension (in particular usage,
I've got embedded styles in the template header that I want emitted in so I
get a foo.css and foo.rhtml pair of files out of my foo.html template)

Expect it might also be useful to have a magic notation for same relative
directory path, if any, but an explicit target file name, but I haven't got
a scenario to justify that yet.

~ Deb



From djlewis at acm.org  Tue Jun  6 01:00:37 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 5 Jun 2006 22:00:37 -0700
Subject: [Masterview-devel] New init/config stuff ready to be submitted
Message-ID: <20060606050042.LYPE19317.fed1rmmtao03.cox.net@DLI92cx797990>

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



From djlewis at acm.org  Tue Jun  6 13:31:42 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 6 Jun 2006 10:31:42 -0700
Subject: [Masterview-devel] New init/config stuff ready to be submitted
In-Reply-To: <19cda190606061007icd5dcb0i25a05b19c0bf32b6@mail.gmail.com>
Message-ID: <20060606173146.TZHI24290.fed1rmmtao09.cox.net@DLI92cx797990>

I'll take a look at the testing with gem install if I can get to it later
later today, it'd be a good exercise for me to run through the build
production cycle anyway.  I've been running everything so far with my
working copy mapped into the plugin load path for rails.  (environment
configs, way cool notion of rails)
 
RE: need to update/synch the masterview_plugin generator's copy of init.rb -
yes, have that in my pending changes pile to submit when we're ready to
activate the new init.  Not sure if there's a clever svn way to ensure
automatic cloning (svn:externals possibly, but I haven't really grokked
those yet).  Or maybe just a rake task or even just a little unit test to
verify consistency of these two files so we don't forget to keep them in
synch.  I'll look into that one and do something.
 
Per your other note, I'll go in right now and do the
unit/directive_XX_test.rb renaming just to get it out of the way.
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060606/ff282ba0/attachment.htm 

From djlewis at acm.org  Tue Jun  6 16:50:42 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 6 Jun 2006 13:50:42 -0700
Subject: [Masterview-devel] New init/config stuff ready to be submitted
In-Reply-To: <19cda190606061127t79167e0cu3c0ab012e0a0640c@mail.gmail.com>
Message-ID: <20060606205047.XCCG5347.fed1rmmtao05.cox.net@DLI92cx797990>

yes - believe replies should go to the list unless someone explicitly wants
to take a thread private, i think.
 
Maybe leave -commits as reply to commiter, if that's how that one is set up.
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Tuesday, June 06, 2006 11:27 AM
To: djlewis at acm.org
Subject: Re: [Masterview-devel] New init/config stuff ready to be submitted


Should I change the reply-to for this list to go automatically back to
masterview-devel? What about the other lists? Should they all be reply-to
the mailing list address?

I'm thinking they should, since that is the way most mailing lists are. 

If you agree then we can update rubyforge mailmain accordingly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060606/6b6deab4/attachment.htm 

From jeff.barczewski at gmail.com  Wed Jun  7 07:41:35 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 7 Jun 2006 06:41:35 -0500
Subject: [Masterview-devel] New init/config stuff ready to be submitted
In-Reply-To: <20060606050042.LYPE19317.fed1rmmtao03.cox.net@DLI92cx797990>
References: <20060606050042.LYPE19317.fed1rmmtao03.cox.net@DLI92cx797990>
Message-ID: <19cda190606070441x61fdbd13gd97d399e98d2c8db@mail.gmail.com>

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 

From jeff.barczewski at gmail.com  Wed Jun  7 08:24:14 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 7 Jun 2006 07:24:14 -0500
Subject: [Masterview-devel] Current release steps
Message-ID: <19cda190606070524l762ceeb1r5d5ed2ab91b45001@mail.gmail.com>

Here are the current release steps as of June 7, 2006

rake test
(make sure no failures or errors)

rake rdoc
(make sure builds ok)
(I do have a custom require warning that I would eventually like to
eliminate from the output but not sure how to accomplish that)


test locally as plugin for a rails app
---------------------------------------------------------
script/generate masterview Model Controller
script/server
(See if the app works as it should)
(make change to an app/views/masterview template file)
(Refresh browser and see change immediately picked up (if in development
mode)
http://localhost:3000/masterview/admin
(should see list)
(invalidate the xhtml of a masterview template add something like
</breakxhtml>)
refresh browser
(should show that file is not parseable (without tidy turned on)
rake mv:list
rake mv:list_all
(both of these commands should show the same listing as webapp and should
show the statuses)
(fix the xhtml again by taking out the </breakxhtml>)
(invalidate the imported layout of one of the mv template, for example add
something to title in
masterview template for destroy.)
visit masterview/admin page, rake mv:list, rake mv:list_all and you should
see the fact that destroy template is out of sync.
Use rebuild or rebuild all link from webapp, and/or rake mv:rebuild
TEMPLATE=foo.html or rake mv:rebuild_all
visit masterview/admin page, rake mv:list, rake mv:list_all and you should
see the fact that everything is OK
Visit app pages to see everything working as should.


test locally as a gem installation on another fresh rails app
----------------------------------------------------------------------------------------------------------------------------
(install local gem, if we were pulling from repository then gem install
masterview_gem_pack --include-dependencies, however since we want to test
before uploading to rubyforge, we need to do this locally, I don't recall
the commands to install a local gem)
script/generate masterview_plugin
script/generate masterview Model Controller
(same tests as above)


Ideally we will eventually create some system tests that we can run from
rake to do all this making it easy to test (just haven't gotten to it yet)

Once all that is done we are ready to release

(note that we were going to use tag latest to represent latest build but
because script/plugin install uses the last part of url for directory name,
we need to name the latest tag simply masterview)
with subversion create release tag MASTERVIEW_X_Y_Z, remove existing
'masterview' tag and recreate masterview tag from current this is what
people will be pulliing from for plugin install

rake package
rake release_files RUBYFORGE_USER=  RUBYFORGE_PASSWORD=   (or put those in
your shell environment)
(this should publish the current versioned package for all of the parts
(masterview, masterview_generator, masterview_plugin_generator,
masterview_gem_pack) as well as a tar and zip version of the plugin up to
rubyforge. It builds the release notes from RELEASE_NOTES and CHANGELOG.

(eventually we will post mail announcements too, but I haven't gotten to
that yet)
(At this point the new verison of files should be on rubyforge files
directory, every so often I go up and remove the really old versions. I
haven't created a rake command to do this all yet)

It will take a while for the gem to become available usually within a half
hour or so
I then test pulling the gem
gem install masterview_gem_pack --include-dependencies
I check that the right version came down and then do a quick rails test
again.

gem uninstall masterview

(test plugin install)
script/plugin install svn://rubyforge.org/var/svn/masterview/tags/masterview
(retest)

That should do it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060607/17a7ac90/attachment.htm 

From jeff.barczewski at gmail.com  Wed Jun  7 08:38:26 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 7 Jun 2006 07:38:26 -0500
Subject: [Masterview-devel] I see you do have some sample configs in your
	fixtures test directory
Message-ID: <19cda190606070538l27795f9fwdb0e944075539b86@mail.gmail.com>

I see you do have some sample configs in your fixtures test directory (as
you mentioned in your email too).

But I think we still should create a fully spelled out commented out version
that a user can copy and maybe put it in
examples/config/masterview/settings.rb, just to make it super easy.

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

From jeff.barczewski at gmail.com  Wed Jun  7 10:09:36 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 7 Jun 2006 09:09:36 -0500
Subject: [Masterview-devel] I think this next release should be 0.2.0
Message-ID: <19cda190606070709l6f50c0ffpd19f9f90133b75ad@mail.gmail.com>

I think we should number the next release 0.2.0 since we have a big change
in how configuration is done. Would you concur?

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

From djlewis at acm.org  Wed Jun  7 12:22:58 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 7 Jun 2006 09:22:58 -0700
Subject: [Masterview-devel] creating masterview release tag,
	latest won't work properly for script/plugin install
In-Reply-To: <19cda190606070535w5e2e2feeq1a02956bd1aa0b3f@mail.gmail.com>
Message-ID: <20060607162302.ZNZZ12581.fed1rmmtao02.cox.net@DLI92cx797990>

Jeff - that's fine, i wasn't wild about 'latest' anyway.
 
Please note the other tag I just installed in the repository so that there's
a clear record of release configurations: masterview-0.1.5 to archive the
config of the last build you did.
 
When we release a new build, I'ld like the procedure and repos tagging to
be:
 
(1) prereq: ensure that lib/masterview_version.rb is in synch with the
package number on the release build artifacts - something's a bit out of
whack in the current tags/masterview config - last release was 0.1.5, but I
see 0.1.4 out there in the code, so not quite sure whether that's a correct
config.  If our current build process doesn't automatically ensure that the
-version.rb is in synch with the build number then we need to fix something.
 
[ignore this comment if that's already the case and the repos tag is just
funky because we're sorting out how to get it set up properly]
 
(2) repository entry 'tags/masterview-M.N.X' gets copied from the trunk in
synch with publication of the packaged release files (gems and zips) onto
the rubyforge project site.  Believe this can/should be automated with rake
task that become part of our build process.
 
(3) repository entry 'tags/masterview' is reset to the new stable build
release (delete, then make copy of new release build tag...)
 
~ Deb

  _____  

From: masterview-commits-bounces at rubyforge.org
[mailto:masterview-commits-bounces at rubyforge.org] On Behalf Of Jeff
Barczewski
Sent: Wednesday, June 07, 2006 5:35 AM
To: masterview-commits at rubyforge.org
Subject: Re: [Masterview-commits] [68] tags/masterview/: creating
masterviewrelease tag,latest won't work properly for script/plugin install
(it puts thefile in vendor/plugins/latest rather than masterview)


I found out that 

script/plugin install svn://rubyforge.org/var/svn/masterview/tags/latesst
installs in vendor/plugins/latest so we need to actually create a tag called
masterview instead of latest. 

Once I get done updating the urls on the web to this I will get rid of the
latest tag. 

Jeff

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

From djlewis at acm.org  Wed Jun  7 12:22:58 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 7 Jun 2006 09:22:58 -0700
Subject: [Masterview-devel] I think this next release should be 0.2.0
In-Reply-To: <19cda190606070709l6f50c0ffpd19f9f90133b75ad@mail.gmail.com>
Message-ID: <20060607162305.ZOBJ12581.fed1rmmtao02.cox.net@DLI92cx797990>

agree, was going to suggest that.  There'll be some non-trivial changes
coming in this next release, version number should bump up suitably (MINOR
increment, not just TINY changes...)
 
~ 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 7:10 AM
To: masterview-devel at rubyforge.org
Subject: [Masterview-devel] I think this next release should be 0.2.0


I think we should number the next release 0.2.0 since we have a big change
in how configuration is done. Would you concur?

Jeff

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

From djlewis at acm.org  Wed Jun  7 12:36:17 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 7 Jun 2006 09:36:17 -0700
Subject: [Masterview-devel] New init/config stuff ready to be submitted
In-Reply-To: <19cda190606070441x61fdbd13gd97d399e98d2c8db@mail.gmail.com>
Message-ID: <20060607163620.OWGH14446.fed1rmmtao12.cox.net@DLI92cx797990>

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 

From djlewis at acm.org  Wed Jun  7 13:28:56 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 7 Jun 2006 10:28:56 -0700
Subject: [Masterview-devel] On default config values for dir locations
	(templates, directives)
Message-ID: <20060607172859.YJHT11027.fed1rmmtao07.cox.net@DLI92cx797990>

Jeff - some thoughts on some of the current default config settings for key
locations that MV deals with.

[long, this is kind of a "thinking out loud" msg to elaborate some
alternatives]

Current MV config defaults:

- template source directory;
   - rails app: app/views/masterview
   - non-rails config: not sure if there's a good default assumption
      [I put in './masterview/templates' for now...]

- template output directory:
    - rails app: app/views
    - non-rails config: nil - client needs to say what they want

- directives load path:
    - initialized to load mv built-in directives:
        [ "#{MV_LIB_DIR}/masterview/directives' ]

I'm now quite happily in the process of converting some content pages for a
site that I'm moving onto rails into masterview templates.  This is a
relatively simple use case scenario: mainly wrapping some existing, fairly
static content in MV templates with mv:generate="*" specs to spit out body
content into an .rhmtl for the <%= @content_for_layout %> slot in the rails
site's layout.  Some lightweight usage of mv/rails facilities (mv:attr to
map some hrefs between ref in my template sandbox to how the urls look in
the real site).

Aside from still needing to settle on notation for mv:generate to provide
"magic values" ("*" or "#{template_rel_ref}" or a pythonic-style
"__template_rel_ref_" or ...) or var subst for target path, I'm quite happy
with how this works.  MV lets me create content pages as complete, valid
xhtml docs and supports declarative-style markup using the mv: attributes.
Very nice.

But I've gone through several variations of "where do I want to keep my
template files" over the past week, partly just to play with the mechanisms
and test things.  I've used:

    app/views/masterview - the default config
    app/mv-templates - sibling structure which maps output into app/views

[and not tried but might consider: app/views/masterview/templates - fits in
with the MasterviewController structure]

I somewhat prefer the sibling dir alongside app/views over the current
default w/in the views dir - I like the symmetry of the parallel structure,
rather than pushing masterview templates into a somewhat odd,
not-used-in-quite-the-usual-fashion area within app/views.

But what I've actually settled on, which what I wanted in the first place
and is the right structure in the long run:

    app/views - MV .html templates live right where they belong

The fact that generated .rhtml files appear alongside my .html templates is
simply an artifact of the current MV implementation.  Someday (*), the
.rhtml intermediate files won't need to be there - a view ref that maps onto
a MV template will do the same magic compile-on-the-fly and caching that
rails does now for its .rhtml files.

(*) maybe even soon, because I can begin to see a way to do this, at least
for this simple scenario where there aren't inter-template generate/import
dependencies

After first pass to settle the basic structure in my site, I now see an
opportunity to use a custom directive to simplify some annoying markup
redundancy in the original static impl.  I'm going to give that a try and if
it works out it'll be a good example to deliver with MV.  Specific case is
that I have a number of pages which are just indexes to report files and
each report link has a little document icon indicating the form of the
report (an html view or a printable view or a PDF file).  So a little
icon_for_link directive would be a really handy gadget for this site.

All of which is the rationale leading into other thought on MV config
defaults: believe it would be useful for the default config for a rails
application to have a point of view on where it might find app-specific
directives to automatically load.  If app dir's directory exist, append to
config.directive_paths after the MV built-ins.

Not sure putting directives code in config/masterview/directives is the
right place.  Possible app/masterview/directives; possibly
app/lib/masterview/directives is better (but need to review rails loading
magic to see if that would work, don't want rails itself to auto-load things
in there)

Opinion?  I hypothesize that the empty directives dir in the masterview
trunk was your notion for providing a convention for this, but don't think
that's the right place.

~ Deb



From djlewis at acm.org  Wed Jun  7 13:53:06 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 7 Jun 2006 10:53:06 -0700
Subject: [Masterview-devel] A few observations from MV usage
Message-ID: <20060607175310.NQVQ554.fed1rmmtao11.cox.net@DLI92cx797990>

A few other observations from MV usage:

(1) generated-file comments should only be inserted into .rhtml files 

-- I'll include a fix for this when new var-subst feature for comment text
is committed

If necessary to generalize, add MasterView::Configuration setting allowing
specification of output file extensions which are erb targets; default value
[ '.rhtml' ]


(2) DirectiveHelpers should in some fashion explicitly distinguish:

    ERB_CONTENT_END = ' %>'
    ERB_NO_CONTENT_END = ' -%>'

and we should either drop the current ERB_END or else take a point of view
on what the "normal" usage is and then just define additional constant for
the alt. flavor.

(??review which flavor DirectiveHelpers#erb uses, vs. erb_content??)


(3) suspect we'll eventually want to handle multiple namespaces for
directives that MV processes.  app might well want to mark its custom
directives with its own namespace; perhaps there will be some std libraries
of useful directives (wouldn't that be a good problem to have?!)

Wasn't clear when I did a quick skim of the current code whether we can
handle that yet, but it would be something to consider/plan for.


(4) need to think about default for when masterview admin controller is
exposed in app (always? only in development unless app's config turns it on
for production?)

And need to understand/document how an app programmer would restrict access
to the mv admin controller in their app if they want to do that.  (which I
think they probably should be doing in a production site)  My other top
to-do for migrating some existing sites on rails besides this template stuff
is establishing my user authentication/authorization infrastructure, so I
hit this issue very soon.

~ Deb



From jeff.barczewski at gmail.com  Wed Jun  7 14:40:13 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 7 Jun 2006 13:40:13 -0500
Subject: [Masterview-devel] creating masterview release tag,
	latest won't work properly for script/plugin install
In-Reply-To: <20060607162302.ZNZZ12581.fed1rmmtao02.cox.net@DLI92cx797990>
References: <19cda190606070535w5e2e2feeq1a02956bd1aa0b3f@mail.gmail.com>
	<20060607162302.ZNZZ12581.fed1rmmtao02.cox.net@DLI92cx797990>
Message-ID: <19cda190606071140q18cc8fcx1c5bc3e2095fd069@mail.gmail.com>

Sounds good. Yes the current build process will use the version out of
mastervie_version.rb to build, so I always update it whenvever I want to do
a new build.

On 6/7/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  Jeff - that's fine, i wasn't wild about 'latest' anyway.
>
> Please note the other tag I just installed in the repository so that
> there's a clear record of release configurations: masterview-0.1.5 to
> archive the config of the last build you did.
>
> When we release a new build, I'ld like the procedure and repos tagging
> to be:
>
> (1) prereq: ensure that lib/masterview_version.rb is in synch with the
> package number on the release build artifacts - something's a bit out of
> whack in the current tags/masterview config - last release was 0.1.5, but
> I see 0.1.4 out there in the code, so not quite sure whether that's a
> correct config.  If our current build process doesn't automatically ensure
> that the -version.rb is in synch with the build number then we need to fix
> something.
>
> [ignore this comment if that's already the case and the repos tag is just
> funky because we're sorting out how to get it set up properly]
>
> (2) repository entry 'tags/masterview-M.N.X' gets copied from the trunk in
> synch with publication of the packaged release files (gems and zips) onto
> the rubyforge project site.  Believe this can/should be automated with rake
> task that become part of our build process.
>
> (3) repository entry 'tags/masterview' is reset to the new stable build
> release (delete, then make copy of new release build tag...)
>
> ~ Deb
>
>  ------------------------------
> *From:* masterview-commits-bounces at rubyforge.org [mailto:
> masterview-commits-bounces at rubyforge.org] *On Behalf Of *Jeff Barczewski
> *Sent:* Wednesday, June 07, 2006 5:35 AM
> *To:* masterview-commits at rubyforge.org
> *Subject:* Re: [Masterview-commits] [68] tags/masterview/: creating
> masterviewrelease tag,latest won't work properly for script/plugin install
> (it puts thefile in vendor/plugins/latest rather than masterview)
>
> I found out that
>
> script/plugin install svn://rubyforge.org/var/svn/masterview/tags/latesst
> installs in vendor/plugins/latest so we need to actually create a tag called
> masterview instead of latest.
>
> Once I get done updating the urls on the web to this I will get rid of the
> latest tag.
>
> Jeff
>
> _______________________________________________
> 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/1c5783e9/attachment.htm 

From jeff.barczewski at gmail.com  Wed Jun  7 14:44:48 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 7 Jun 2006 13:44:48 -0500
Subject: [Masterview-devel] New init/config stuff ready to be submitted
In-Reply-To: <20060607163620.OWGH14446.fed1rmmtao12.cox.net@DLI92cx797990>
References: <19cda190606070441x61fdbd13gd97d399e98d2c8db@mail.gmail.com>
	<20060607163620.OWGH14446.fed1rmmtao12.cox.net@DLI92cx797990>
Message-ID: <19cda190606071144q10f5a8baw30a77e0f094b49a7@mail.gmail.com>

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 

From jeff.barczewski at gmail.com  Wed Jun  7 15:11:43 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 7 Jun 2006 14:11:43 -0500
Subject: [Masterview-devel] On default config values for dir locations
	(templates, directives)
In-Reply-To: <20060607172859.YJHT11027.fed1rmmtao07.cox.net@DLI92cx797990>
References: <20060607172859.YJHT11027.fed1rmmtao07.cox.net@DLI92cx797990>
Message-ID: <19cda190606071211g6f22cf4m7fe19e64e33758a4@mail.gmail.com>

Yes, we are on pretty much the same page here.

I think that ultimately they should go in the app/views directory right
where they belong. The only reason I didn't put them there originally is
because I didn't want users to get confused and such. However once we can
eliminate the erb intermediate file then there is no confusion.

So app/views/controller/action.html will work out well.

I think I can add the direct to erb cache pretty soon, but if we wanted to
so something like app/masterview in the meantime we could since that has the
advantage of being the same subdirectory depth as app/views.

As for the directives, I too wasn't sure where to put them. I put them down
in the plugin directory because that seemed to be where to keep everything
together, but it isn't necessarily the best place. And I was trying to think
about ways where they could reuse the custom directives across apps, so it
is fine to allow them to put things into an app config directory but I want
to make sure to have a way for directives to be loaded in other directories
too. It turns out though that as long as they load masterview.rb first, then
they can simply require anything else in that they want and they will show
up as directives (if they inherited from directive_base)>

Your suggestion about using app/masterview/directives sounds like a good
one.

For keyword expansion, I started out with ruby inline substitution but since
that conflicted with the erb inline substitution using the same notation, I
fell back to plan B.

Plan B was to just do simple keyword expansion of simple text.
Here is the keywords I used in my first iteration of this.

For template path = app/views/masterview/foo/bar.html where
app/views/masterview is the template root
TEMPLATE_PATH = foo/bar.html
* = foo/bar
SHORTNAME = foo/bar (same as *, its the template_path minus the extension)
CONTROLLER = foo
ACTION = bar
EXTENSION = .html

I originally had additional ones but I think these would be the core.

We could even allow this to be configurable too, if for instance someone
wanted to use one of these. That would theoretically allow them to use
something like {template_path} if they wanted to for the keyword rather than
the all capital names.

But I like this simplicity since upper case is typically seen as a
replacement (or constant) and * is not typically used for a path, then
something like this works well. It also stands out when you ready it and is
cleaner than using {template_path} so they would do
layouts/CONTROLLER.rhtml    *.rhtml etc.

We can also assume that if they don't specify an extension that it would use
the default setup '.rhtml' that way they can just use * and be done.

The way I wrote the keyword expander is that it would start with the longest
strings first so even if we ended up having keywords that used the same
subwords (not recommended) but it would still work.

Typically keyword expansion is only needed on generate, gen_* and import*
commands so by having it default to on only for those it doesn't affect most
other directives.

Jeff


On 6/7/06, Deb Lewis <djlewis at acm.org> wrote:
>
> Jeff - some thoughts on some of the current default config settings for
> key
> locations that MV deals with.
>
> [long, this is kind of a "thinking out loud" msg to elaborate some
> alternatives]
>
> Current MV config defaults:
>
> - template source directory;
>    - rails app: app/views/masterview
>    - non-rails config: not sure if there's a good default assumption
>       [I put in './masterview/templates' for now...]
>
> - template output directory:
>     - rails app: app/views
>     - non-rails config: nil - client needs to say what they want
>
> - directives load path:
>     - initialized to load mv built-in directives:
>         [ "#{MV_LIB_DIR}/masterview/directives' ]
>
> I'm now quite happily in the process of converting some content pages for
> a
> site that I'm moving onto rails into masterview templates.  This is a
> relatively simple use case scenario: mainly wrapping some existing, fairly
> static content in MV templates with mv:generate="*" specs to spit out body
> content into an .rhmtl for the <%= @content_for_layout %> slot in the
> rails
> site's layout.  Some lightweight usage of mv/rails facilities (mv:attr to
> map some hrefs between ref in my template sandbox to how the urls look in
> the real site).
>
> Aside from still needing to settle on notation for mv:generate to provide
> "magic values" ("*" or "#{template_rel_ref}" or a pythonic-style
> "__template_rel_ref_" or ...) or var subst for target path, I'm quite
> happy
> with how this works.  MV lets me create content pages as complete, valid
> xhtml docs and supports declarative-style markup using the mv: attributes.
> Very nice.
>
> But I've gone through several variations of "where do I want to keep my
> template files" over the past week, partly just to play with the
> mechanisms
> and test things.  I've used:
>
>     app/views/masterview - the default config
>     app/mv-templates - sibling structure which maps output into app/views
>
> [and not tried but might consider: app/views/masterview/templates - fits
> in
> with the MasterviewController structure]
>
> I somewhat prefer the sibling dir alongside app/views over the current
> default w/in the views dir - I like the symmetry of the parallel
> structure,
> rather than pushing masterview templates into a somewhat odd,
> not-used-in-quite-the-usual-fashion area within app/views.
>
> But what I've actually settled on, which what I wanted in the first place
> and is the right structure in the long run:
>
>     app/views - MV .html templates live right where they belong
>
> The fact that generated .rhtml files appear alongside my .html templates
> is
> simply an artifact of the current MV implementation.  Someday (*), the
> .rhtml intermediate files won't need to be there - a view ref that maps
> onto
> a MV template will do the same magic compile-on-the-fly and caching that
> rails does now for its .rhtml files.
>
> (*) maybe even soon, because I can begin to see a way to do this, at least
> for this simple scenario where there aren't inter-template generate/import
> dependencies
>
> After first pass to settle the basic structure in my site, I now see an
> opportunity to use a custom directive to simplify some annoying markup
> redundancy in the original static impl.  I'm going to give that a try and
> if
> it works out it'll be a good example to deliver with MV.  Specific case is
> that I have a number of pages which are just indexes to report files and
> each report link has a little document icon indicating the form of the
> report (an html view or a printable view or a PDF file).  So a little
> icon_for_link directive would be a really handy gadget for this site.
>
> All of which is the rationale leading into other thought on MV config
> defaults: believe it would be useful for the default config for a rails
> application to have a point of view on where it might find app-specific
> directives to automatically load.  If app dir's directory exist, append to
> config.directive_paths after the MV built-ins.
>
> Not sure putting directives code in config/masterview/directives is the
> right place.  Possible app/masterview/directives; possibly
> app/lib/masterview/directives is better (but need to review rails loading
> magic to see if that would work, don't want rails itself to auto-load
> things
> in there)
>
> Opinion?  I hypothesize that the empty directives dir in the masterview
> trunk was your notion for providing a convention for this, but don't think
> that's the right place.
>
> ~ 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/1f12ae50/attachment-0001.htm 

From jeff.barczewski at gmail.com  Wed Jun  7 15:28:12 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 7 Jun 2006 14:28:12 -0500
Subject: [Masterview-devel] A few observations from MV usage
In-Reply-To: <20060607175310.NQVQ554.fed1rmmtao11.cox.net@DLI92cx797990>
References: <20060607175310.NQVQ554.fed1rmmtao11.cox.net@DLI92cx797990>
Message-ID: <19cda190606071228w6c204e3aw808cbf0086a9d0a@mail.gmail.com>

1) agreed, generated comment is only for erb files as it currently is. (Are
we ok not putting anything in other files??, should we think about doing
that? For now let's keep it simple, but someday we may want to have
different comment types for different types of files, so users know this is
generated.

2) I struggled with what to name the ERB constants. Something like what you
proposed would be pretty clear.

3) We can handle directives created in other module namespaces but they
still all get mapped down to one prefix currently. You can control the what
the attribute name is is used independent of directive class name so it is
pretty flexible (defaults to lowercase directive class name). However I see
your point in that it would be nice to support multiple namespaces, that
would be a nicer thing to do. We would just map a prefix to a module
namespace and everything works pretty nicely. I wish I had thought of that
earlier, but probably won't be too hard to retrofit.

4) I thought about doing a variety of schemes for user authentication, even
something as simple as having a set user password and only doing it in
development, etc. However I went with the simplest approach at first
figuring there are many ways to skin this.

I had used the engines version of RBAC for a project and that worked out
pretty nice because it was pretty unintrusive. Bolt on authentication is
nice. However I didn't want to put any big dependencies on things since the
current plugin mechanism doesn't have a nice way to do dependencies (that I
am aware of) so users have to manually install prerequisites or one has to
bundle them in (which is generally not the best way). I think eventually
plugins will move toward something more like gems, but the gems system needs
to be made easier to use without root access (for shared servers).

Jeff

On 6/7/06, Deb Lewis <djlewis at acm.org> wrote:
>
> A few other observations from MV usage:
>
> (1) generated-file comments should only be inserted into .rhtml files
>
> -- I'll include a fix for this when new var-subst feature for comment text
> is committed
>
> If necessary to generalize, add MasterView::Configuration setting allowing
> specification of output file extensions which are erb targets; default
> value
> [ '.rhtml' ]
>
>
> (2) DirectiveHelpers should in some fashion explicitly distinguish:
>
>     ERB_CONTENT_END = ' %>'
>     ERB_NO_CONTENT_END = ' -%>'
>
> and we should either drop the current ERB_END or else take a point of view
> on what the "normal" usage is and then just define additional constant for
> the alt. flavor.
>
> (??review which flavor DirectiveHelpers#erb uses, vs. erb_content??)
>
>
> (3) suspect we'll eventually want to handle multiple namespaces for
> directives that MV processes.  app might well want to mark its custom
> directives with its own namespace; perhaps there will be some std
> libraries
> of useful directives (wouldn't that be a good problem to have?!)
>
> Wasn't clear when I did a quick skim of the current code whether we can
> handle that yet, but it would be something to consider/plan for.
>
>
> (4) need to think about default for when masterview admin controller is
> exposed in app (always? only in development unless app's config turns it
> on
> for production?)
>
> And need to understand/document how an app programmer would restrict
> access
> to the mv admin controller in their app if they want to do that.  (which I
> think they probably should be doing in a production site)  My other top
> to-do for migrating some existing sites on rails besides this template
> stuff
> is establishing my user authentication/authorization infrastructure, so I
> hit this issue very soon.
>
> ~ 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/2aacd4b8/attachment.htm 

From djlewis at acm.org  Wed Jun  7 17:03:40 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 7 Jun 2006 14:03:40 -0700
Subject: [Masterview-devel] A few observations from MV usage
In-Reply-To: <19cda190606071228w6c204e3aw808cbf0086a9d0a@mail.gmail.com>
Message-ID: <20060607210345.OYAX12581.fed1rmmtao02.cox.net@DLI92cx797990>

response interspersed below.
 
~ 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 12:28 PM
To: masterview-devel at rubyforge.org
Subject: Re: [Masterview-devel] A few observations from MV usage


1) agreed, generated comment is only for erb files as it currently is. (Are
we ok not putting anything in other files??, should we think about doing
that? For now let's keep it simple, but someday we may want to have
different comment types for different types of files, so users know this is
generated. 
 
I thought about allowing diff comments for diff types but files, but then
decided that's ridiculous overkill.  We can invent that in the future if
needed.
 
 ...

4) I thought about doing a variety of schemes for user authentication, even
something as simple as having a set user password and only doing it in
development, etc. However I went with the simplest approach at first
figuring there are many ways to skin this. 

I had used the engines version of RBAC for a project and that worked out
pretty nice because it was pretty unintrusive. Bolt on authentication is
nice. However I didn't want to put any big dependencies on things since the
current plugin mechanism doesn't have a nice way to do dependencies (that I
am aware of) so users have to manually install prerequisites or one has to
bundle them in (which is generally not the best way). I think eventually
plugins will move toward something more like gems, but the gems system needs
to be made easier to use without root access (for shared servers). 
 
I don't have an answer for this yet, just want us to be thinking about it.
And no, we certainly shouldn't have any big dependencies in the core MV
plugin.  
 
Maybe someday there's MV add-ons if it made sense to standardize hookup with
something widely used, but it doesn't seem that area of the rails world has
settled into anything standard yet.  There are several diff auth schemes out
there, including really simple roll-your-own, and no precedent in place for
standardized protocol that we could leverage to auto-detect whether/how to
filter access.
 
FWIW I'll likely to end up doing something with Bruce Perens' ModelSecurity
for my own app infrastructure, after incomplete initial research into
available options.  Or possibly ActiveRBAC - not sure.  I want to be able to
start with something relatively simple, but with notions of roles and
permissions in the foundation so I can scale in the future to more
sophisticated schemes as needed.
 
http://perens.com/FreeSoftware/ModelSecurity/Tutorial.html
 
~ Deb
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060607/bf21741e/attachment.htm 

From djlewis at acm.org  Wed Jun  7 17:03:40 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 7 Jun 2006 14:03:40 -0700
Subject: [Masterview-devel] On default config values for dir
	locations(templates, directives)
In-Reply-To: <19cda190606071211g6f22cf4m7fe19e64e33758a4@mail.gmail.com>
Message-ID: <20060607210355.OYFK12581.fed1rmmtao02.cox.net@DLI92cx797990>

RE; default template src dir
 
>> if we wanted to so something like app/masterview in the meantime we could

>> since that has the advantage of being the same subdirectory depth as
app/views.

I think I like do like that better than lurking down in
app/views/masterview, so I'll go ahead and make that change to the default
config.
 
>> think about ways where they could reuse the custom directives across
apps...
>> want to make sure to have a way for directives to be loaded in other
directories 
 
Yep, and in fact I'll probably do exactly that.  Just append any ol' path
name you want to config.directive_paths in your settings.rb or env config.
 
But it would be nice to have a convenient "if you have the conventional
directives dir in your rails app we'll load it automagically".  I'll put in
app/masterview/directives for now and test-drive it with something to make
sure it "feels good" in the overall organization of my app.
 
still contemplating your caps plan B fallback for import/gen directives -
it's a bit grating, I do prefer "{template_path}" over "TEMPLATE_PATH".
Making the notation itself configurable seems like a bad idea - the basic
notation should be simple and standard.
 
Maybe TEMPLATE_SHORT_PATH or TEMPLATE_BASE_PATH rather than SHORTNAME?
Trying to find the right name to fit with "standard" file system terminology
and the existing File protocol in ruby.  File::basename get you just the
base file name w/out path or extension, so maybe "base path" captures the
no-ext intent?
 
Don't like CONTROLLER and ACTION - that may happen to be what those elements
of a path represent, but it's not necessarily so.  And there's potentially
diffs in url path fragments vs. controller impl structures.  So I think the
notions we allow to be expressed in the keywords we support should be
restricted just to the concepts of the template file living in some relative
scope of the file system structure - thus just name, extension,
full/relative paths.
 
>> Typically keyword expansion is only needed on generate, gen_* and import*
commands 
>> so by having it default to on only for those it doesn't affect most other
directives.
 
Take a stronger point of view: these *are* the only directives that this
applies to.  Let's don't open it to other directives until there's a clear
need and an understanding of what might be appropriate.  [don't invent
overly general mechanism until we need it - YAGNI]
 
~ Deb
 
YAGNI:
http://xp.c2.com/YouArentGonnaNeedIt.html
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060607/69013d71/attachment-0001.htm 

From djlewis at acm.org  Wed Jun  7 17:03:40 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 7 Jun 2006 14:03:40 -0700
Subject: [Masterview-devel]
	branches/preview-template-watcher-refactoring-20060607
In-Reply-To: <20060607201125.6ADCC3CC20B@rubyforge.org>
Message-ID: <20060607210405.OYLE12581.fed1rmmtao02.cox.net@DLI92cx797990>

Jeff - look this over at some point, I want to pull out a few little
utilities that I'm tripping over in various places as I hunt down and fix
places where app/views assumptions are lurking.  There's a little readme
with some notes plus a couple files I'm tinkering with
 
Needs the new Config stuff before committed, there's some diffs in constant
names and semantics, but you'll get the general idea
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060607/ac1125f9/attachment.htm 

From jeff.barczewski at gmail.com  Wed Jun  7 17:42:21 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 7 Jun 2006 16:42:21 -0500
Subject: [Masterview-devel] A few observations from MV usage
In-Reply-To: <20060607210345.OYAX12581.fed1rmmtao02.cox.net@DLI92cx797990>
References: <19cda190606071228w6c204e3aw808cbf0086a9d0a@mail.gmail.com>
	<20060607210345.OYAX12581.fed1rmmtao02.cox.net@DLI92cx797990>
Message-ID: <19cda190606071442w60cfa09u4ef3591d9d35db02@mail.gmail.com>

Mine too.

On 6/7/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  response interspersed below.
>
> ~ 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 12:28 PM
> *To:* masterview-devel at rubyforge.org
> *Subject:* Re: [Masterview-devel] A few observations from MV usage
>
>  1) agreed, generated comment is only for erb files as it currently is.
> (Are we ok not putting anything in other files??, should we think about
> doing that? For now let's keep it simple, but someday we may want to have
> different comment types for different types of files, so users know this is
> generated.
>
> I thought about allowing diff comments for diff types but files, but then
> decided that's ridiculous overkill.  We can invent that in the future if
> needed.
>


Absolutely. Let's keep it simple, it will get complicated enough on its own.
We can add when needed.


 ...
>
> 4) I thought about doing a variety of schemes for user authentication,
> even something as simple as having a set user password and only doing it in
> development, etc. However I went with the simplest approach at first
> figuring there are many ways to skin this.
>
> I had used the engines version of RBAC for a project and that worked out
> pretty nice because it was pretty unintrusive. Bolt on authentication is
> nice. However I didn't want to put any big dependencies on things since the
> current plugin mechanism doesn't have a nice way to do dependencies (that I
> am aware of) so users have to manually install prerequisites or one has to
> bundle them in (which is generally not the best way). I think eventually
> plugins will move toward something more like gems, but the gems system needs
> to be made easier to use without root access (for shared servers).
>
> I don't have an answer for this yet, just want us to be thinking about
> it.  And no, we certainly shouldn't have any big dependencies in the core MV
> plugin.
>
> Maybe someday there's MV add-ons if it made sense to standardize hookup
> with something widely used, but it doesn't seem that area of the rails world
> has settled into anything standard yet.  There are several diff auth
> schemes out there, including really simple roll-your-own, and no precedent
> in place for standardized protocol that we could leverage to auto-detect
> whether/how to filter access.
>
> FWIW I'll likely to end up doing something with Bruce Perens'
> ModelSecurity for my own app infrastructure, after incomplete initial
> research into available options.  Or possibly ActiveRBAC - not sure.  I want
> to be able to start with something relatively simple, but with notions of
> roles and permissions in the foundation so I can scale in the future to more
> sophisticated schemes as needed.
>
> http://perens.com/FreeSoftware/ModelSecurity/Tutorial.html
>
>


Thanks, I'll check Bruce's stuff out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060607/8c8fcdb9/attachment.htm 

From jeff.barczewski at gmail.com  Wed Jun  7 18:07:09 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 7 Jun 2006 17:07:09 -0500
Subject: [Masterview-devel] On default config values for dir
	locations(templates, directives)
In-Reply-To: <20060607210355.OYFK12581.fed1rmmtao02.cox.net@DLI92cx797990>
References: <19cda190606071211g6f22cf4m7fe19e64e33758a4@mail.gmail.com>
	<20060607210355.OYFK12581.fed1rmmtao02.cox.net@DLI92cx797990>
Message-ID: <19cda190606071507h33cb669ag42a984e4ad0f4e71@mail.gmail.com>

On 6/7/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  RE; default template src dir
>
> >> if we wanted to so something like app/masterview in the meantime we
> could
> >> since that has the advantage of being the same subdirectory depth as
> app/views.
> I think I like do like that better than lurking down in
> app/views/masterview, so I'll go ahead and make that change to the default
> config.
>

ok. We just need to make sure the generator and watcher are putting things
in the right place too. Might search for 'app/views' across the tree to see
if it was hard coded anywhere else. Shame on me if I didn't use a constant
everywhere. Of course that will all be centralized soon when I get the
centralized IO stuff in.


>> think about ways where they could reuse the custom directives across
> apps...
> >> want to make sure to have a way for directives to be loaded in other
> directories
>
> Yep, and in fact I'll probably do exactly that.  Just append any ol' path
> name you want to config.directive_paths in your settings.rb or env config.
>
> But it would be nice to have a convenient "if you have the conventional
> directives dir in your rails app we'll load it automagically".  I'll put in
> app/masterview/directives for now and test-drive it with something to make
> sure it "feels good" in the overall organization of my app.
>
> still contemplating your caps plan B fallback for import/gen directives -
> it's a bit grating, I do prefer "{template_path}" over "TEMPLATE_PATH".
> Making the notation itself configurable seems like a bad idea - the basic
> notation should be simple and standard.
>

I see your point. If you like {template_path} better then many other people
will too, so I am ok with that. I will have to test but I don't think it
will be any problem to use the {} syntax around the keywords.


Maybe TEMPLATE_SHORT_PATH or TEMPLATE_BASE_PATH rather than SHORTNAME?
> Trying to find the right name to fit with "standard" file system terminology
> and the existing File protocol in ruby.  File::basename get you just the
> base file name w/out path or extension, so maybe "base path" captures the
> no-ext intent?
>

I had a hard time figuring out what to call that. I basically want the
relative pathname to the root (app/masterview) without extension. I couldn't
think of a good name for it. Looking at the ruby util Pathname it has a
function that is close 'relative_path_from'. So {template_path_no_ext} or
one of the other ones you mentiond.

I took your advice on the path stuff by not worrying about native file paths
and only working with forward slash paths. By doing this Pathname does much
of what I needed and the rest was easily added in. So I use extended
Pathname for path operations and have the consolidated io to handle the
details about where to read and write the files from (file system with this
base path, db, hash, ...)

I think it is going to turn out nice.


Don't like CONTROLLER and ACTION - that may happen to be what those elements
> of a path represent, but it's not necessarily so.  And there's potentially
> diffs in url path fragments vs. controller impl structures.  So I think the
> notions we allow to be expressed in the keywords we support should be
> restricted just to the concepts of the template file living in some relative
> scope of the file system structure - thus just name, extension,
> full/relative paths.
>


Yeah I didn't like that much either, however it is what the standard rails
view layout looks like so I was trying to talk in terms that users would
understand. You are right in that obviously people don't have to use that
convention and can have more levels or other path arrangements.

So maybe something like

{template_full_path}
{template_path}
{template_path_no_ext} or *
{parent}
{filename}
{basename}
{extension}


>> Typically keyword expansion is only needed on generate, gen_* and import*
> commands
> >> so by having it default to on only for those it doesn't affect most
> other directives.
>
> Take a stronger point of view: these *are* the only directives that this
> applies to.  Let's don't open it to other directives until there's a clear
> need and an understanding of what might be appropriate.  [don't invent
> overly general mechanism until we need it - YAGNI]
>


You are probably right. Simpler is better.

Thanks for the continued refinement and input! It will save much confusion
down the road.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060607/46b4521f/attachment-0001.htm 

From jeff.barczewski at gmail.com  Wed Jun  7 19:07:59 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 7 Jun 2006 18:07:59 -0500
Subject: [Masterview-devel]
	branches/preview-template-watcher-refactoring-20060607
In-Reply-To: <20060607210405.OYLE12581.fed1rmmtao02.cox.net@DLI92cx797990>
References: <20060607201125.6ADCC3CC20B@rubyforge.org>
	<20060607210405.OYLE12581.fed1rmmtao02.cox.net@DLI92cx797990>
Message-ID: <19cda190606071607n245c0031sbbeeb9e45c43fa89@mail.gmail.com>

Yeah I like the idea of cleaning this up and exposing with a block. You are
correct this needs to be as simple as possible to allow it to be used from
other frameworks. If you are in this code maybe the method name
parse_modified_templates sounds better than parse_changed_templates?

One question you had in the rails_init.rb regarding whether the server
setting belonged in client app settings. I guess we could put this in client
settings with a default of what we have here, or depending on how these
blocks come out of the refactoring... might just see.

Just so you know, the $PROGRAM_NAME check was needed so that the auto parser
was run only on script/server, or *cgi launch, and not all the other
commands that rails has like script/console script/generate, ...  Before I
had this the parser was running for everything because the plugin/init.rb
gets called before any of those things run.

I like what you have started here.


On 6/7/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  Jeff - look this over at some point, I want to pull out a few little
> utilities that I'm tripping over in various places as I hunt down and fix
> places where app/views assumptions are lurking.  There's a little readme
> with some notes plus a couple files I'm tinkering with
>
> Needs the new Config stuff before committed, there's some diffs in
> constant names and semantics, but you'll get the general idea
>
> ~ 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/b8d4d99e/attachment.htm 

From djlewis at acm.org  Wed Jun  7 19:45:22 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 7 Jun 2006 16:45:22 -0700
Subject: [Masterview-devel] On default config values for
	dirlocations(templates, directives)
In-Reply-To: <19cda190606071507h33cb669ag42a984e4ad0f4e71@mail.gmail.com>
Message-ID: <20060607234525.SISI19284.fed1rmmtao01.cox.net@DLI92cx797990>

Jeff - ok, I like this last round: all-caps is too much like SHOUTING_AT_ME,
simple bracket w/out the # is recognizably something a bit different that
usual by still close enough to ruby string subst. notation to be
comfortable, I think.  Latter also argues for following ruby var naming
convection (snake_case)
 
So I like:
 
{template_full_path}
{template_path}
{template_path_no_ext} or *

where {template_path} is rel path within template src dir.  
 
And at this point I'd drop "*" completely.
mv:generate="{template_path}.xxx" generates .xxx extension,
mv:generate="{template_path}" with no extension picks up default output file
extension (.rhtml; could be made a config setting if necessary)
 
That last _no_ext guy is still awk.  What if we just take the point of view
that neither {template_path} or {template_full_path} include file ext and be
done with it.  Support {extension} to allow reference the template's
extension if needed (tho I don't know how useful that is)
 
Rather than {parent}, maybe {template_dir_path}, which is '' for template
file in the root templates src dir and 'foo/bar' for nested guys.
 
Not sure we need the following, maybe defer and just activate if we get
request?

{filename}
{basename}

I don't think we need to bring controller/action into this - it's a notion
from a diff space (dispatch routing, and even there there's issue between
url routing paths and controller impl hieriarchies).  We just need to deal
with file paths here, I think.
 
So... I like this.  It's simple and it's pretty clear to a reader, and it
handles the cases I've come up with so far.
 
??maybe we need escape convention someday to allow generating a file name
containing squigglies, but I wouldn't worry about it until the problem
arises.
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060607/ab732fb7/attachment.htm 

From jeff.barczewski at gmail.com  Thu Jun  8 06:06:49 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Thu, 8 Jun 2006 05:06:49 -0500
Subject: [Masterview-devel] On default config values for
	dirlocations(templates, directives)
In-Reply-To: <20060607234525.SISI19284.fed1rmmtao01.cox.net@DLI92cx797990>
References: <19cda190606071507h33cb669ag42a984e4ad0f4e71@mail.gmail.com>
	<20060607234525.SISI19284.fed1rmmtao01.cox.net@DLI92cx797990>
Message-ID: <19cda190606080306i6b8429b3qbe4dd23cc0de7da@mail.gmail.com>

Alright, I think we are getting some where :-)

Taking into account your email, how about this?

{template_full_path}
{template_path} (picks up default extension)
{extension}
{template_dir_path}
{template_basename} (I need this one)

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060608/70b26a9b/attachment.htm 

From djlewis at acm.org  Thu Jun  8 08:44:29 2006
From: djlewis at acm.org (Deb Lewis)
Date: Thu, 8 Jun 2006 05:44:29 -0700
Subject: [Masterview-devel] On default config values for
	dirlocations(templates, directives)
In-Reply-To: <19cda190606080306i6b8429b3qbe4dd23cc0de7da@mail.gmail.com>
Message-ID: <20060608124433.YRCM15767.fed1rmmtao04.cox.net@DLI92cx797990>

Yes, I think that's a good set.  Go with it!
 
Just to clarify: template_path and template_full_path are the
dir/file-base-name path components, but don't include extension, right?
Then it's consistent, and if needed ref to template's own extension is
hardcoded or used {extension}.
 
So test understanding - mv:generate target mapping examples in template
"foo/bar/testpage.html":
 
    mv:generate="{template_path}" 
        -> output file "foo/bar/testpage.rhtml"
    mv:generate="{template_path}.xxx 
        -> output file "foo/bar/testpage.xxx"
    mv:generate="somewhere/different/{template_basename}" 
       -> output file "somewhere/different/testpage.rhtml"
 
mv:generate="{template_dir_path}/{template_basename}-subsectionX.{extension}
" 
        -> output file "foo/bar/testpage-subsection.html"
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Thursday, June 08, 2006 3:07 AM
To: djlewis at acm.org; masterview-devel at rubyforge.org
Subject: Re: [Masterview-devel] On default config values for
dirlocations(templates, directives)


Alright, I think we are getting some where :-)

Taking into account your email, how about this?

{template_full_path}
{template_path} (picks up default extension)
{extension}
{template_dir_path}
{template_basename} (I need this one) 

Jeff


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060608/696a6473/attachment.htm 

From jeff.barczewski at gmail.com  Thu Jun  8 11:49:56 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Thu, 8 Jun 2006 10:49:56 -0500
Subject: [Masterview-devel] On default config values for
	dirlocations(templates, directives)
In-Reply-To: <20060608124433.YRCM15767.fed1rmmtao04.cox.net@DLI92cx797990>
References: <19cda190606080306i6b8429b3qbe4dd23cc0de7da@mail.gmail.com>
	<20060608124433.YRCM15767.fed1rmmtao04.cox.net@DLI92cx797990>
Message-ID: <19cda190606080849l299162e3xc390c2ee31327043@mail.gmail.com>

Yes, and similar to your example I couldn't see a need for the template full
path (in fact I don't necessarily have access to it, since you might be
rendering to a hash or db), so I took out the template_full_path one.

All the others work as you indicated.

On 6/8/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  Yes, I think that's a good set.  Go with it!
>
> Just to clarify: template_path and template_full_path are the
> dir/file-base-name path components, but don't include extension, right?
> Then it's consistent, and if needed ref to template's own extension is
> hardcoded or used {extension}.
>
> So test understanding - mv:generate target mapping examples in
> template "foo/bar/testpage.html":
>
>     mv:generate="{template_path}"
>         -> output file "foo/bar/testpage.rhtml"
>     mv:generate="{template_path}.xxx
>         -> output file "foo/bar/testpage.xxx"
>     mv:generate="somewhere/different/{template_basename}"
>        -> output file "somewhere/different/testpage.rhtml"
>
> mv:generate="{template_dir_path}/{template_basename}-subsectionX.{extension}"
>
>         -> output file "foo/bar/testpage-subsection.html"
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060608/56f00971/attachment-0001.htm 

From jeff.barczewski at gmail.com  Fri Jun  9 10:04:06 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 9 Jun 2006 09:04:06 -0500
Subject: [Masterview-devel] I am in the final stages of the consolidated io
	refactoring
Message-ID: <19cda190606090704o46f44593l63bb6bfe743d7d77@mail.gmail.com>

I am in the final stages of consolidated io refactoring which I am trying to
finish as soon as possible.

So I just wanted to mention where I was at. These changes will consolidate
the file handling operations and clean things up considerably. That being
said things like ParserHelper and anything that used to rely on files will
not be using the new IO and thus there will be many changes to those files.

I will get this finished as soon as possible but just wanted to give you a
heads up in case you were activly working on files that manipulate files,
that there may be conflicts once it is all said and done. So if you could
minimize work around those routines until after I am finished. I will have
this done asap.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060609/e0079753/attachment.htm 

From djlewis at acm.org  Fri Jun  9 15:20:14 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 9 Jun 2006 12:20:14 -0700
Subject: [Masterview-devel] I am in the final stages of the consolidated
	iorefactoring
In-Reply-To: <19cda190606090704o46f44593l63bb6bfe743d7d77@mail.gmail.com>
Message-ID: <20060609192017.NNAB5347.fed1rmmtao05.cox.net@DLI92cx797990>

Jeff  - sounds good, thx for the update. I'll be doing another pass on the
init/config this afternoon to incorporate our last round of discussions and
some some additional work on the docs.
 
I'm minimizing the other files I have to touch right now until the config
stuff is settled and integrated to the trunk, so anything else I need to
change I'll happily hold onto and then merge in after your file handling
work is done.   Shouldn't be a problem - version control and diff compares
make this all quite tractable.
 
~ Deb


  _____  

From: masterview-devel-bounces at rubyforge.org
[mailto:masterview-devel-bounces at rubyforge.org] On Behalf Of Jeff Barczewski
Sent: Friday, June 09, 2006 7:04 AM
To: masterview-devel at rubyforge.org
Subject: [Masterview-devel] I am in the final stages of the consolidated
iorefactoring


I am in the final stages of consolidated io refactoring which I am trying to
finish as soon as possible. 

So I just wanted to mention where I was at. These changes will consolidate
the file handling operations and clean things up considerably. That being
said things like ParserHelper and anything that used to rely on files will
not be using the new IO and thus there will be many changes to those files. 

I will get this finished as soon as possible but just wanted to give you a
heads up in case you were activly working on files that manipulate files,
that there may be conflicts once it is all said and done. So if you could
minimize work around those routines until after I am finished. I will have
this done asap. 

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060609/2c8c38d9/attachment.htm 

From jeff.barczewski at gmail.com  Mon Jun 12 11:01:12 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 12 Jun 2006 10:01:12 -0500
Subject: [Masterview-devel] Consolidated IO almost there
Message-ID: <19cda190606120801h3050a9c8of63a687f9b518290@mail.gmail.com>

After I started integrating the new consolidated io I found that it wasn't
going to work as I envisioned, so I refactored it once more and it came out
much cleaner than before. Not perfect but much lighter and cleaner. I was
able to trim the classes down of some of the extra features that most likely
wouldn't be needed and they got much simpler.

Anyway, I still have a little bit of rework to do and more testing, but it
is coming along nicely.

I put a branch jjb-refactored-io up with my current work.

I really like how it is shaping up. It allows for templates to exist
anywhere (file, string hash, active record (not implemnted yet), ...) and
the same for writing files.

We also can apply any number of filters to the reading and writing for
things like tidy, escaping erb, caching, logging, ...

This mechanism will also allow us to write direct to erb cache pretty
easily.

I hope to have things wrapped up in a day or two, sorry for the delay. The
refactoring took longer than expected.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060612/56a1437b/attachment.htm 

From djlewis at acm.org  Mon Jun 12 12:00:19 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 12 Jun 2006 09:00:19 -0700
Subject: [Masterview-devel] Consolidated IO almost there
In-Reply-To: <19cda190606120801h3050a9c8of63a687f9b518290@mail.gmail.com>
Message-ID: <20060612160018.XFDR27967.fed1rmmtao08.cox.net@DLI92cx797990>

Jeff - sounds good, thx for the update.
 
>> sorry for the delay. The refactoring took longer than expected
 
Hey, it takes as long as it takes - better to get the fundamentals right in
the first place (go slow now so we can go fast later, as the XP'ers say)
 
I did yet another pass over the config/initializer stuff over the weekend
and have been whacking on providing docs and samples (speaking of taking
longer than expected...).  Settling into something that looks pretty
consistent now when you try to describe the settings to a user, so that's a
good thing.  Also patched up internals so that unless you need to do some
special config setup, std usage is back to simple "require 'masterview'" -
that's all init.rb needs for std rails app.
 
Have gotten sidetracked this morning deciphering the two logging packages in
order to add a config setting to allow initializing the logging level, so
need to test all the variations of that.  Hope to get through a full
build/deploy test in all the various configurations today.
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060612/e6f630b3/attachment.htm 

From djlewis at acm.org  Mon Jun 12 15:49:10 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 12 Jun 2006 12:49:10 -0700
Subject: [Masterview-devel] Latest round of changes in initializer mechanism
Message-ID: <20060612194909.MFMC12581.fed1rmmtao02.cox.net@DLI92cx797990>

Redid all directory path refs to be relative to the app root (no more
cleverness about assuming app/views context w/in rails app for specifying
template dirs): config_dir_path, template_src_dir_path, and
template_dst_dir_path are relative paths from config.root_path.  If you need
to specify location outside the app's root directory scope, there's abs-path
setter methods.

Default template src path changed from app/views/masterview to
app/masterview - pulls up a level, now a parallel dir structure alongside
the default target dir of app/views.

Add logger config settings: config.logger to configure log4r or std ruby
logger; config.log_level to specify log level.  This turns out to be nice,
makes it easy to configure/disable debug logging.  Tested with both log4r
and logger to make sure this works for both flavors.

[not quite sure yet about default loc for auto-adding app directives to the
load path - need to test whether something like lib/master/view/directives
or lib/mv-directives works as desired; not sure that
app/masterview/directives is right place, don't want directives code muddled
under template src dir - would be ok if we made app/masterview/templates the
default src dir, but then dir levels aren't symmetric with target app/views]

doc/configuration.html updated; examples of settings files updated to
provided commented-out template with all the options.  [still to do:
reorganize top-level index.html to link to config doc]

Unit tests for config settings updated; new code tested in rails app in my
working copy.  Still to do: test clean install as rails plugin and via gem
into new, empty rails app to do full life-cycle test.

In order to activate in the main integration, I need to submit updated
init.rb (mostly comment fixes for the rdoc) and lib/masterview.rb (changes
the way things are done to hook in the initializer).  There'll also be
README and RELEASE_NOTES updates, of course.

~ Deb



From jeff.barczewski at gmail.com  Mon Jun 12 18:31:10 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 12 Jun 2006 17:31:10 -0500
Subject: [Masterview-devel] Consolidated IO almost there
In-Reply-To: <20060612160018.XFDR27967.fed1rmmtao08.cox.net@DLI92cx797990>
References: <19cda190606120801h3050a9c8of63a687f9b518290@mail.gmail.com>
	<20060612160018.XFDR27967.fed1rmmtao08.cox.net@DLI92cx797990>
Message-ID: <19cda190606121531l63e6d4cpf12f6bd2ad6d6771@mail.gmail.com>

Sounds wonderful! I look forward to seeing what you did.

On 6/12/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  Jeff - sounds good, thx for the update.
>
> >> sorry for the delay. The refactoring took longer than expected
>
> Hey, it takes as long as it takes - better to get the fundamentals right
> in the first place (go slow now so we can go fast later, as the XP'ers say)
>
> I did yet another pass over the config/initializer stuff over the
> weekend and have been whacking on providing docs and samples (speaking of
> taking longer than expected...).  Settling into something that looks pretty
> consistent now when you try to describe the settings to a user, so that's a
> good thing.  Also patched up internals so that unless you need to do some
> special config setup, std usage is back to simple "require 'masterview'" -
> that's all init.rb needs for std rails app.
>
> Have gotten sidetracked this morning deciphering the two logging packages
> in order to add a config setting to allow initializing the logging level, so
> need to test all the variations of that.  Hope to get through a full
> build/deploy test in all the various configurations today.
>
> ~ 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/20060612/23be9884/attachment.htm 

From djlewis at acm.org  Mon Jun 12 21:03:31 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 12 Jun 2006 18:03:31 -0700
Subject: [Masterview-devel] Test case: analyzer breaks on template that
	parser handles
Message-ID: <20060613010332.PLWX18458.fed1rmmtao10.cox.net@DLI92cx797990>

Configuration: new, empty rails app w/ masterview installed in
vendor/plugins from my working copy, with new initializer hooked up, but no
changes to parser.rb or analyzer.rb from current trunk.  Three lines changed
in template_spec.rb to convert old MasterView::TemplateSrcRelativePath const
refs and hardwired 'app/views' to new TemplateSrcDirPath constant.

Create a single very simple template in app/masterview templates dir and
verify that MV detects and parses it into app/views.  Attached.

Go to masterview Admin controller -> list page does a TemplateSpec.scan on
the templates src dir, breaks in Analyzer.end_element with nil value for
stack.last at line 196 (if @depth == @stack.last.depth)

It's dying on the <title> element the document <head>, according to trace
dumps that I added.

Not going to pursue this further right this instant, but this doesn't look
like a Win32 platform issue.  Probably just needs extra stack.empty? check
per below (just adding that did fix this simple case).  Anyway, explains why
the admin controller breaks when I try to run it, my templates all have
<title> elements in their headers.

    if ! @stack.empty? && @depth == @stack.last.depth

p.s. if you activate the admin controller in a new empty rails app it's
really bogus looking - assumes stylesheets that aren't there.  I think these
are guys that get dropped in from running your other generator, which at
this point I haven't done in this new app and it's a legit use case that one
might not do so.  A to-do for the cleanup list, not critical for the moment.

~ Deb

MasterView::Analyzer.start_document

MasterView::Analyzer.start_element
...uri: http://www.w3.org/1999/xhtml
...<html>
...attributes: lang, xml:lang, xmlns
... at depth=0
... at stack=[0 entries] on entry
... at stack=[0 entries] after processing entry

MasterView::Analyzer.start_element
...<head>
... at depth=1
... at stack=[0 entries] on entry
... at stack=[0 entries] after processing entry

MasterView::Analyzer.start_element
...<title>
... at depth=2
... at stack=[0 entries] on entry
... at stack=[0 entries] after processing entry

MasterView::Analyzer.end_element
...</title>
...qname=title
... at stack=[0 entries] on entry

ERROR:
You have a nil object when you didn't expect it!
The error occured while evaluating nil.depth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060612/bd8a81d2/attachment-0001.html 

From jeff.barczewski at gmail.com  Tue Jun 13 20:22:09 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Tue, 13 Jun 2006 19:22:09 -0500
Subject: [Masterview-devel] Test case: analyzer breaks on template that
	parser handles
In-Reply-To: <20060613010332.PLWX18458.fed1rmmtao10.cox.net@DLI92cx797990>
References: <20060613010332.PLWX18458.fed1rmmtao10.cox.net@DLI92cx797990>
Message-ID: <19cda190606131722x29888080p4b00f8c4699d27a6@mail.gmail.com>

That's a good point about the admin page not looking good without the
stylesheets, we should account for the fact that not everyone is going to
run the generator. Probably include a different stylesheet or embed some
minor style.

I can take a look at the template scan, I have mainly tested on files that
came out of the generator so maybe on something simpler that doesn't have as
many mv:generates, maybe we are getting into an empty list situation that we
weren't with the generator created files.



On 6/12/06, Deb Lewis <djlewis at acm.org> wrote:
>
> Configuration: new, empty rails app w/ masterview installed in
> vendor/plugins from my working copy, with new initializer hooked up, but
> no
> changes to parser.rb or analyzer.rb from current trunk.  Three lines
> changed
> in template_spec.rb to convert old MasterView::TemplateSrcRelativePath
> const
> refs and hardwired 'app/views' to new TemplateSrcDirPath constant.
>
> Create a single very simple template in app/masterview templates dir and
> verify that MV detects and parses it into app/views.  Attached.
>
> Go to masterview Admin controller -> list page does a TemplateSpec.scan on
> the templates src dir, breaks in Analyzer.end_element with nil value for
> stack.last at line 196 (if @depth == @stack.last.depth)
>
> It's dying on the <title> element the document <head>, according to trace
> dumps that I added.
>
> Not going to pursue this further right this instant, but this doesn't look
> like a Win32 platform issue.  Probably just needs extra stack.empty? check
> per below (just adding that did fix this simple case).  Anyway, explains
> why
> the admin controller breaks when I try to run it, my templates all have
> <title> elements in their headers.
>
>     if ! @stack.empty? && @depth == @stack.last.depth
>
> p.s. if you activate the admin controller in a new empty rails app it's
> really bogus looking - assumes stylesheets that aren't there.  I think
> these
> are guys that get dropped in from running your other generator, which at
> this point I haven't done in this new app and it's a legit use case that
> one
> might not do so.  A to-do for the cleanup list, not critical for the
> moment.
>
> ~ Deb
>
> MasterView::Analyzer.start_document
>
> MasterView::Analyzer.start_element
> ...uri: http://www.w3.org/1999/xhtml
> ...<html>
> ...attributes: lang, xml:lang, xmlns
> ... at depth=0
> ... at stack=[0 entries] on entry
> ... at stack=[0 entries] after processing entry
>
> MasterView::Analyzer.start_element
> ...<head>
> ... at depth=1
> ... at stack=[0 entries] on entry
> ... at stack=[0 entries] after processing entry
>
> MasterView::Analyzer.start_element
> ...<title>
> ... at depth=2
> ... at stack=[0 entries] on entry
> ... at stack=[0 entries] after processing entry
>
> MasterView::Analyzer.end_element
> ...</title>
> ...qname=title
> ... at stack=[0 entries] on entry
>
> ERROR:
> You have a nil object when you didn't expect it!
> The error occured while evaluating nil.depth
>
>
> _______________________________________________
> 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/20060613/cd195832/attachment.htm 

From djlewis at acm.org  Tue Jun 13 21:08:52 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 13 Jun 2006 18:08:52 -0700
Subject: [Masterview-devel] Test case: analyzer breaks on template that
	parser handles
In-Reply-To: <19cda190606131722x29888080p4b00f8c4699d27a6@mail.gmail.com>
Message-ID: <20060614010851.YDVG554.fed1rmmtao11.cox.net@DLI92cx797990>

suggest we chase both of those problems (<title> parsing in analyzer, admin
controller stylesheets) after getting current round of code stuff settled
and integrated (your file i/o, my initializer stuff), then catch up on loose
ends and polish work items.  I'm starting to have trouble juggling changes
between various dev and test copies, would like to get things integrated
onto trunk before I accidently wipe out something useful.
 
[not trying to push you, just observing]
 
I starting running build tasks last night to test the various install
flavors, but got bogged down poking around the rake file exploring and then
hitting problem with building zip's for some of the packages (probably easy
to fix, likely just something diff about your system or *nix that I need to
update on my system).  Will try to get back into that tonight.
 
Rakefile change notes: there's a couple build tasks that need
doc/stylesheets/*.* added to their flie specs; some other tweaking on the
syntax check/LOC/mvparse of examples guys.  Nothing earthshaking.
 
If it's ok with you, I'd like to factor out the prereqs and installation
instructions section of the current docs into a separate
doc/installation.html and then beef up the instructions to better explain
the flavors of packages available and when to pick which.  I know on my
first install experience I gave up trying to figure out which of the
downloads to use and just grabbed the include-everything bundle.  Not a
problem for experience rail-ers, I think, but sort of befuddling to newbies.
 
My goal is for this stuff to *look* polished when a potential user arrives
to browse the docs, easy to figure out whether it runs on their system
(platform version, prereqs, etc), and really easy for someone new to rails
or mv to get going.  Doesn't matter how glorious the package is if people
thnk it looks half-baked or they can't get off the ground easily.
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Tuesday, June 13, 2006 5:22 PM
To: djlewis at acm.org; masterview-devel at rubyforge.org
Subject: Re: [Masterview-devel] Test case: analyzer breaks on template that
parser handles


That's a good point about the admin page not looking good without the
stylesheets, we should account for the fact that not everyone is going to
run the generator. Probably include a different stylesheet or embed some
minor style. 

I can take a look at the template scan, I have mainly tested on files that
came out of the generator so maybe on something simpler that doesn't have as
many mv:generates, maybe we are getting into an empty list situation that we
weren't with the generator created files. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060613/550b77b1/attachment.htm 

From djlewis at acm.org  Wed Jun 14 02:58:40 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 13 Jun 2006 23:58:40 -0700
Subject: [Masterview-devel] Quick question about package building
Message-ID: <20060614065838.CABG19317.fed1rmmtao03.cox.net@DLI92cx797990>

Jeff - save me some time if you have a quick answer, otherwise I'll google
about a bit more for clues.

Trying to run masterview_plugin:package which builds zip/tgz files breaks on
windows when the rake task tries to shell out to run tar, which ain't there
on win32.

I took a quick look at minitar per your commented-out entries in the
rakefile:

#require 'archive/tar/minitar'
#require 'zlib'

You know any more about minitar or what's needed to get it hooked into rake
for win32 tar'ing?  Couldn't find any obvious refs in first quick look in
the rake impl's and docs; only other google tip so far was "install cygwin"
[bah, i'd rather get my new suse linux dual boot loaded up with ruby at that
point and run builds on my backup machine]

~ Deb



From jeff.barczewski at gmail.com  Wed Jun 14 10:14:46 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 14 Jun 2006 09:14:46 -0500
Subject: [Masterview-devel] I have the consolidated io working pretty well,
	will upload as soon as I resolve any conflicts
Message-ID: <19cda190606140714n44534c37qc153541a6178e08b@mail.gmail.com>

I will try to upload the consolidated io changes today as soon as I resolve
any conflicts.

It is working well.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060614/28de543b/attachment.htm 

From jeff.barczewski at gmail.com  Wed Jun 14 12:26:25 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 14 Jun 2006 11:26:25 -0500
Subject: [Masterview-devel] Test case: analyzer breaks on template that
	parser handles
In-Reply-To: <20060614010851.YDVG554.fed1rmmtao11.cox.net@DLI92cx797990>
References: <19cda190606131722x29888080p4b00f8c4699d27a6@mail.gmail.com>
	<20060614010851.YDVG554.fed1rmmtao11.cox.net@DLI92cx797990>
Message-ID: <19cda190606140926q1662221cm9d6c666bc7e96269@mail.gmail.com>

Yes, I agree. I am trying to get the code released asap.

I fully agree about it looking polished, that makes a huge difference in
whether people will actually look into something.

On 6/13/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  suggest we chase both of those problems (<title> parsing in analyzer,
> admin controller stylesheets) after getting current round of code stuff
> settled and integrated (your file i/o, my initializer stuff), then catch up
> on loose ends and polish work items.  I'm starting to have trouble juggling
> changes between various dev and test copies, would like to get things
> integrated onto trunk before I accidently wipe out something useful.
>
> [not trying to push you, just observing]
>
> I starting running build tasks last night to test the various install
> flavors, but got bogged down poking around the rake file exploring and then
> hitting problem with building zip's for some of the packages (probably easy
> to fix, likely just something diff about your system or *nix that I need to
> update on my system).  Will try to get back into that tonight.
>
> Rakefile change notes: there's a couple build tasks that need
> doc/stylesheets/*.* added to their flie specs; some other tweaking on the
> syntax check/LOC/mvparse of examples guys.  Nothing earthshaking.
>
> If it's ok with you, I'd like to factor out the prereqs and installation
> instructions section of the current docs into a separate
> doc/installation.html and then beef up the instructions to better explain
> the flavors of packages available and when to pick which.  I know on my
> first install experience I gave up trying to figure out which of the
> downloads to use and just grabbed the include-everything bundle.  Not a
> problem for experience rail-ers, I think, but sort of befuddling to newbies.
>
> My goal is for this stuff to *look* polished when a potential user arrives
> to browse the docs, easy to figure out whether it runs on their system
> (platform version, prereqs, etc), and really easy for someone new to rails
> or mv to get going.  Doesn't matter how glorious the package is if people
> thnk it looks half-baked or they can't get off the ground easily.
>
> ~ Deb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060614/a3ece1de/attachment-0001.htm 

From jeff.barczewski at gmail.com  Wed Jun 14 12:33:28 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 14 Jun 2006 11:33:28 -0500
Subject: [Masterview-devel] Quick question about package building
In-Reply-To: <20060614065838.CABG19317.fed1rmmtao03.cox.net@DLI92cx797990>
References: <20060614065838.CABG19317.fed1rmmtao03.cox.net@DLI92cx797990>
Message-ID: <19cda190606140933r22944446k18c54e208207907c@mail.gmail.com>

I wish I knew more about minitar and such. I just started from what others
had done and it worked. I hadn't tried the build on win32 though. It is sad
that many of these tools aren't there.

Maybe we can use a different package to do the tar'ing, something that is
both *nix and win32 friendly?

On 6/14/06, Deb Lewis <djlewis at acm.org> wrote:
>
> Jeff - save me some time if you have a quick answer, otherwise I'll google
> about a bit more for clues.
>
> Trying to run masterview_plugin:package which builds zip/tgz files breaks
> on
> windows when the rake task tries to shell out to run tar, which ain't
> there
> on win32.
>
> I took a quick look at minitar per your commented-out entries in the
> rakefile:
>
> #require 'archive/tar/minitar'
> #require 'zlib'
>
> You know any more about minitar or what's needed to get it hooked into
> rake
> for win32 tar'ing?  Couldn't find any obvious refs in first quick look in
> the rake impl's and docs; only other google tip so far was "install
> cygwin"
> [bah, i'd rather get my new suse linux dual boot loaded up with ruby at
> that
> point and run builds on my backup machine]
>
> ~ 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/20060614/ab8f81e4/attachment.htm 

From djlewis at acm.org  Wed Jun 14 14:21:11 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 14 Jun 2006 11:21:11 -0700
Subject: [Masterview-devel] Quick question about package building
In-Reply-To: <19cda190606140933r22944446k18c54e208207907c@mail.gmail.com>
Message-ID: <20060614182109.DPAR5347.fed1rmmtao05.cox.net@DLI92cx797990>

Jeff - ok, don't worry about it, I'll chase at some point. For now, I can
build gem packages and that was what I mostly need in order to do some
additional install testing on the new initializer mechanisms.  You'll just
have to continue to be the one and only release-build guy for the moment.
 
RE: sad that Windows lacks tar, etc
 
IMHO [ha], MS should be deeply embarassed that despite decades of proven
value of unix command shells, Windows has... the brain-damaged DOS box.  At
the PDC last fall, they proudly announced they're finally going to address
this in Vista (but only if you buy VS or MSDN subscription, wasn't clear
that they intended to include the new shell scripting capability in the main
Vista product).  amazing.
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Wednesday, June 14, 2006 9:33 AM
To: djlewis at acm.org; masterview-devel at rubyforge.org
Subject: Re: [Masterview-devel] Quick question about package building


I wish I knew more about minitar and such. I just started from what others
had done and it worked. I hadn't tried the build on win32 though. It is sad
that many of these tools aren't there. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060614/235a3ba3/attachment.htm 

From jeff.barczewski at gmail.com  Wed Jun 14 15:57:37 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 14 Jun 2006 14:57:37 -0500
Subject: [Masterview-devel] Consolidated MasterView IO is commited,
	need to think about best way to configure it with initializer
Message-ID: <19cda190606141257x7fcdd5c6x62284bde339b8db9@mail.gmail.com>

I committed the MIO code and changes. I still need to update the initializer
and sample configs, but I wanted your input on the best way to configure
this.

Before we had a bunch of loose constants and this was starting to balloon.

With the new consolidated MasterView IO (MIO) I encapsulated things for each
src and dst.

Here is a sumamry of how MIO works

There is an open struct called MasterView::IOMgr  (short for manager)

One can set up any number of MIOTrees under this IOMgr (a MIOTree is a
source or destination for templates, erb, files, ...)

So typically we will have trees setup for templates, erb, and backup. This
corresponds to reading/writing template, reading/writing .rhtml,
reading/writing backups files.

These MIOTrees are designed to be portable, I have implemented a FileMIOTree
and a StringHashMIOTree. I have stubbed ActiveRecordMIOTree (for storing
templates in db), and I have a RailsErbCacheMIOTree which will be used to
write to the Rails ERB cache (bypassing the intermediate .rhtml file
generation).

IOMgr.template = FileMIOTree('app/masterview', '.html') # root_path,
default_extension for templates
IOMgr.erb = FileMIOTree('app/views', '.rhtml') # root_path,
default_extension for generated erb
IOMgr.backup = FileMIOTree('tmp/masterview') # root_path, default_extension
for backups, if nil then no backups will be created.

Similarly you can change to a string_hash mechanism (great for testing) by
simply doing
template_hash = {}
IOMgr.template = StringHashMIOTree(template_hash, '.html') # root_path,
default_extension for templates
erb_hash = {}
IOMgr.erb = StringHashMIOTree(erb_hash, '.rhtml') # root_path,
default_extension for generated erb
backup_hash = {}
IOMgr.backup = StringHashMIOTree(backup_hash) # root_path, default_extension
for backups, if nil then no backups will be created.
And to create a pseudo file simply
template_hash['foo/bar.html'] = 'my template html'
and it is available to be read.

Written files show up as new entries similarly.
assert erb_hash['cat/dog.rhtml']

In addition to that one can apply any number of filters to the objects that
are read/written. I have created TidyMIOFilter, EscapeErbMIOFilter, and
LoggingMIOFilter. First runs tidy on the template after reading it before
passing it on, next one escapes <%= %>, and last one logs reads and writes.
I stubbed out a CachingMIOFilter as well but is not implemented yet.

You can configure what filters will be applied to the underlying MIO objects
(which the MIOTree hands out). You can do this by provding a block to the
MIOTree when created. for instance.

IOMgr.template = FileMIOTree('app/masterview', '.html') do |mio|
  mio.apply_filter TidyMIOFilter
  mio.apply_filter LogggingMIOFilter
end

This plugs Tidy on top of FileMIO and then Logging on top of it, so Logging
will be hit first, then Tidy, then FileMIO. Each filter can do whatever it
wants to the content being passed through.

Since this is somewhat advanced and most users will simply want to turn on
or off ones we have provided and to ensure they are invoked in the proper
order, I provided a default block which you can toggle on and off the
standard filters with hash options.

IOMgr.template = FileMIOTree('app/masterview', '.html', :caching => true,
:tidy => true, :escape_erb => true, :logging => true)
So when this tree creates FileMIO objects it adds the appropriate filters
before giving back the object.
You would obtain one of these FileMIO object simply by doing

fileMIO = IOMgr.template.path('foo/bar.html')
with that MIO object you can easily read or write to it as well as check if
exist?, identical?(to output).
template = fileMIO.read
or
template = IOMgr.template.path('foo/bar.html').read

to write an erb we use
IOMgr.erb.path('foo/bar.rhtml').write(content)

So we have things nicely encapsulated for each tree( the root_path, the
default extension, caching, tidy, escape_erb, logging).

How do we bring this out to the user in an easy to configure manner??
Do we take this simple approach below, or do we need to somehow break this
out into separate constants again?
IOMgr.template = FileMIOTree('app/masterview', '.html', :caching => true,
:tidy => true, :escape_erb => true, :logging => true)

One of the only constants I didn't stick in the trees yet was the MasterView
Template pattern, but I could see it being set as a hash value too.

So Deb looking for some of your intutiveness here on making this easy for
users.

Then once we come up with an approach we can update the samples you created
and the documentation.

All in all, I think this is going to work out really well with this io
consolidation. Everything is handled centrally and we can easily switch from
one IO mechanism to another and extend however we see fit.

I am open to additional ideas and naming suggestions if you don't like my
terms MIOTree, MIO objects. I spent all my creativity on the code and didn't
have much left for naming :-)

I created several *mio_tests to exercise the functionality.

And if I hadn't mentioned before, a natural extension of this product is to
serve these templates out of a database so that one can keep all the moving
parts in the db (great for backups and security). One place to backup all
the things that are changing regularly. So that's why the
ActiveRecordMIOTree will exist.

We have discussed going direct to the rails ERB cache so I stubbed that out
as well.

It will be as simple as changing out the Tree type and providing enough
configue information to get it using the new location.

This also makes it great for testing now, since we can put stuff directly
into hash and not touch file system at all.

So when thinking about the configuration changes, think also about these
other possibilities, so when we turn on this functionality, the
configuration capabilities will be able to accomodate it. Most likely for
ActiveRecordMIOTree we will simply need a table or query, although it could
get more complicated with ability to save x old versions, etc. Most of the
time these things can be provided via a hash to keep our interface flexible
enough.

Let me know what you think, and how we should approach the configuration of
this new functionality.

Thanks,

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060614/a1ab8990/attachment.htm 

From djlewis at acm.org  Wed Jun 14 17:49:28 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 14 Jun 2006 14:49:28 -0700
Subject: [Masterview-devel] Consolidated MasterView IO is commited,
	need to think about best way to configure it with initializer
In-Reply-To: <19cda190606141257x7fcdd5c6x62284bde339b8db9@mail.gmail.com>
Message-ID: <20060614214928.PBEO5347.fed1rmmtao05.cox.net@DLI92cx797990>

Jeff - ok, lots of good stuff here for me to chew on!
 
Propose I take a first pass at things tonight to get the initializer changes
I've already got integrated into your new stuff, then we can take a second
pass once all the pieces are back together and figure out where we need to
work on naming, config-ability, etc.
 
I'll have a much better sense of how this all "feels" after going through
what you've done, but on first read of your description sounds very good.
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060614/2a2f9683/attachment-0001.htm 

From djlewis at acm.org  Thu Jun 15 05:33:30 2006
From: djlewis at acm.org (Deb Lewis)
Date: Thu, 15 Jun 2006 02:33:30 -0700
Subject: [Masterview-devel] Integration status
Message-ID: <20060615093328.DNIS19284.fed1rmmtao01.cox.net@DLI92cx797990>

I've gone through everything and have an almost-working system.  One unit
test case fails (involving templates and abs. paths).  I can run my rails
application and template parsing seems to be basically working.

mv:generate="{template_path}" generates my .rhtml now

glitch: mv:generate="{template_path}.css" produces foo.rhtml.css - so the
default output extension isn't being ignored when target specified ext.

~ Deb



From jeff.barczewski at gmail.com  Thu Jun 15 11:33:24 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Thu, 15 Jun 2006 10:33:24 -0500
Subject: [Masterview-devel] Integration status
In-Reply-To: <20060615093328.DNIS19284.fed1rmmtao01.cox.net@DLI92cx797990>
References: <20060615093328.DNIS19284.fed1rmmtao01.cox.net@DLI92cx797990>
Message-ID: <19cda190606150833h398cd809rd5d72433ae8ebd93@mail.gmail.com>

Yes, this is how the keyword expander is currently implemented, it actually
just replaces the token inside of the {}.

Currently to do what you were trying to do you would use the following
mv:generate="{template_dir_path}/{template_basename}.css"

I think it is important to not blur the lines between what is substituted
since if there is business logic that is used in addition the the token
itself then this would be confusing. This also keeps our keyword
substitution light and simple which can be used for other things and not too
customized for this one case.

If you want we can create another different token which represents
{template_dir_path}/{template_basename} to make it simpler for the user to
use, but I think it is important for this to be different than the token we
are using to represent template path with default extension.

So if you want we can create {template_path_no_ext} or {template_path_base}
or something similar which logically consists of
{template_dir_path}/{template_basename} .

What do you think?

On 6/15/06, Deb Lewis <djlewis at acm.org> wrote:
>
> I've gone through everything and have an almost-working system.  One unit
> test case fails (involving templates and abs. paths).  I can run my rails
> application and template parsing seems to be basically working.
>
> mv:generate="{template_path}" generates my .rhtml now
>
> glitch: mv:generate="{template_path}.css" produces foo.rhtml.css - so the
> default output extension isn't being ignored when target specified ext.
>
> ~ 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/20060615/b368d5aa/attachment.htm 

From djlewis at acm.org  Thu Jun 15 11:47:38 2006
From: djlewis at acm.org (Deb Lewis)
Date: Thu, 15 Jun 2006 08:47:38 -0700
Subject: [Masterview-devel] Integration status
In-Reply-To: <19cda190606150833h398cd809rd5d72433ae8ebd93@mail.gmail.com>
Message-ID: <20060615154735.KKFB11027.fed1rmmtao07.cox.net@DLI92cx797990>

RE: mv:generate="{template_dir_path}/{template_basename}.css" 
 
way too verbose, even for me, but your argument about clearly distinguishing
when default extension will be used vs. not is good.
 
{template_path_base} might work, but alternatively maybe we need to revisit
{template_path}, it's a bit confusing relative to the other keyword.  Lemme
think on this a bit more this morning.
 
[fwiw, I think I'm going to stop using my generates that are dumping out
local <style> decls, but I'm keeping for the moment because it turns out to
be a good test case for playing with our new target notations]
 
btw your new version of test/unit/template_spec_test fixed my unit test
failure, but am tinkering a bit more with paths and roots and init this
morning.  Want to test a bit more on my own rails app and in clean installs
before commiting, but I think I can submit today.
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Thursday, June 15, 2006 8:33 AM
To: djlewis at acm.org; masterview-devel at rubyforge.org
Subject: Re: [Masterview-devel] Integration status


Yes, this is how the keyword expander is currently implemented, it actually
just replaces the token inside of the {}. 

Currently to do what you were trying to do you would use the following
mv:generate="{template_dir_path}/{template_basename}.css" 

I think it is important to not blur the lines between what is substituted
since if there is business logic that is used in addition the the token
itself then this would be confusing. This also keeps our keyword
substitution light and simple which can be used for other things and not too
customized for this one case. 

If you want we can create another different token which represents
{template_dir_path}/{template_basename} to make it simpler for the user to
use, but I think it is important for this to be different than the token we
are using to represent template path with default extension. 

So if you want we can create {template_path_no_ext} or {template_path_base}
or something similar which logically consists of
{template_dir_path}/{template_basename} .

What do you think? 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060615/27708fd5/attachment.htm 

From jeff.barczewski at gmail.com  Thu Jun 15 11:58:09 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Thu, 15 Jun 2006 10:58:09 -0500
Subject: [Masterview-devel] Test case: analyzer breaks on template that
	parser handles
In-Reply-To: <20060613010332.PLWX18458.fed1rmmtao10.cox.net@DLI92cx797990>
References: <20060613010332.PLWX18458.fed1rmmtao10.cox.net@DLI92cx797990>
Message-ID: <19cda190606150858s5e29cae8lb3ce000832a63c80@mail.gmail.com>

With my commit earlier today, I believe that both of these issues are
resolved.

1) Empty/simple template analyzer stack.last nil bug
2) MasterView Admin controller didn' t have stylesheets if generator was not
run so output was plain and unstyled.

On 6/12/06, Deb Lewis <djlewis at acm.org> wrote:
>
> Configuration: new, empty rails app w/ masterview installed in
> vendor/plugins from my working copy, with new initializer hooked up, but
> no
> changes to parser.rb or analyzer.rb from current trunk.  Three lines
> changed
> in template_spec.rb to convert old MasterView::TemplateSrcRelativePath
> const
> refs and hardwired 'app/views' to new TemplateSrcDirPath constant.
>
> Create a single very simple template in app/masterview templates dir and
> verify that MV detects and parses it into app/views.  Attached.
>
> Go to masterview Admin controller -> list page does a TemplateSpec.scan on
> the templates src dir, breaks in Analyzer.end_element with nil value for
> stack.last at line 196 (if @depth == @stack.last.depth)
>
> It's dying on the <title> element the document <head>, according to trace
> dumps that I added.
>
> Not going to pursue this further right this instant, but this doesn't look
> like a Win32 platform issue.  Probably just needs extra stack.empty? check
> per below (just adding that did fix this simple case).  Anyway, explains
> why
> the admin controller breaks when I try to run it, my templates all have
> <title> elements in their headers.
>
>     if ! @stack.empty? && @depth == @stack.last.depth
>
> p.s. if you activate the admin controller in a new empty rails app it's
> really bogus looking - assumes stylesheets that aren't there.  I think
> these
> are guys that get dropped in from running your other generator, which at
> this point I haven't done in this new app and it's a legit use case that
> one
> might not do so.  A to-do for the cleanup list, not critical for the
> moment.
>
> ~ Deb
>
> MasterView::Analyzer.start_document
>
> MasterView::Analyzer.start_element
> ...uri: http://www.w3.org/1999/xhtml
> ...<html>
> ...attributes: lang, xml:lang, xmlns
> ... at depth=0
> ... at stack=[0 entries] on entry
> ... at stack=[0 entries] after processing entry
>
> MasterView::Analyzer.start_element
> ...<head>
> ... at depth=1
> ... at stack=[0 entries] on entry
> ... at stack=[0 entries] after processing entry
>
> MasterView::Analyzer.start_element
> ...<title>
> ... at depth=2
> ... at stack=[0 entries] on entry
> ... at stack=[0 entries] after processing entry
>
> MasterView::Analyzer.end_element
> ...</title>
> ...qname=title
> ... at stack=[0 entries] on entry
>
> ERROR:
> You have a nil object when you didn't expect it!
> The error occured while evaluating nil.depth
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060615/b87ff268/attachment.htm 

From jeff.barczewski at gmail.com  Thu Jun 15 12:19:55 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Thu, 15 Jun 2006 11:19:55 -0500
Subject: [Masterview-devel] Integration status
In-Reply-To: <20060615154735.KKFB11027.fed1rmmtao07.cox.net@DLI92cx797990>
References: <19cda190606150833h398cd809rd5d72433ae8ebd93@mail.gmail.com>
	<20060615154735.KKFB11027.fed1rmmtao07.cox.net@DLI92cx797990>
Message-ID: <19cda190606150919r54ebc2ebndfa2157c3847b8f2@mail.gmail.com>

Sounds good.

I am fine with changing keyword expansion to either have another expansion
word, or if you want to simply make {template_path} the one without
extension then I that would work as well.

We could put the logic into the generate tag to always add default extension
if one doesn't exist. In essence this would give you what you were hoping
for.

mv:generate="{template_path}" generates foo/bar.defaultExtension
mv:generate="{template_path}.css" generates foo/bar.css

I guess maybe I should have thought about doing it that way rather then
changing the keyword expander. It does seem reasonable to me to do things
this way if we do it in the generator logic. I don't know how much code this
will affect, but most likely parser code that handles generator directive,
and some work in the analyzer since I have to do keyword expansion and some
substitution to be able to compare sections to determine if an imported
section is out of date with another. Basically if they specified literally
foo.bar in one place and in another file they imported {template_path} that
expands to foo.bar in another. Logically those are the same so my comparison
needs to indicate that. Rebuild or copy currently forces the built files to
have their keywords expanded since it is too difficult to accomplish
otherwise.

Let me know what you think and whether this is something that you want in
there real soon or if it could wait a while. I would like to firm up the
keywords themselves before next release, but if you felt that the adding
default extension in generator is low priority then we could wait with that
until later and not mess up anything we have defined.

On 6/15/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  RE: mv:generate="{template_dir_path}/{template_basename}.css"
>
> way too verbose, even for me, but your argument about clearly
> distinguishing when default extension will be used vs. not is good.
>
> {template_path_base} might work, but alternatively maybe we need to
> revisit {template_path}, it's a bit confusing relative to the other
> keyword.  Lemme think on this a bit more this morning.
>
> [fwiw, I think I'm going to stop using my generates that are dumping out
> local <style> decls, but I'm keeping for the moment because it turns out to
> be a good test case for playing with our new target notations]
>
> btw your new version of test/unit/template_spec_test fixed my unit test
> failure, but am tinkering a bit more with paths and roots and init this
> morning.  Want to test a bit more on my own rails app and in clean installs
> before commiting, but I think I can submit today.
>
> ~ Deb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060615/3412680e/attachment-0001.htm 

From djlewis at acm.org  Thu Jun 15 12:34:33 2006
From: djlewis at acm.org (Deb Lewis)
Date: Thu, 15 Jun 2006 09:34:33 -0700
Subject: [Masterview-devel] On paths and expands and cleaning
Message-ID: <20060615163430.XOWM5347.fed1rmmtao05.cox.net@DLI92cx797990>

Jeff - we'll need to go over path handling one more time so our brains and
code are both clear.

Assumption: we'll always deal with normalized path representations (/ path
separator, not krufty windows \).  Initializer or other points where paths
can come in from the outside are responsible for doing any cleanup and
normalization.

Caveat: an abs path on Win32 has a drive letter prefix ('X:/foo/bar'), but
not on *nix, and the ruby file services don't necessarily work as desired.
(eg, believe it told me that 'X:/foo' is a relative path when I was
experimenting with abs/rel path services)

Implications: the only place where we should need to do things like
expand_path and cleanpath are in initializer.rb, which bolts down all the
fundamental root dir path refs for the app session, or any subsequent points
where we provide services to establish an MIO onto a directory.  I think
there's some now-unnecessary cases of this scattered around the MIO world
that can be dropped.

Side note: cleanpath doesn't on Windows, sigh - ugly things like
'../foo/../bing/bam' clutter up my RAILS_ROOT, which is why I made sure our
MV initializer tries to clean things up.  At least on Win32, expand_path
cleans up all the kruft so cleanpath seems unnecessary, but we can put that
back if needed on *nix.

Area we need to review: FileMIOTree's root_path and set_root_parent - I
don't quite understand the subtleties of what you're trying to do with the
latter in latest rails_init, we'll need to review.  Not sure it's needed
since new initializer instantiates the MasterView::IOMgr with FileMIOTree's
whose root_paths are already properly resovled to abs dir refs w/in rails
app.  Muddling about in there this morning....

~ Deb



From jeff.barczewski at gmail.com  Thu Jun 15 13:49:25 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Thu, 15 Jun 2006 12:49:25 -0500
Subject: [Masterview-devel] On paths and expands and cleaning
In-Reply-To: <20060615163430.XOWM5347.fed1rmmtao05.cox.net@DLI92cx797990>
References: <20060615163430.XOWM5347.fed1rmmtao05.cox.net@DLI92cx797990>
Message-ID: <19cda190606151049o225b908dm78c7e6be3fcc6fca@mail.gmail.com>

Yes, we'll always deal with url style (*nix) paths and we'll primarily deal
with only relative paths letting FileMIO resolve to absolute. Only using
root paths for FileMIO when creating. Also to note I check that the exanded
relative path exists under the root_path to sandbox to a particular tree.
Using relative paths should keep things simple, except for times when we
want full_path for logging or messages. What I did in those cases was added
a full_pathname attribute for output which we can read from if from FileMIO
it has root+relative path, for all other MIO objects it just is the same as
relative path.

That's a bummer that cleanpath doesn't work on win32.

Yes, I actually had to add the set_root_path thing in after the fact, when I
realized that I didn't have RAILS_ROOT yet when inside of rails_init.rb. So
if you have that taken care of with initializer then we can simlify that. I
guess I wasn't aware that RAILS_ROOT would be available in initializer. If
you can update initializer how it needs to be then I can take out that
method to simplify. So I guess that's why it didn't make sense to you, I
didn't build it in originally either :-)

Is initializer also where we do the rest of rails_init.rb, the watcher
setup? I also added some code to there today to copy the stylesheets that
are needed for masterview admin if it is enabled and they don't exist, so I
wasn't sure if you said this was going away (then let me know where I should
put the code).

Jeff



On 6/15/06, Deb Lewis <djlewis at acm.org> wrote:
>
> Jeff - we'll need to go over path handling one more time so our brains and
> code are both clear.
>
> Assumption: we'll always deal with normalized path representations (/ path
> separator, not krufty windows \).  Initializer or other points where paths
> can come in from the outside are responsible for doing any cleanup and
> normalization.
>
> Caveat: an abs path on Win32 has a drive letter prefix ('X:/foo/bar'), but
> not on *nix, and the ruby file services don't necessarily work as desired.
> (eg, believe it told me that 'X:/foo' is a relative path when I was
> experimenting with abs/rel path services)
>
> Implications: the only place where we should need to do things like
> expand_path and cleanpath are in initializer.rb, which bolts down all the
> fundamental root dir path refs for the app session, or any subsequent
> points
> where we provide services to establish an MIO onto a directory.  I think
> there's some now-unnecessary cases of this scattered around the MIO world
> that can be dropped.
>
> Side note: cleanpath doesn't on Windows, sigh - ugly things like
> '../foo/../bing/bam' clutter up my RAILS_ROOT, which is why I made sure
> our
> MV initializer tries to clean things up.  At least on Win32, expand_path
> cleans up all the kruft so cleanpath seems unnecessary, but we can put
> that
> back if needed on *nix.
>
> Area we need to review: FileMIOTree's root_path and set_root_parent - I
> don't quite understand the subtleties of what you're trying to do with the
> latter in latest rails_init, we'll need to review.  Not sure it's needed
> since new initializer instantiates the MasterView::IOMgr with
> FileMIOTree's
> whose root_paths are already properly resovled to abs dir refs w/in rails
> app.  Muddling about in there this morning....
>
> ~ 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/20060615/b4e42a79/attachment.htm 

From djlewis at acm.org  Thu Jun 15 15:25:09 2006
From: djlewis at acm.org (Deb Lewis)
Date: Thu, 15 Jun 2006 12:25:09 -0700
Subject: [Masterview-devel] On paths and expands and cleaning
In-Reply-To: <19cda190606151049o225b908dm78c7e6be3fcc6fca@mail.gmail.com>
Message-ID: <20060615192507.XFNL23482.fed1rmmtao12.cox.net@DLI92cx797990>

> > .. realized that I didn't have RAILS_ROOT yet when inside of
rails_init.rb. 
>>  So if you have that taken care of with initializer then we can simlify
that.  
>> I guess I wasn't aware that RAILS_ROOT would be available in initializer.

>> ...
>>Is initializer also where we do the rest of rails_init.rb, the watcher
setup? 
>> I also added some code to there today to copy the stylesheets that are 
>> needed for masterview admin 
 
Yes, initializer is the guy that takes care of figuring out RAIL_ROOT etc.
Goes to a lot of effort to try to automagicallly always do the right thing;
maybe not quite right for all scenarios, but heading in the right direction
anyway.  
 
extras/rails_init.rb is going away, what it was doing is shared between
initializer.rb and new extra/init_rails_controller.rb.  I've been synching
your changes last night/today that you've been doing in to rails_init.rb
into the new code, so got your stylesheet thing.  
 
Not sure I'm wild about pushing the admin controller's stylesheets into
app's public/stylesheets, may or may not be appropriate to litter their
space with "our" admin styles.  [tho I don't yet have a picture of how as an
app developer I'd want to integrate this into my app's overall styles and
layout...]
 
did you consider public/stylesheets/masterview?
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060615/4192321c/attachment.htm 

From jeff.barczewski at gmail.com  Thu Jun 15 15:50:14 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Thu, 15 Jun 2006 14:50:14 -0500
Subject: [Masterview-devel] On paths and expands and cleaning
In-Reply-To: <20060615192507.XFNL23482.fed1rmmtao12.cox.net@DLI92cx797990>
References: <19cda190606151049o225b908dm78c7e6be3fcc6fca@mail.gmail.com>
	<20060615192507.XFNL23482.fed1rmmtao12.cox.net@DLI92cx797990>
Message-ID: <19cda190606151250s3e7664b4q5a77301f11bbaaa0@mail.gmail.com>

On 6/15/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  Yes, initializer is the guy that takes care of figuring out RAIL_ROOT
> etc.  Goes to a lot of effort to try to automagicallly always do the right
> thing; maybe not quite right for all scenarios, but heading in the right
> direction anyway.
>
> extras/rails_init.rb is going away, what it was doing is shared between
> initializer.rb and new extra/init_rails_controller.rb.  I've been synching
> your changes last night/today that you've been doing in to rails_init.rb
> into the new code, so got your stylesheet thing.
>

sounds good.


Not sure I'm wild about pushing the admin controller's stylesheets into
> app's public/stylesheets, may or may not be appropriate to litter their
> space with "our" admin styles.  [tho I don't yet have a picture of how as an
> app developer I'd want to integrate this into my app's overall styles and
> layout...]
>


Yeah, I thought twice about this too, but couldn't come up with an easy
alternative. I figured if they use the generator which many of them will
then these will be generated anyway.  Of course we could move all of them
into a masterview folder below stylsheets like you mentioned, assuming the
asset_tag supports it which it probably does.


did you consider public/stylesheets/masterview?
>


Yes, I could change them to go there.


~ 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/20060615/e3ab319d/attachment.htm 

From djlewis at acm.org  Thu Jun 15 18:05:30 2006
From: djlewis at acm.org (Deb Lewis)
Date: Thu, 15 Jun 2006 15:05:30 -0700
Subject: [Masterview-devel] Integrate new initializer mechanism into MIO
	rework.
In-Reply-To: <20060615205605.AB00F3CC1CA@rubyforge.org>
Message-ID: <20060615220528.QBSL27967.fed1rmmtao08.cox.net@DLI92cx797990>

ok, I think it all got out there and reorganized (sorry about the email
blizzard, the reorg from my working copy didn't "take" so I just brute-force
moved everything).  As far as I know all your recent changes have been
picked up and brought forward.
 
UPGRADE: You'll need to recreate any MV settings customizations that you
have into the new config/masterview settings.rb and env config files. Should
be pretty straightforward, doc/configuration.html describes settings.
 
init.rb and task/masterview.rake replicated manually into the plugin
generator templates.
 
Testing of the build products and installation variations incomplete - can't
easily do all that on my win32 box.  And I haven't tested running the
masterview.rake tests on a rails app yet.
 
Rakefile changes:
 
o i was messing around with wrapping a 'dev' namespace on developer
utilities (parsing examples templates, syntax checking), change it back if
you don't like
 
**the dev:mvparse_examples rake task is broken, needs to be fixed up for the
new mio but i punted for now
 
o was trying to unravel what chunks go into which build packages, so you'll
see a bunch of factoring in file subset specs - tested that as much as I
can, but we'll have to doublecheck when doing a full build to make sure all
the files we want in various build pkg's are done properly
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060615/721de1c8/attachment-0001.htm 

From jeff.barczewski at gmail.com  Fri Jun 16 07:39:51 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 16 Jun 2006 06:39:51 -0500
Subject: [Masterview-devel] Integrate new initializer mechanism into MIO
	rework.
In-Reply-To: <20060615220528.QBSL27967.fed1rmmtao08.cox.net@DLI92cx797990>
References: <20060615205605.AB00F3CC1CA@rubyforge.org>
	<20060615220528.QBSL27967.fed1rmmtao08.cox.net@DLI92cx797990>
Message-ID: <19cda190606160439u50be2537jd2bb872325b5f709@mail.gmail.com>

I fixed the dev:mv_parse_examples task

Good job on the reorg and config work, it is pretty nice!!

I had a problem trying to use

config.after_initialize { MasterView::Log.level = DEBUG }

in my config/masterview/settings.rb

It throws me into some sort of rdb debug mode?? I thought I would ask you if
this works for you and if you had any ideas. I'm guessing that some sort of
exception is being raised (but not shown) and this is kicking me into a
debugger?? Not sure, but if it is all working for you then I will look into
it. Let me know if you have any ideas.

Thanks,

Jeff

On 6/15/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  ok, I think it all got out there and reorganized (sorry about the email
> blizzard, the reorg from my working copy didn't "take" so I just brute-force
> moved everything).  As far as I know all your recent changes have been
> picked up and brought forward.
>
> UPGRADE: You'll need to recreate any MV settings customizations that you
> have into the new config/masterview settings.rb and env config files.
> Should be pretty straightforward, doc/configuration.html describes settings.
>
> init.rb and task/masterview.rake replicated manually into the plugin
> generator templates.
>
> Testing of the build products and installation variations incomplete -
> can't easily do all that on my win32 box.  And I haven't tested running the
> masterview.rake tests on a rails app yet.
>
> Rakefile changes:
>
> o i was messing around with wrapping a 'dev' namespace on developer
> utilities (parsing examples templates, syntax checking), change it back if
> you don't like
>
> **the dev:mvparse_examples rake task is broken, needs to be fixed up for
> the new mio but i punted for now
>
> o was trying to unravel what chunks go into which build packages, so
> you'll see a bunch of factoring in file subset specs - tested that as much
> as I can, but we'll have to doublecheck when doing a full build to make sure
> all the files we want in various build pkg's are done properly
>
> ~ 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/20060616/0ddba7fa/attachment.htm 

From djlewis at acm.org  Fri Jun 16 10:47:06 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 16 Jun 2006 07:47:06 -0700
Subject: [Masterview-devel] Integrate new initializer mechanism into MIO
	rework.
In-Reply-To: <19cda190606160439u50be2537jd2bb872325b5f709@mail.gmail.com>
Message-ID: <20060616144702.TQNG12581.fed1rmmtao02.cox.net@DLI92cx797990>

MasterView.set_log_level( 'DEBUG' )
 
generator style changes are good, i like that naming scheme better, reduces
possibility of inadvertant collision with apps' own stylesheets.  We need to
document this at some point ("Using the mv admin controller will add some
stylesheets to your app's public/stylesheets..."
 
thx for the other fixes in initializer, obviously I hadn't tested a few of
those scenarios well enough
 
My priorities for today:
- respond to mv:generate keyword subst. and file ext. handling semantics
    mv:generate="{template_path}" and ="{template_path}.css" 
- think about issues you raised about what/how to do config w/ new mio
- testing and documentation (doc/installation.html)
 
~ Deb

 
  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Friday, June 16, 2006 4:40 AM
To: djlewis at acm.org; masterview-devel at rubyforge.org
Subject: Re: [Masterview-devel] Integrate new initializer mechanism into MIO
rework.


I fixed the dev:mv_parse_examples task

Good job on the reorg and config work, it is pretty nice!!

I had a problem trying to use 

config.after_initialize { MasterView::Log.level = DEBUG }

in my config/masterview/settings.rb 

It throws me into some sort of rdb debug mode?? I thought I would ask you if
this works for you and if you had any ideas. I'm guessing that some sort of
exception is being raised (but not shown) and this is kicking me into a
debugger?? Not sure, but if it is all working for you then I will look into
it. Let me know if you have any ideas. 

Thanks,

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060616/1eb3ee25/attachment.htm 

From djlewis at acm.org  Fri Jun 16 11:03:55 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 16 Jun 2006 08:03:55 -0700
Subject: [Masterview-devel] protocol for changing the MV log level
In-Reply-To: <20060616144702.TQNG12581.fed1rmmtao02.cox.net@DLI92cx797990>
Message-ID: <20060616150351.BLES27967.fed1rmmtao08.cox.net@DLI92cx797990>

 >>  MasterView.set_log_level( 'DEBUG' )
 
hmm hmm... string or symbol or be generous and accept either flavor of the
name from client??
 
    MasterView.set_log_level( :DEBUG )
 
and I suppose assignment is probably more natural that setter function, I
think I just hadn't decided at the time I did that whether I liked assigment
semantics directly on the MV module, but it's probably fine
 
    MasterView::log_level= 'DEBUG'  #? or :DEBUG ?
 
I'll put that in this morning.
 
Contemplating also supporting Masterview.log service, rather than
MasterView::Log.  If clients outside the MV/directives impls have legit need
to get the log, prefer accessor rather than direct ref to module constant.
Maybe premature, won't add this unless we decide it's appropriate to expose.
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060616/44dbc39c/attachment.htm 

From djlewis at acm.org  Fri Jun 16 11:07:08 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 16 Jun 2006 08:07:08 -0700
Subject: [Masterview-devel] Build task impl question
Message-ID: <20060616150704.BORR27967.fed1rmmtao08.cox.net@DLI92cx797990>

in the rakefile, is there a particular reason that the two generator gems
are built by explicitly cd'ing to the generator dir and running 'rake
package' in that context, vs. using Rake::GemPackageTask.new(spec) as done
for the main mv gem?

tracking down why that variation of building the generator gems doesn't work
on windows

~ Deb



From djlewis at acm.org  Fri Jun 16 11:24:09 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 16 Jun 2006 08:24:09 -0700
Subject: [Masterview-devel] aaah - lib/facets/core/string/starts_with.rb
Message-ID: <20060616152405.YSPU18458.fed1rmmtao10.cox.net@DLI92cx797990>

cool, just (re)discovered this, it's been bugging me that ruby strings don't
support starts/ends-with predicates, which are standard in python and very
handy.

There's a couple places in code I've written that I'll fix to use these

~ Deb



From jeff.barczewski at gmail.com  Fri Jun 16 11:56:43 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 16 Jun 2006 10:56:43 -0500
Subject: [Masterview-devel] Build task impl question
In-Reply-To: <20060616150704.BORR27967.fed1rmmtao08.cox.net@DLI92cx797990>
References: <20060616150704.BORR27967.fed1rmmtao08.cox.net@DLI92cx797990>
Message-ID: <19cda190606160856j5937326aha37288dff155b854@mail.gmail.com>

yeah, I couldn't figure out how for it to build packages using a sub
directory, tried many things and couldn't get it to do what we needed. If
you can find a better way then lets try it.

On 6/16/06, Deb Lewis <djlewis at acm.org> wrote:
>
> in the rakefile, is there a particular reason that the two generator gems
> are built by explicitly cd'ing to the generator dir and running 'rake
> package' in that context, vs. using Rake::GemPackageTask.new(spec) as done
> for the main mv gem?
>
> tracking down why that variation of building the generator gems doesn't
> work
> on windows
>
> ~ 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/20060616/84963a8d/attachment.htm 

From jeff.barczewski at gmail.com  Fri Jun 16 12:00:34 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 16 Jun 2006 11:00:34 -0500
Subject: [Masterview-devel] I just about have direct to erb working
Message-ID: <19cda190606160900m59f6b8b7i8750d0e35c4fee4a@mail.gmail.com>

I just about have direct to erb working (eliminating rhtml to file
generation). I just have to make the right hook for the layouts and need to
look at the analyzer and it will be done.

There will be a little more to figure out around getting utilities to
support operation in this mode (for debugging) like several ways to get at
the erb, but otherwise it is done.

I wanted to have it this morning, but ran out of time. I am taking off to
take my daughter to water park. Will pick it up later this evening and get
it finished.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060616/22ec1f33/attachment-0001.htm 

From djlewis at acm.org  Fri Jun 16 16:00:34 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 16 Jun 2006 13:00:34 -0700
Subject: [Masterview-devel] What I really want for {template_path}
	substitution semantics
Message-ID: <20060616200031.PIGN15767.fed1rmmtao04.cox.net@DLI92cx797990>

... is sketched out in notes and revised code in
branches/djl-revised-template-keywords-20060616/keyword_expander.rb

aborted attempt to test in my app, however - reparsing/writing generated
files isn't working this morning, startup trace looks appropriate but
template changes aren't generating updated output files

And template_file_watcher_test - writing test/tmp/views output - where are
things going today??!  maybe due to removal of mio root-path

~ Deb



From djlewis at acm.org  Fri Jun 16 16:01:56 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 16 Jun 2006 13:01:56 -0700
Subject: [Masterview-devel] I just about have direct to erb working
In-Reply-To: <19cda190606160900m59f6b8b7i8750d0e35c4fee4a@mail.gmail.com>
Message-ID: <20060616200152.TNCF24290.fed1rmmtao09.cox.net@DLI92cx797990>

fabulous!!  that would be exceptionally fine to get working so quickly,
wasn't sure how close we were to tackling that yet
 
~ Deb
 

  _____  

From: masterview-devel-bounces at rubyforge.org
[mailto:masterview-devel-bounces at rubyforge.org] On Behalf Of Jeff Barczewski
Sent: Friday, June 16, 2006 9:01 AM
To: masterview-devel at rubyforge.org
Subject: [Masterview-devel] I just about have direct to erb working


I just about have direct to erb working (eliminating rhtml to file
generation). I just have to make the right hook for the layouts and need to
look at the analyzer and it will be done.

There will be a little more to figure out around getting utilities to
support operation in this mode (for debugging) like several ways to get at
the erb, but otherwise it is done. 

I wanted to have it this morning, but ran out of time. I am taking off to
take my daughter to water park. Will pick it up later this evening and get
it finished. 

Jeff

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

From jeff.barczewski at gmail.com  Fri Jun 16 20:06:38 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 16 Jun 2006 19:06:38 -0500
Subject: [Masterview-devel] aaah - lib/facets/core/string/starts_with.rb
In-Reply-To: <20060616152405.YSPU18458.fed1rmmtao10.cox.net@DLI92cx797990>
References: <20060616152405.YSPU18458.fed1rmmtao10.cox.net@DLI92cx797990>
Message-ID: <19cda190606161706t60adc994w5fe9e5f2570925d@mail.gmail.com>

Yes I missed that too. I wrote my own and then found that facets had it and
a bunch more so I just borrowed a few of them so people wouldn't have to
install the entire facets collection.

This is one of the first places I look to see if missing functions are
implemented, they have a huge library of things that can be individually
included.

On 6/16/06, Deb Lewis <djlewis at acm.org> wrote:
>
> cool, just (re)discovered this, it's been bugging me that ruby strings
> don't
> support starts/ends-with predicates, which are standard in python and very
> handy.
>
> There's a couple places in code I've written that I'll fix to use these
>
> ~ 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/20060616/41da03b0/attachment.htm 

From jeff.barczewski at gmail.com  Fri Jun 16 20:19:23 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 16 Jun 2006 19:19:23 -0500
Subject: [Masterview-devel] I just about have direct to erb working
In-Reply-To: <20060616200152.TNCF24290.fed1rmmtao09.cox.net@DLI92cx797990>
References: <19cda190606160900m59f6b8b7i8750d0e35c4fee4a@mail.gmail.com>
	<20060616200152.TNCF24290.fed1rmmtao09.cox.net@DLI92cx797990>
Message-ID: <19cda190606161719s3d1e337em223797797f4ddd3b@mail.gmail.com>

Yeah, it just kind of fell out. Once we had the MIO rewritten, I thought I
would take a look and see what it would take. It turned out that it would be
fairly easy hook since we had all that in place. So I was testing just
before I went to the water park this morning and it was close, it turns out
I have to hook something else to get the layouts but once that is done I
think we're good. It would be wonderful to have that out of the way too.

I will also take a look at your email that you weren't getting things
updated properly after this mornings changes (mentioned root_path removal as
possible suspect). I also took out one of the file expansions because it was
ending up expanded twice (giving wrong path). I thought everything seemed to
be working on my end, though I was running through a ton of things this
morning so maybe I wasn't careful enough. However I think we even have a
rake test that tests the watcher and all tests were passing. I know I also
would change a template and then when I refresh the browser it was picking
it up. Will check it out.

Jeff

On 6/16/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  fabulous!!  that would be exceptionally fine to get working so quickly,
> wasn't sure how close we were to tackling that yet
>
> ~ Deb
>
>
>  ------------------------------
> *From:* masterview-devel-bounces at rubyforge.org [mailto:
> masterview-devel-bounces at rubyforge.org] *On Behalf Of *Jeff Barczewski
> *Sent:* Friday, June 16, 2006 9:01 AM
> *To:* masterview-devel at rubyforge.org
> *Subject:* [Masterview-devel] I just about have direct to erb working
>
> I just about have direct to erb working (eliminating rhtml to file
> generation). I just have to make the right hook for the layouts and need to
> look at the analyzer and it will be done.
>
> There will be a little more to figure out around getting utilities to
> support operation in this mode (for debugging) like several ways to get at
> the erb, but otherwise it is done.
>
> I wanted to have it this morning, but ran out of time. I am taking off to
> take my daughter to water park. Will pick it up later this evening and get
> it finished.
>
> Jeff
>
> _______________________________________________
> 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/20060616/c981474f/attachment.htm 

From jeff.barczewski at gmail.com  Fri Jun 16 20:21:34 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 16 Jun 2006 19:21:34 -0500
Subject: [Masterview-devel] What I really want for {template_path}
	substitution semantics
In-Reply-To: <20060616200031.PIGN15767.fed1rmmtao04.cox.net@DLI92cx797990>
References: <20060616200031.PIGN15767.fed1rmmtao04.cox.net@DLI92cx797990>
Message-ID: <19cda190606161721t18299095u9c3de635507b4a17@mail.gmail.com>

I will take a look at your notes and code.

I will make sure things are still working on my end and then test in windows
too, to see if its one of those types of issues.

On 6/16/06, Deb Lewis <djlewis at acm.org> wrote:
>
> ... is sketched out in notes and revised code in
> branches/djl-revised-template-keywords-20060616/keyword_expander.rb
>
> aborted attempt to test in my app, however - reparsing/writing generated
> files isn't working this morning, startup trace looks appropriate but
> template changes aren't generating updated output files
>
> And template_file_watcher_test - writing test/tmp/views output - where are
> things going today??!  maybe due to removal of mio root-path
>
> ~ 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/20060616/b13889a3/attachment.htm 

From jeff.barczewski at gmail.com  Sat Jun 17 17:59:43 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sat, 17 Jun 2006 16:59:43 -0500
Subject: [Masterview-devel] Finished direct to erb
Message-ID: <19cda190606171459g4b93439cpc4a7dcd07f87ab37@mail.gmail.com>

I finished the direct to erb functionality and added ability to configure it
on or off.

Should I default it to on? If so should we default the template view src to
app/views rather than app/masterview?

I still need to test this stuff on windows, but it is working on *nix.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060617/bd52e5c7/attachment.htm 

From djlewis at acm.org  Sat Jun 17 18:36:08 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 17 Jun 2006 15:36:08 -0700
Subject: [Masterview-devel] Finished direct to erb
In-Reply-To: <19cda190606171459g4b93439cpc4a7dcd07f87ab37@mail.gmail.com>
Message-ID: <20060617223604.DNWV18458.fed1rmmtao10.cox.net@DLI92cx797990>

errr....
 
config.read_erb_direct_from_masterview
 
is a pretty awful name, if ya don't mind a bit of nitpicking.
 
Maybe... 'generate_rhtml_files' or something along those lines - want to
express "should we create .rhtml output files or not" when running in rails,
right?
 
>> default the template view src to app/views rather than app/masterview
 
fine by me, that's actually what I ended up deciding was the right way to
organize my own app anyway, with or w/out generated .rhtml
 
I've been chasing odd failures related to timestamps all day...  I think
there's something very odd going on related to subclipse in my Ecipse setup,
but even these end up being "my dev system" oddities it does seem to point
out some issues with changed-template checking, I have to think about what's
happening a bit more.
 
~ Deb
 
  _____  

From: masterview-devel-bounces at rubyforge.org
[mailto:masterview-devel-bounces at rubyforge.org] On Behalf Of Jeff Barczewski
Sent: Saturday, June 17, 2006 3:00 PM
To: masterview-devel at rubyforge.org
Subject: [Masterview-devel] Finished direct to erb


I finished the direct to erb functionality and added ability to configure it
on or off. 

Should I default it to on? If so should we default the template view src to
app/views rather than app/masterview?

I still need to test this stuff on windows, but it is working on *nix. 

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060617/3ef00e14/attachment-0001.htm 

From djlewis at acm.org  Sun Jun 18 01:52:47 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 17 Jun 2006 22:52:47 -0700
Subject: [Masterview-devel] No joy in generating today
Message-ID: <20060618055242.NLRB554.fed1rmmtao11.cox.net@DLI92cx797990>

Can't seem to get either .rhtml files out or erb directly into the rails
view cache.

Tried in my own rails app where I've got a few pages for testing this, also
on a clean install (from newly built gem, whoo hoo) into a new empty rails
app.  nada.

I'm going to add a config info page to the masterview admin controller in
the morning; that might help track things down and will be useful in any
case.

~ Deb



From jeff.barczewski at gmail.com  Sun Jun 18 09:05:40 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sun, 18 Jun 2006 08:05:40 -0500
Subject: [Masterview-devel] Finished direct to erb
In-Reply-To: <20060617223604.DNWV18458.fed1rmmtao10.cox.net@DLI92cx797990>
References: <19cda190606171459g4b93439cpc4a7dcd07f87ab37@mail.gmail.com>
	<20060617223604.DNWV18458.fed1rmmtao10.cox.net@DLI92cx797990>
Message-ID: <19cda190606180605p72979e96w67ee9ee76eb96365@mail.gmail.com>

Yes, I suppose so, I was trying to be descriptive about what the config
point does from the code's point of view but I think you are right from the
users point of view something as simple as generate rhtml is better.



On 6/17/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  errr....
>
> config.read_erb_direct_from_masterview
>
> is a pretty awful name, if ya don't mind a bit of nitpicking.
>
> Maybe... 'generate_rhtml_files' or something along those lines - want to
> express "should we create .rhtml output files or not" when running in rails,
> right?
>
> >> default the template view src to app/views rather than app/masterview
>
> fine by me, that's actually what I ended up deciding was the right way to
> organize my own app anyway, with or w/out generated .rhtml
>
> I've been chasing odd failures related to timestamps all day...  I think
> there's something very odd going on related to subclipse in my Ecipse setup,
> but even these end up being "my dev system" oddities it does seem to point
> out some issues with changed-template checking, I have to think about what's
> happening a bit more.
>
> ~ Deb
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060618/9da1fceb/attachment.htm 

From jeff.barczewski at gmail.com  Sun Jun 18 09:09:54 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sun, 18 Jun 2006 08:09:54 -0500
Subject: [Masterview-devel] No joy in generating today
In-Reply-To: <20060618055242.NLRB554.fed1rmmtao11.cox.net@DLI92cx797990>
References: <20060618055242.NLRB554.fed1rmmtao11.cox.net@DLI92cx797990>
Message-ID: <19cda190606180609h2b35160cra14a7f0d79164e00@mail.gmail.com>

Nothing? I'll try testing on windows too to see if I can find any issues. I
also want to gracefully handle the situation where one doesn't have write
permission to the file system, need to test that.

I will do some installs on windows and see if anything breaks.

Jeff

On 6/18/06, Deb Lewis <djlewis at acm.org> wrote:
>
> Can't seem to get either .rhtml files out or erb directly into the rails
> view cache.
>
> Tried in my own rails app where I've got a few pages for testing this,
> also
> on a clean install (from newly built gem, whoo hoo) into a new empty rails
> app.  nada.
>
> I'm going to add a config info page to the masterview admin controller in
> the morning; that might help track things down and will be useful in any
> case.
>
> ~ 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/20060618/8e0df71b/attachment.htm 

From jeff.barczewski at gmail.com  Sun Jun 18 12:23:54 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sun, 18 Jun 2006 11:23:54 -0500
Subject: [Masterview-devel] No joy in generating today
In-Reply-To: <19cda190606180609h2b35160cra14a7f0d79164e00@mail.gmail.com>
References: <20060618055242.NLRB554.fed1rmmtao11.cox.net@DLI92cx797990>
	<19cda190606180609h2b35160cra14a7f0d79164e00@mail.gmail.com>
Message-ID: <19cda190606180923g7ab9bf0cn3ca26a689965b11d@mail.gmail.com>

I fixed an issue today where updates weren't being seen because the
resolution of Time is a second, so I put in a sleep in the tests to insure a
second would pass between updates.

I also updated config_settings_test to use default path of app/views

All tests work for me on *nix and win32. I also manually ran mv as gem and
plugin in both environments and appears to be working from what I tested. I
tested with generate_rhtml on and off.

I am running rails 1.1.2, I haven't tried it on older versions in a while.
Specifically the direct to erb might not work on older versions, so if it
doesn't then set generate_rhtml_files to true and it should work fine.  Will
test on those versions first chance I get.

Let me know the details of your issues, it sounds like nothing is generating
for you, or it isn't picking up updates?? And you have all the latest
changes. correct?

I'm hoping that it is something out of sync, because I am running out of
ideas unless it maybe it is an older version of rails or something, but they
also worked (using rhtml) when I tested a while back.

I am going to do some stuff for fathers day, but let me know any details of
your issues and I'll take a look by tomorrow morning.

Jeff

On 6/18/06, Jeff Barczewski <jeff.barczewski at gmail.com> wrote:
>
> Nothing? I'll try testing on windows too to see if I can find any issues.
> I also want to gracefully handle the situation where one doesn't have write
> permission to the file system, need to test that.
>
> I will do some installs on windows and see if anything breaks.
>
> Jeff
>
>
> On 6/18/06, Deb Lewis <djlewis at acm.org> wrote:
> >
> > Can't seem to get either .rhtml files out or erb directly into the rails
> > view cache.
> >
> > Tried in my own rails app where I've got a few pages for testing this,
> > also
> > on a clean install (from newly built gem, whoo hoo) into a new empty
> > rails
> > app.  nada.
> >
> > I'm going to add a config info page to the masterview admin controller
> > in
> > the morning; that might help track things down and will be useful in any
> > case.
> >
> > ~ 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/20060618/bd550605/attachment.htm 

From djlewis at acm.org  Sun Jun 18 16:45:13 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sun, 18 Jun 2006 13:45:13 -0700
Subject: [Masterview-devel] No joy in generating today
In-Reply-To: <19cda190606180923g7ab9bf0cn3ca26a689965b11d@mail.gmail.com>
Message-ID: <20060618204510.KCGN554.fed1rmmtao11.cox.net@DLI92cx797990>

I'm running rails 1.1.2, ruby 1.8.4, and fully synched with trunk.  There's
something profoundly screwy going on with my files and timestamps that only
seems to have started w/in the past few days.
 
I have finally gotten things running again, kinda: mv installed in a clean
empty rails app, files not under version control; also in my own rails app
checked out from svn if I do certain hand-fiddling to ensure template file
timestamps are getting updated.  Tried both file generation and
direct-to-rails-cache - cool!!!
 
There's something I don't understand about what's happening with SVN
checkouts and files/timestamps.  Dunno if it's SVN, my client config
settings, Tortoise SVN, subclipse, or all of these in some fashion.  I'm
editing files in eclipse or with my usual html editing tools and despite the
fact that edits are made and saved the file timestamps aren't getting
updated.  I am... baffled.
 
A thought: timestamps can in general be kind of flakey, esp. when doing
things like FTP xfr's between machines (?and version control checkouts?).
And you really don't wanna hear me whine about daylight savings changes on
windows... Maybe shouldn't be the sole criteria for  template change
detection.  How about adding a size-changed condition as well?
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Sunday, June 18, 2006 9:24 AM
To: djlewis at acm.org; masterview-devel at rubyforge.org
Subject: Re: [Masterview-devel] No joy in generating today


I fixed an issue today where updates weren't being seen because the
resolution of Time is a second, so I put in a sleep in the tests to insure a
second would pass between updates. 

I also updated config_settings_test to use default path of app/views 

All tests work for me on *nix and win32. I also manually ran mv as gem and
plugin in both environments and appears to be working from what I tested. I
tested with generate_rhtml on and off.

I am running rails 1.1.2, I haven't tried it on older versions in a while.
Specifically the direct to erb might not work on older versions, so if it
doesn't then set generate_rhtml_files to true and it should work fine.  Will
test on those versions first chance I get. 

Let me know the details of your issues, it sounds like nothing is generating
for you, or it isn't picking up updates?? And you have all the latest
changes. correct?

I'm hoping that it is something out of sync, because I am running out of
ideas unless it maybe it is an older version of rails or something, but they
also worked (using rhtml) when I tested a while back. 

I am going to do some stuff for fathers day, but let me know any details of
your issues and I'll take a look by tomorrow morning.

Jeff

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

From djlewis at acm.org  Sun Jun 18 16:51:07 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sun, 18 Jun 2006 13:51:07 -0700
Subject: [Masterview-devel] Plugin generator for gem installation
Message-ID: <20060618205102.LZTJ19317.fed1rmmtao03.cox.net@DLI92cx797990>

Your original installation description of gem install say that after
installing masterview gem, running the masterview_plugin_generator will
"...create a very lightweight plugin instance for this application mainly
consisting of an init.rb file which will get loaded at runtime. This init.rb
refers to the gem"

But... I just ran script/generate masterview_plugin for an install test and
it copied in the whole lib directory.  I nuked lib, just to verify that it
indeed wasn't needed.

So I think this is a bug in the masterview_plugin_generator, yes?

Also: mv admin controller is a feature of the main masterview gem, but it's
stylesheets depend on having the mv-generator also installed.  Not good,
this is essentially an "up-level" dependency (fundamental component shoudn't
depend on something optionally layered on top of it)

~ Deb



From jeff.barczewski at gmail.com  Sun Jun 18 23:20:23 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sun, 18 Jun 2006 22:20:23 -0500
Subject: [Masterview-devel] No joy in generating today
In-Reply-To: <20060618204510.KCGN554.fed1rmmtao11.cox.net@DLI92cx797990>
References: <19cda190606180923g7ab9bf0cn3ca26a689965b11d@mail.gmail.com>
	<20060618204510.KCGN554.fed1rmmtao11.cox.net@DLI92cx797990>
Message-ID: <19cda190606182020o2aecc50ne632fd4a5b7a8e51@mail.gmail.com>

Well what we are doing currently is if the mtime is not exactly what it was
before then assume it is changed. I don't bother doing greater than checking
just if it is different. Rails currently just checks if the file is > than
the last compile time (which like you said can get messed up). I think doing
exact mtime checking gets around most issues. If we need to we can
eventually add size too, but I just went for simple (and that was what rails
was doing too).

On 6/18/06, Deb Lewis <djlewis at acm.org> wrote:
>
>
> A thought: timestamps can in general be kind of flakey, esp. when doing
> things like FTP xfr's between machines (?and version control checkouts?).
> And you really don't wanna hear me whine about daylight savings changes on
> windows... Maybe shouldn't be the sole criteria for  template change
> detection.  How about adding a size-changed condition as well?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060618/72f7b814/attachment.htm 

From jeff.barczewski at gmail.com  Sun Jun 18 23:31:20 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sun, 18 Jun 2006 22:31:20 -0500
Subject: [Masterview-devel] Plugin generator for gem installation
In-Reply-To: <20060618205102.LZTJ19317.fed1rmmtao03.cox.net@DLI92cx797990>
References: <20060618205102.LZTJ19317.fed1rmmtao03.cox.net@DLI92cx797990>
Message-ID: <19cda190606182031ge5a636cvc869d8bc19e4f783@mail.gmail.com>

The plugin generator shouldn't have very many files to copy. Are you sure
you weren't running it on an app that already was installed as normal
plugin? One would either install as gem and then script/generate the plugin
(which is only coded to create a handful of files and directories). It does
create a lib/masterview and a few files under there but it shouldn't be the
whole tree. I will double check but that wasn't what I was seeing happen. I
will try to verify.

If you can come up with a better way for us to do these cross gem
dependencies I am all ears, that was causing headaches from the beginning, I
didn't like it but couldn't come up with a better way yet. I also didn't
like having to duplicate the files. I looked for a way to do this in svn but
didn't find one yet, so created the rake task to help with it. Would be best
if we could find a way to not have those issues. Of course it all gets
tricky when being able to do things from straight plugin and via gems, but I
really like having both ways to install. Serves more users that way. I would
think that eventually plugins will evolve to using gems, not sure why they
kind of abandoned them when they were created, there are nice features in
gems including versioning and dependencies.

Jeff



On 6/18/06, Deb Lewis <djlewis at acm.org> wrote:
>
> Your original installation description of gem install say that after
> installing masterview gem, running the masterview_plugin_generator will
> "...create a very lightweight plugin instance for this application mainly
> consisting of an init.rb file which will get loaded at runtime. This
> init.rb
> refers to the gem"
>
> But... I just ran script/generate masterview_plugin for an install test
> and
> it copied in the whole lib directory.  I nuked lib, just to verify that it
> indeed wasn't needed.
>
> So I think this is a bug in the masterview_plugin_generator, yes?
>
> Also: mv admin controller is a feature of the main masterview gem, but
> it's
> stylesheets depend on having the mv-generator also installed.  Not good,
> this is essentially an "up-level" dependency (fundamental component
> shoudn't
> depend on something optionally layered on top of it)
>
> ~ 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/20060618/4919bcf8/attachment.htm 

From jeff.barczewski at gmail.com  Sun Jun 18 23:57:24 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sun, 18 Jun 2006 22:57:24 -0500
Subject: [Masterview-devel] Your keyword changes look good,
	lets commit them Re: What I really want for {template_path}
	substitution semantics
Message-ID: <19cda190606182057g4bf7d83aoc98dffdae6ceb9ba@mail.gmail.com>

Sorry I took so long to take a look at your changes, I was preoccupied with
all the mods I was doing.

Your keyword expander changes look good, lets go ahead and turn those on.
Looks like a nice addition. The way you implemented is very clean.

Commit those whenever you are ready. Looking to do a build soon, so let's go
ahead and get those in.

Let me know if there are any other things you needed me to look at for this
release. Otherwise I am working on videos and we'll need to come up with a
nice release announcement.


On 6/16/06, Jeff Barczewski <jeff.barczewski at gmail.com> wrote:
>
> I will take a look at your notes and code.
>
> I will make sure things are still working on my end and then test in
> windows too, to see if its one of those types of issues.
>
>
> On 6/16/06, Deb Lewis <djlewis at acm.org> wrote:
> >
> > ... is sketched out in notes and revised code in
> > branches/djl-revised-template-keywords-20060616/keyword_expander.rb
> >
> > aborted attempt to test in my app, however - reparsing/writing generated
> > files isn't working this morning, startup trace looks appropriate but
> > template changes aren't generating updated output files
> >
> > And template_file_watcher_test - writing test/tmp/views output - where
> > are
> > things going today??!  maybe due to removal of mio root-path
> >
> > ~ 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/20060618/404cdd61/attachment.htm 

From jeff.barczewski at gmail.com  Mon Jun 19 00:05:14 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sun, 18 Jun 2006 23:05:14 -0500
Subject: [Masterview-devel] Plugin generator for gem installation
In-Reply-To: <19cda190606182031ge5a636cvc869d8bc19e4f783@mail.gmail.com>
References: <20060618205102.LZTJ19317.fed1rmmtao03.cox.net@DLI92cx797990>
	<19cda190606182031ge5a636cvc869d8bc19e4f783@mail.gmail.com>
Message-ID: <19cda190606182105q2cdc5d5diee310fe09f4f6b3@mail.gmail.com>

I just tried the gem plugin generator and it only created the files I would
have expected, so can you verify on your end that it is doing something
wrong?

We do need to update the docs though because it now does add a little more
than just the init. It has the default settings files and the admin
controller and view files. The reas stays in the gems, but these were
exposed since they might need to be changed by the users.

On 6/18/06, Jeff Barczewski <jeff.barczewski at gmail.com> wrote:
>
> The plugin generator shouldn't have very many files to copy. Are you sure
> you weren't running it on an app that already was installed as normal
> plugin? One would either install as gem and then script/generate the plugin
> (which is only coded to create a handful of files and directories). It does
> create a lib/masterview and a few files under there but it shouldn't be the
> whole tree. I will double check but that wasn't what I was seeing happen. I
> will try to verify.
>
>
> On 6/18/06, Deb Lewis <djlewis at acm.org> wrote:
> >
> > Your original installation description of gem install say that after
> > installing masterview gem, running the masterview_plugin_generator will
> > "...create a very lightweight plugin instance for this application
> > mainly
> > consisting of an init.rb file which will get loaded at runtime. This
> > init.rb
> > refers to the gem"
> >
> > But... I just ran script/generate masterview_plugin for an install test
> > and
> > it copied in the whole lib directory.  I nuked lib, just to verify that
> > it
> > indeed wasn't needed.
> >
> > So I think this is a bug in the masterview_plugin_generator, yes?
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060618/8b29c28c/attachment.htm 

From djlewis at acm.org  Mon Jun 19 00:42:47 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sun, 18 Jun 2006 21:42:47 -0700
Subject: [Masterview-devel] Plugin generator for gem installation
In-Reply-To: <19cda190606182105q2cdc5d5diee310fe09f4f6b3@mail.gmail.com>
Message-ID: <20060619044242.FVHQ27967.fed1rmmtao08.cox.net@DLI92cx797990>

I just did rebuild of the gems today to test.  Take a look at the generator
rakefiles - you just changed both of them w/in the past few days to change
from explicit masterview-XX-rb to "*.rb" in the include spec.
 
Just finished working through rewrite for new doc/installation.html, after
going through all the scenarios and (re)testing all the command descriptions
etc.  Go over it and make any changes/additions I missed on this pass (or
send me reminder of which areas to fix).
 
I don't think I capture all the recent tweaks about admin stylesheets and
auto-install of prototype settings files, we need to pick those up on
another pass.
 
Should I go ahead and start breaking up the original top-level index.html
into separate doc's or is that something you want to look at?  Suggest a
main intro page, stripped down to overview and links to all the key
sub-docs: install, config, User's Guide (doc/guide.html) and Directives
Reference (doc/directives.html)
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Sunday, June 18, 2006 9:05 PM
To: djlewis at acm.org; masterview-devel at rubyforge.org
Subject: Re: [Masterview-devel] Plugin generator for gem installation


I just tried the gem plugin generator and it only created the files I would
have expected, so can you verify on your end that it is doing something
wrong?

We do need to update the docs though because it now does add a little more
than just the init. It has the default settings files and the admin
controller and view files. The reas stays in the gems, but these were
exposed since they might need to be changed by the users. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060618/5e7e41fa/attachment-0001.htm 

From jeff.barczewski at gmail.com  Mon Jun 19 09:28:14 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 19 Jun 2006 08:28:14 -0500
Subject: [Masterview-devel] Plugin generator for gem installation
In-Reply-To: <20060619044242.FVHQ27967.fed1rmmtao08.cox.net@DLI92cx797990>
References: <19cda190606182105q2cdc5d5diee310fe09f4f6b3@mail.gmail.com>
	<20060619044242.FVHQ27967.fed1rmmtao08.cox.net@DLI92cx797990>
Message-ID: <19cda190606190628r11d64524yf18c7666170b7554@mail.gmail.com>

Good catch! I did change the spec and so it probably does pull too much
stuff into each gem, sorry I misunderstood you. I will go correct those
specs to be specific again.

I will take a look at the install guide.

Yes a nice top level index for docs would be great. If you have time and
want to start on this then that would be wonderful! I am heads down on
videos and after that a start of a release announcement which I will run by
you for approval. But you are right in that we need a structured index page
for the site for the launch too. If you have time to start breaking up lets
go for it. I will help once done with the other parts.

Jeff

On 6/18/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  I just did rebuild of the gems today to test.  Take a look at the
> generator rakefiles - you just changed both of them w/in the past few days
> to change from explicit masterview-XX-rb to "*.rb" in the include spec.
>
> Just finished working through rewrite for new doc/installation.html, after
> going through all the scenarios and (re)testing all the command descriptions
> etc.  Go over it and make any changes/additions I missed on this pass (or
> send me reminder of which areas to fix).
>
> I don't think I capture all the recent tweaks about admin stylesheets and
> auto-install of prototype settings files, we need to pick those up on
> another pass.
>
> Should I go ahead and start breaking up the original top-level index.htmlinto separate doc's or is that something you want to look at?  Suggest a
> main intro page, stripped down to overview and links to all the key
> sub-docs: install, config, User's Guide (doc/guide.html) and Directives
> Reference (doc/directives.html)
>
> ~ Deb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060619/9626b16b/attachment.htm 

From jeff.barczewski at gmail.com  Mon Jun 19 14:41:35 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 19 Jun 2006 13:41:35 -0500
Subject: [Masterview-devel] I added config.enable_view_rhtml which turns on
	ability to view rhtml from admin pages
Message-ID: <19cda190606191141n7b709dccn7f5c6fb6e3f5b091@mail.gmail.com>

I added config.enable_view_rhtml which turns on ability to view rhtml from
admin pages. Defaults to false for security purposes.

Turning this on creates links on the masterview admin page list which you
can click on the rhtml you want to view and it shows you the generated rhtml
in the browser. This will be quite useful for people to understand what it
is generating (especially when using generate_rhtml is false). Also for
debugging.

It allows them to try out directives and see if it has the desired effect
and if not why.

I also created a rake mv:view_rhtml RHTML=product/_form.rhtml which can be
used to view any of the rhtml files from the console.

That completes the utilities needed when we don't generate the rhtml any
more.

Now back to the videos.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060619/72cecee8/attachment.htm 

From djlewis at acm.org  Mon Jun 19 16:33:16 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 19 Jun 2006 13:33:16 -0700
Subject: [Masterview-devel] Docs reorganized and a bit of cleanup
Message-ID: <20060619203322.WCOS27967.fed1rmmtao08.cox.net@DLI92cx797990>

Broke up the original top-level index.html into: doc/index.html,
doc/guide.html, doc/directives.html (plus installation.html and
configuration.html that got started last week).

Did a bit for formatting and content-tweaking along the way; organized
directives ref's so that there are functional groupings presented as well as
alphabetiacal index (I often want have a purpose in mind when looking for
something, thus the fcnal pt of view)

Review/revise as desired; nuke the original top-level index.html if you're
happy with the new stuff.

Still needs misc. polishing and updates for some of our recent changes, I
think.

~ Deb

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
consider config default change: believe the admin controller should default
OFF, or at least only on by default in development environment - not clear
this should be on by default in production, developer probably needs to
consider access restriction issues in that env.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Couple comments on directives observed while going over all the doc entries:

mv:gen_render is kind of a funky name - if this is really only about
partials, then call it ... mv:gen_partial and simplify the attribute value.
If it's got more general uses in mind, include descr/example (fragment of
content vs. the specific rails notion of partial).

consider: might make sense for default semantics of mv:generate to be
mv:omit_tag="true", I think this is perhaps the normal usage, *unless*
specifically overridden by mv:omit_tag="false" *or* mv:gen_replace attribute
is also specified.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --



From djlewis at acm.org  Mon Jun 19 18:14:32 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 19 Jun 2006 15:14:32 -0700
Subject: [Masterview-devel] Your keyword changes look good,
	lets commit them Re: What I really want for {template_path}
	substitution semantics
In-Reply-To: <19cda190606182057g4bf7d83aoc98dffdae6ceb9ba@mail.gmail.com>
Message-ID: <20060619221438.DDFQ27967.fed1rmmtao08.cox.net@DLI92cx797990>

>> Your keyword expander changes look good, lets go ahead and turn those on.
 
ok, I'll flip the toggle switch over the "new and improved version" and
clean out the transition kruft when I have time tonight.
 
note to selves: directives.html need a section added to describe this new
keyword expansion feature.
 
one other possible tweak: maybe either a separate flavor of expand_keywords
or a defaulted parm so that the extra checking for whether to automatically
append .rhtml extension is only incurred by directives that need that
functionality?  (i.e., generate/import guys)
 
this would need to be hooked up in the proper places in parser/analyzer, so
I hadn't pursued that on first round of revision proposal.
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060619/69d8a24d/attachment.htm 

From jeff.barczewski at gmail.com  Mon Jun 19 18:18:23 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 19 Jun 2006 17:18:23 -0500
Subject: [Masterview-devel] Docs reorganized and a bit of cleanup
In-Reply-To: <20060619203322.WCOS27967.fed1rmmtao08.cox.net@DLI92cx797990>
References: <20060619203322.WCOS27967.fed1rmmtao08.cox.net@DLI92cx797990>
Message-ID: <19cda190606191518s41c9f346l1d3426b8c8b29848@mail.gmail.com>

Sounds good. See my comments below.

On 6/19/06, Deb Lewis <djlewis at acm.org> wrote:
>
> Broke up the original top-level index.html into: doc/index.html,
> doc/guide.html, doc/directives.html (plus installation.html and
> configuration.html that got started last week).
>
> Did a bit for formatting and content-tweaking along the way; organized
> directives ref's so that there are functional groupings presented as well
> as
> alphabetiacal index (I often want have a purpose in mind when looking for
> something, thus the fcnal pt of view)
>
> Review/revise as desired; nuke the original top-level index.html if you're
> happy with the new stuff.
>
> Still needs misc. polishing and updates for some of our recent changes, I
> think.
>
> ~ Deb
>
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> consider config default change: believe the admin controller should
> default
> OFF, or at least only on by default in development environment - not clear
> this should be on by default in production, developer probably needs to
> consider access restriction issues in that env.


Yes, we can make the default to be off, but lets have the default
environments/develoment.rb turn it on since I want to have it available for
users. That way if they have the latest configs it will be on for dev only.
If they don't then it is off.


-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> Couple comments on directives observed while going over all the doc
> entries:
>
> mv:gen_render is kind of a funky name - if this is really only about
> partials, then call it ... mv:gen_partial and simplify the attribute
> value.
> If it's got more general uses in mind, include descr/example (fragment of
> content vs. the specific rails notion of partial).


Yes, the name came from the combination of generate and render since it is
doing a generate of a partial and outputting a render :partial. I guess we
can rename it to gen_partial.


consider: might make sense for default semantics of mv:generate to be
> mv:omit_tag="true", I think this is perhaps the normal usage, *unless*
> specifically overridden by mv:omit_tag="false" *or* mv:gen_replace
> attribute
> is also specified.



On this one I left the outer tags in by default since if you are designing
in wysiwyg editor, you need to have the same number of divs in the
desigining view as what is rendered if you want the same output. If for
instance each div adds some sort of style (offset, linefeed, etc.). So by
automatically removing them could cause the output to look different than it
did in the editor. So on this point I would prefer people to add the
omit_tag if they really want it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060619/aaadb337/attachment.htm 

From jeff.barczewski at gmail.com  Mon Jun 19 18:19:39 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 19 Jun 2006 17:19:39 -0500
Subject: [Masterview-devel] Default log output to Info
Message-ID: <19cda190606191519u18468502r27e389d47ee41ed3@mail.gmail.com>

I was thinking that we should set our default log ouput to info. If you
agree, what do I change to make this happen?

Thanks,

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060619/331fc2e1/attachment.htm 

From jeff.barczewski at gmail.com  Mon Jun 19 18:22:04 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 19 Jun 2006 17:22:04 -0500
Subject: [Masterview-devel] Your keyword changes look good,
	lets commit them Re: What I really want for {template_path}
	substitution semantics
In-Reply-To: <20060619221438.DDFQ27967.fed1rmmtao08.cox.net@DLI92cx797990>
References: <19cda190606182057g4bf7d83aoc98dffdae6ceb9ba@mail.gmail.com>
	<20060619221438.DDFQ27967.fed1rmmtao08.cox.net@DLI92cx797990>
Message-ID: <19cda190606191522x5bbcba10o4d01359ea50d169a@mail.gmail.com>

yes I agree, that would be nice for non-generate/import guys to not get the
.rhtml expansion. However I would like to hold on that till after the
release if that is ok since it is internal change.

On 6/19/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  >> Your keyword expander changes look good, lets go ahead and turn those
> on.
>
> ok, I'll flip the toggle switch over the "new and improved version" and
> clean out the transition kruft when I have time tonight.
>
> note to selves: directives.html need a section added to describe this new
> keyword expansion feature.
>
> one other possible tweak: maybe either a separate flavor of
> expand_keywords or a defaulted parm so that the extra checking for whether
> to automatically append .rhtml extension is only incurred by directives that
> need that functionality?  (i.e., generate/import guys)
>
> this would need to be hooked up in the proper places in parser/analyzer,
> so I hadn't pursued that on first round of revision proposal.
>
> ~ 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/20060619/372dde23/attachment-0001.htm 

From jeff.barczewski at gmail.com  Mon Jun 19 18:38:58 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 19 Jun 2006 17:38:58 -0500
Subject: [Masterview-devel] Docs reorganized and a bit of cleanup
In-Reply-To: <19cda190606191518s41c9f346l1d3426b8c8b29848@mail.gmail.com>
References: <20060619203322.WCOS27967.fed1rmmtao08.cox.net@DLI92cx797990>
	<19cda190606191518s41c9f346l1d3426b8c8b29848@mail.gmail.com>
Message-ID: <19cda190606191538i5b62e404s944f770506920e41@mail.gmail.com>

I took care of the default enable_admin_pages false and updated
configuration.html default (I think, just in the one place, not sure if
other mentions).

We need to do a global search and replace on gen_render to become
gen_partial.

I have to run right now but if you don't get to it first then I will do it
tomorrow morning. I went through a good video sequence, so once I do the
global replace then I will create the video and a draft announcement which I
will send both to you for review.

Hoping to do a release sometime tomorrow if everything goes well and you are
ok with it.

Looks like they are going to have a show and tell session on Friday that I
can potentially use to show what we are doing at the rails conference. Cool!

Either way would like to get the release out Tuesday or Wednesday at the
very latest. I'm traveling Thursday.


Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060619/99e9fe7e/attachment.htm 

From djlewis at acm.org  Mon Jun 19 20:05:17 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 19 Jun 2006 17:05:17 -0700
Subject: [Masterview-devel] Default log output to Info
In-Reply-To: <19cda190606191519u18468502r27e389d47ee41ed3@mail.gmail.com>
Message-ID: <20060620000522.RKAK24290.fed1rmmtao09.cox.net@DLI92cx797990>

>> I was thinking that we should set our default log ouput to info. 
>> If you agree, what do I change to make this happen?
 
Yes, agree.  Actually, I'd even say change default level to WARN, with maybe
INFO used for development.
 
All we should have to do is fiddle the init expression in
Configuration#initialize at line 489:
 
      self.log_level = nil  # use the default level of the logger
 
to, say:
 
      self.log_level = (self.environment == 'development') ? 'INFO' : 'WARN'
 
(and fix the rdoc comment and doc/configuration.html)
 
And then extras/init_logger.rb should take care of the rest.  If the config
has a value specified for log_level, it installs it; if log_level is nil, it
leaves whatever the configured logger has as its default alone.
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060619/4ea9f19d/attachment.htm 

From djlewis at acm.org  Mon Jun 19 20:11:23 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 19 Jun 2006 17:11:23 -0700
Subject: [Masterview-devel] Docs reorganized and a bit of cleanup
In-Reply-To: <19cda190606191538i5b62e404s944f770506920e41@mail.gmail.com>
Message-ID: <20060620001130.UBTA19317.fed1rmmtao03.cox.net@DLI92cx797990>

>> Hoping to do a release sometime tomorrow if everything goes well 
>> and you are ok with it. .. Looks like they are going to have a show and
tell 
>> session on Friday that I can potentially use to show what we are doing at
the rails conference. 
 
Yes, let's get this stabilized and released, there's a lot of really good
improvements.  I'd say go for Tue if possible, that gives us one last day
for finding any bugs/polishing things before you hit the road Thu.
 
My expectation: we'll have a fairly quick turnaround to putting out a 0.2.1
update to fix loose ends, but I think it's fine if we push out 0.2.0 with a
few rough edges.  I'd characterize us at having an alpha-level facility,
maybe about to settle enough that we can all it beta.  My criteria for
declaring beta-ness would be that we believe the basic structure and
protocols are solid and not likely to change.
 
And I can do any last-minute patching on Thursday if you needed something by
Friday.  By all means, get in on the show-and-tell if you can!!  That'll be
an excellent way to get the word out and get some exposure.
 
I'll try to suppress the urge to do cool new stuff this week and stay
focused on docs and polishing so this looks good to the world.
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060619/da2e3b87/attachment.htm 

From djlewis at acm.org  Tue Jun 20 04:59:50 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 20 Jun 2006 01:59:50 -0700
Subject: [Masterview-devel] Your keyword changes look good,
	lets commit them Re: What I really want for {template_path}
	substitution semantics
In-Reply-To: <19cda190606191522x5bbcba10o4d01359ea50d169a@mail.gmail.com>
Message-ID: <20060620085956.EXRB11027.fed1rmmtao07.cox.net@DLI92cx797990>

agree, we can polish that later.  I left us a comment in the code that we
should revisit when the extension-defaulting takes place, but for now it's
just always checked.
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Monday, June 19, 2006 3:22 PM
To: djlewis at acm.org; masterview-devel at rubyforge.org
Subject: Re: [Masterview-devel] Your keyword changes look good, lets commit
them Re: What I really want for {template_path} substitution semantics


yes I agree, that would be nice for non-generate/import guys to not get the
.rhtml expansion. However I would like to hold on that till after the
release if that is ok since it is internal change.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060620/0b207680/attachment.htm 

From djlewis at acm.org  Tue Jun 20 04:59:50 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 20 Jun 2006 01:59:50 -0700
Subject: [Masterview-devel] Docs reorganized and a bit of cleanup
In-Reply-To: <19cda190606191518s41c9f346l1d3426b8c8b29848@mail.gmail.com>
Message-ID: <20060620090006.EXTE11027.fed1rmmtao07.cox.net@DLI92cx797990>

RE: proposal to consider haveing mv:generate omit its tag by default
 
your counterargument is good, we leave as-is.  For the particular way I
happen to be doing things I do use mv:omit_tag="" with all my main content
generation directives, which are div's whose sole purpose is to provide a
place to hang the mv:generate directive.
 
But agree it's safer to leave the (possibly unnecessary ) tag than it is to
be overly aggressive about dropping it out.
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Monday, June 19, 2006 3:18 PM
To: djlewis at acm.org; masterview-devel at rubyforge.org
Subject: Re: [Masterview-devel] Docs reorganized and a bit of cleanup


Sounds good. See my comments below.


 .....snipped...
 

consider: might make sense for default semantics of mv:generate to be
mv:omit_tag="true", I think this is perhaps the normal usage, *unless* 
specifically overridden by mv:omit_tag="false" *or* mv:gen_replace attribute
is also specified.


On this one I left the outer tags in by default since if you are designing
in wysiwyg editor, you need to have the same number of divs in the
desigining view as what is rendered if you want the same output. If for
instance each div adds some sort of style (offset, linefeed, etc.). So by
automatically removing them could cause the output to look different than it
did in the editor. So on this point I would prefer people to add the
omit_tag if they really want it. 

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

From jeff.barczewski at gmail.com  Tue Jun 20 06:42:23 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Tue, 20 Jun 2006 05:42:23 -0500
Subject: [Masterview-devel] Docs reorganized and a bit of cleanup
In-Reply-To: <20060620001130.UBTA19317.fed1rmmtao03.cox.net@DLI92cx797990>
References: <19cda190606191538i5b62e404s944f770506920e41@mail.gmail.com>
	<20060620001130.UBTA19317.fed1rmmtao03.cox.net@DLI92cx797990>
Message-ID: <19cda190606200342m39ad4308tc2a509f8a408af65@mail.gmail.com>

Sounds like a plan!!

On 6/19/06, Deb Lewis <djlewis at acm.org> wrote:
>
> Yes, let's get this stabilized and released, there's a lot of really good
> improvements.  I'd say go for Tue if possible, that gives us one last day
> for finding any bugs/polishing things before you hit the road Thu.
>
> My expectation: we'll have a fairly quick turnaround to putting out a
> 0.2.1 update to fix loose ends, but I think it's fine if we push out 0.2.0with a few rough edges.  I'd characterize us at having an alpha-level
> facility, maybe about to settle enough that we can all it beta.  My criteria
> for declaring beta-ness would be that we believe the basic structure and
> protocols are solid and not likely to change.
>
> And I can do any last-minute patching on Thursday if you needed something
> by Friday.  By all means, get in on the show-and-tell if you can!!  That'll
> be an excellent way to get the word out and get some exposure.
>
> I'll try to suppress the urge to do cool new stuff this week and stay
> focused on docs and polishing so this looks good to the world.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060620/8bf87757/attachment-0001.htm 

From jeff.barczewski at gmail.com  Tue Jun 20 13:39:24 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Tue, 20 Jun 2006 12:39:24 -0500
Subject: [Masterview-devel] Draft ANN MasterView rails-optimized (x)HTML
	friendly template engine plugin - release 0.2.0
Message-ID: <19cda190606201039w4e92f3dbqea99ad3f0c1e337@mail.gmail.com>

Deb,

Here is a draft of the announcement, please feel free to update or suggest
changes as you see fit. Should I use the
masterview-users at rubyforge.orgemail account for feedback and
questions? I think I set it up to allow
anyone to post to it.

Jeff

----------------------------------

MasterView rails-optimized (x)HTML friendly template engine plugin - Release
0.2.0

The MasterView development team is pleased to announce the general
availability of MasterView release 0.2.0. MasterView is a rails-optimized
XHTML friendly template engine plugin that was launched in January of 2006.
Building on the suggestions of early users, the MasterView project has been
enhanced for better team usage and for easier configuration/upgrading.

If you are looking for a template engine that gives you all the power of
layout, partials, helpers, but still is editable in a WYSIWYG editor then
check out this project. Let designers work on the design while developers
focus on coding. The MasterView generator creates usable styleable templates
that can be easily customized to your needs or start straight from your html
prototype and add MasterView attribute directives straight to those files.
You can redit those same template files at any time in your development life
cycle to update html layout and style.

Video
A quick start video which demos basic operation is available at
http://masterview.org/videos/masterview_quick_start.html

MasterView is released under MIT open source licensing.

Main site: http://masterview.org/
Rubyforge Project site: http://rubyforge.org/projects/masterview


Goals

   - Create/extend a template engine for rails that would be XHTML
   friendly and thus could be edited/styled with a WYSIWYG HTML editor even
   late in development without breaking template.
   - Keep it simple. DRY. No extra config files, simple syntax with ruby
   flavor.
   - Design it specifically for ruby and rails. Use the full power and
   not be limited in its capabilities over what can be done with ERb
   - Work nicely with layouts, partials, and rails html helpers.
   - Reduce complexity, work with existing rails code, no extra view
   logic or hashes than what is used by ERb. Scaffold generate initial
   templates or work from existing html prototype.
   - Reduce the numbers of files, simplifying editing. Define partials
   and layouts naturallyl right in the template, no need to go to another file.

   - Preview in browser without running an app. Allow for dummy data in
   the template so that the page can be viewed and styled independently of the
   application.
   - Performance equal to ERb

Release Notes

   - Ability to easily utilize multiple template files for a controller
   making it easier to work together as a team on files and to keep file sizes
   manageable.
   - Rails like configuration system which provides a clean way to
   configure options
   - MasterView admin pages for working with templates
   - Rake utilities to provide command line capabilities equal to those
   in MasterView admin pages.
   - Configuration and documentation cleanup.
   - Keyword expansions for generate and import directives.

Installation - several options (gem install or plugin install)

   - As a gem - gem install masterview_gem_pack; cd railsapp;
   script/generate masterview_plugin
   - As a pure plugin using plugin install - script/plugin install
   svn://rubyforge.org/var/svn/masterview/tags/masterview
   - As a pure plugin download from rubyforge - download
masterview.tgzor .zip and extract to
railsapp/vendor/plugins/masterview

We would love to hear your feedback and ideas around this project!

Thanks for your time!


MasterView Development Team
Jeff Barczewski and Deb Lewis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060620/5b2f454b/attachment.html 

From jeff.barczewski at gmail.com  Wed Jun 21 08:13:02 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 21 Jun 2006 07:13:02 -0500
Subject: [Masterview-devel] Check to see that all your latest changes are in
	the repository
Message-ID: <19cda190606210513g31798a88uf87c17297bd9003f@mail.gmail.com>

Deb,

Check to see that all your latest changes are in the repository. When I
connected today it only had version 152 and I was on 154, so they might have
missed a few things in the switch. I uploaded a change that I made to
Rakefile that I believe was 154. I could not find any details about 153.

Some of the last things you were working on were updating the RELEASE_NOTES
and such, so double check that. Once we have verified it I will do a release
this morning.

Thanks,

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060621/816fb021/attachment.html 

From jeff.barczewski at gmail.com  Wed Jun 21 10:30:04 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 21 Jun 2006 09:30:04 -0500
Subject: [Masterview-devel] I have uploaded latest docs to masterview.org
Message-ID: <19cda190606210730s7e4544d4lb3a187893b70a2d4@mail.gmail.com>

I updated the docs some and have uploaded the latest docs to masterview.org,
did you say you had created a toolbar for the pages? It wasn't in the one in
svn.

If you could do one last check of your svn,  then if you give me the ok
we'll do a release and send out an announcement.

Thanks for all your hard work!! The docs you reworked look great!!

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060621/fbc7d268/attachment.html 

From dlewis at glaivestone.com  Wed Jun 21 11:14:12 2006
From: dlewis at glaivestone.com (Deb Lewis)
Date: Wed, 21 Jun 2006 08:14:12 -0700
Subject: [Masterview-devel] I have uploaded latest docs to masterview.org
In-Reply-To: <19cda190606210730s7e4544d4lb3a187893b70a2d4@mail.gmail.com>
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAUqR4yTf5ykqE6vl3UNgBQgKCAAAQAAAAXgQo1X1FRkiWfyvVdjVFYgEAAAAA@glaivestone.com>

Yep, lost some of the changes I put in late yesterday morning in the doc
files.  I'll recheck all the changes I put in yesterday morning (doc files
and some changes in release notes,change log...)
 
Upgrading and reinstalling my firewall seems to have solved the baffling
problems I've been having since last week with file edits not resulting in
updated mtimes.  grrrr....
 
One more thought about the release message: we should include a short note
on upgrading from prev. release of MV, existing users *must* redo their
config setups if customized and need to review where their template files
live.  
 
We need to have a stable url that we can point to where the latest release's
release note are posted so users always have a reliable place to go to get a
preview of changes and upgrade notes before picking up new build.  Drive me
nuts when packages don't provide this info (well geez... what happened and
do I need to know anything important before I install newer version??)
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Wednesday, June 21, 2006 7:30 AM
To: dlewis at glaivestone.com; masterview-devel at rubyforge.org
Subject: I have uploaded latest docs to masterview.org


I updated the docs some and have uploaded the latest docs to masterview.org,
did you say you had created a toolbar for the pages? It wasn't in the one in
svn.

If you could do one last check of your svn,  then if you give me the ok
we'll do a release and send out an announcement. 

Thanks for all your hard work!! The docs you reworked look great!!

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060621/ffeca10c/attachment.html 

From jeff.barczewski at gmail.com  Wed Jun 21 11:41:47 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 21 Jun 2006 10:41:47 -0500
Subject: [Masterview-devel] I have uploaded latest docs to masterview.org
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAUqR4yTf5ykqE6vl3UNgBQgKCAAAQAAAAXgQo1X1FRkiWfyvVdjVFYgEAAAAA@glaivestone.com>
References: <19cda190606210730s7e4544d4lb3a187893b70a2d4@mail.gmail.com>
	<!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAUqR4yTf5ykqE6vl3UNgBQgKCAAAQAAAAXgQo1X1FRkiWfyvVdjVFYgEAAAAA@glaivestone.com>
Message-ID: <19cda190606210841i40eb76adq415d611fd80b5564@mail.gmail.com>

On 6/21/06, Deb Lewis <dlewis at glaivestone.com> wrote:
>
>  Yep, lost some of the changes I put in late yesterday morning in the doc
> files.  I'll recheck all the changes I put in yesterday morning (doc files
> and some changes in release notes,change log...)
>

Sounds great, just let me know when things are ready and we can do the
release then.


Upgrading and reinstalling my firewall seems to have solved the baffling
> problems I've been having since last week with file edits not resulting in
> updated mtimes.  grrrr....
>
> One more thought about the release message: we should include a short note
> on upgrading from prev. release of MV, existing users *must* redo their
> config setups if customized and need to review where their template files
> live.
>

Yes, I will add something about that.


We need to have a stable url that we can point to where the latest release's
> release note are posted so users always have a reliable place to go to get a
> preview of changes and upgrade notes before picking up new build.  Drive me
> nuts when packages don't provide this info (well geez... what happened and
> do I need to know anything important before I install newer version??)
>

Agreed. Our change_log will be a living document, but it probably doesn't
have the details needed for what you described.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060621/49a3408e/attachment.html 

From djlewis at acm.org  Wed Jun 21 13:39:38 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 21 Jun 2006 10:39:38 -0700
Subject: [Masterview-devel] Salvage operation completed
Message-ID: <20060621173943.MIZD18458.fed1rmmtao10.cox.net@DLI92cx797990>

my that was fun - took two hours to re-create 20 min. of work

Plz run your fresh eyeballs over the docs and top-level release files to
make sure I didn't miss anything.  Tried to catch some update synching from
your last changes in doc/index.html in the project summary section into the
other docs that have copies of that same info.

~ Deb



From jeff.barczewski at gmail.com  Wed Jun 21 14:39:58 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 21 Jun 2006 13:39:58 -0500
Subject: [Masterview-devel] MasterView 0.2.0 is released
Message-ID: <19cda190606211139s76251554o9a5fdf81bfdc5ba8@mail.gmail.com>

MasterView 0.2.0 is released.

Should be available for gem download soon (in the past it seemed to take 30
minutes or so for the update to be there, don't know if the same is true for
current hardware).

I have updated the docs on masterview.org with those from docs.

Last thing to do is to send out release announcement to rails and
masterview-announce list. I will wait for gem to be available and then will
send it out.

Thanks for all your hard work Deb, it really looks good!

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060621/97cdb88c/attachment.html 

From djlewis at acm.org  Wed Jun 21 15:38:13 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 21 Jun 2006 12:38:13 -0700
Subject: [Masterview-devel] MasterView 0.2.0 is released
In-Reply-To: <19cda190606211139s76251554o9a5fdf81bfdc5ba8@mail.gmail.com>
Message-ID: <20060621193817.XESL19057.fed1rmmtao12.cox.net@DLI92cx797990>

Jeff - outstanding!  Lot of good stuff in this update and I'm looking
forward to tackling some additional problems (better image support, multiple
name spaces for directives).
 
I just stored a couple comment fixes in the prototype config settings files
- you probably didn't pick up for the build, but that's ok, they're not
critical.
 
One more thing we need to do today is create the release tags in the
repository.  Might need to be a bit careful (sorry, my bad): rev. 159 was
your final tweaks to release docs;  revs 160-162 were my config file updates
(examples + cloned copies for plugin generator).
 
Believe tags/masterview-0.2.0 should be copy of rev. 159, what you probably
had when you ran the build; then we delete and recreate tags/masterview as a
copy of tags/masterview-0.2.0.
 
I'll do that later today if you want.  [and add to our TODO: automate this
in our rakefile before we do next release!]
 
and thx for the nice plug in your updated docs.  It's a pleasure working
with you!  Have a great time at RailsConf, hopefully you can get some
visibility and we can get some feedback and users.
 
~ Deb

  _____  

From: masterview-devel-bounces at rubyforge.org
[mailto:masterview-devel-bounces at rubyforge.org] On Behalf Of Jeff Barczewski
Sent: Wednesday, June 21, 2006 11:40 AM
To: dlewis at glaivestone.com; masterview-devel at rubyforge.org
Subject: [Masterview-devel] MasterView 0.2.0 is released


MasterView 0.2.0 is released. 

Should be available for gem download soon (in the past it seemed to take 30
minutes or so for the update to be there, don't know if the same is true for
current hardware).

I have updated the docs on masterview.org with those from docs.

Last thing to do is to send out release announcement to rails and
masterview-announce list. I will wait for gem to be available and then will
send it out. 

Thanks for all your hard work Deb, it really looks good!

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060621/9ddd3ea0/attachment.html 

From jeff.barczewski at gmail.com  Wed Jun 21 16:19:33 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 21 Jun 2006 15:19:33 -0500
Subject: [Masterview-devel] MasterView 0.2.0 is released
In-Reply-To: <20060621193817.XESL19057.fed1rmmtao12.cox.net@DLI92cx797990>
References: <19cda190606211139s76251554o9a5fdf81bfdc5ba8@mail.gmail.com>
	<20060621193817.XESL19057.fed1rmmtao12.cox.net@DLI92cx797990>
Message-ID: <19cda190606211319uf413adfoc8603f7af0ed3111@mail.gmail.com>

I fired off the announcement to rails mailing list and to
masterview-announce, let me know if you don't get it. It showed up in the
archives for masterview-announce and on the rails mailing list web bridge
but I didn't get it directly probably because I sent it.

Do we need to post to masterview-users as well or simply to
masterview-announce? I would think just the announce list.

If you have time yes, make the release tag, I didn't do that yet. I am going
to be busy this afternoon with other work. I will keep you posted from the
conference, I think they will have wireless. There might even be an
opportunity for me to demo it starting tomorrow, they are going to have a
room for adhoc presentations for the early arrivals.

Jeff


On 6/21/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  Jeff - outstanding!  Lot of good stuff in this update and I'm looking
> forward to tackling some additional problems (better image support, multiple
> name spaces for directives).
>
> I just stored a couple comment fixes in the prototype config settings
> files - you probably didn't pick up for the build, but that's ok, they're
> not critical.
>
> One more thing we need to do today is create the release tags in the
> repository.  Might need to be a bit careful (sorry, my bad): rev. 159 was
> your final tweaks to release docs;  revs 160-162 were my config file updates
> (examples + cloned copies for plugin generator).
>
> Believe tags/masterview-0.2.0 should be copy of rev. 159, what you
> probably had when you ran the build; then we delete and recreate
> tags/masterview as a copy of tags/masterview-0.2.0.
>
> I'll do that later today if you want.  [and add to our TODO: automate this
> in our rakefile before we do next release!]
>
> and thx for the nice plug in your updated docs.  It's a pleasure working
> with you!  Have a great time at RailsConf, hopefully you can get some
> visibility and we can get some feedback and users.
>
> ~ Deb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060621/e573dd4d/attachment.html 

From djlewis at acm.org  Wed Jun 21 16:27:31 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 21 Jun 2006 13:27:31 -0700
Subject: [Masterview-devel] MasterView 0.2.0 is released
In-Reply-To: <19cda190606211319uf413adfoc8603f7af0ed3111@mail.gmail.com>
Message-ID: <20060621202735.POGL6235.fed1rmmtao06.cox.net@DLI92cx797990>

I rcv'd from both -devel and -announce.  And yes, should also send to
-users.  That's fairly customary, I think (i get double-announcements from
lists where I'm on both user and announce lists, eg. subversion and
subclipse)
 
I'll take care of the release tag.
 
~ Deb

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060621/2ceda291/attachment.html 

From djlewis at acm.org  Wed Jun 21 16:42:17 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 21 Jun 2006 13:42:17 -0700
Subject: [Masterview-devel] MasterView release tags published for 0.2.0 build
Message-ID: <20060621204221.TORP554.fed1rmmtao11.cox.net@DLI92cx797990>

done

~ Deb

--SVN console log from Subclipse (a bit slow via my auth login, but
otherwise extremely good for managing changes and synching, i do love
eclipse)

copy -r159
svn+ssh://djlewis-auth-rubyforge.org/var/svn/masterview/trunk/masterview
svn+ssh://djlewis-auth-rubyforge.org/var/svn/masterview/tags/masterview-0.2.
0

delete -m "Reset tags/masterview to masterview-0.2.0 release build
[21-Jun-2006]"
svn+ssh://djlewis-auth-rubyforge.org/var/svn/masterview/tags/masterview

copy -rHEAD
svn+ssh://djlewis-auth-rubyforge.org/var/svn/masterview/tags/masterview-0.2.
0 svn+ssh://djlewis-auth-rubyforge.org/var/svn/masterview/tags/masterview



From jeff.barczewski at gmail.com  Wed Jun 21 16:44:49 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 21 Jun 2006 15:44:49 -0500
Subject: [Masterview-devel] MasterView release tags published for 0.2.0
	build
In-Reply-To: <20060621204221.TORP554.fed1rmmtao11.cox.net@DLI92cx797990>
References: <20060621204221.TORP554.fed1rmmtao11.cox.net@DLI92cx797990>
Message-ID: <19cda190606211344if00d105xa10e98d11a7ebd63@mail.gmail.com>

Wonderful!! Thanks. I emailed the masterview-users list as well.

On 6/21/06, Deb Lewis <djlewis at acm.org> wrote:
>
> done
>
> ~ Deb
>
> --SVN console log from Subclipse (a bit slow via my auth login, but
> otherwise extremely good for managing changes and synching, i do love
> eclipse)
>
> copy -r159
> svn+ssh://djlewis-auth-rubyforge.org/var/svn/masterview/trunk/masterview
> svn+ssh://djlewis-
> auth-rubyforge.org/var/svn/masterview/tags/masterview-0.2.
> 0
>
> delete -m "Reset tags/masterview to masterview-0.2.0 release build
> [21-Jun-2006]"
> svn+ssh://djlewis-auth-rubyforge.org/var/svn/masterview/tags/masterview
>
> copy -rHEAD
> svn+ssh://djlewis-
> auth-rubyforge.org/var/svn/masterview/tags/masterview-0.2.
> 0 svn+ssh://djlewis-auth-rubyforge.org/var/svn/masterview/tags/masterview
>
>
> _______________________________________________
> 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/20060621/9f37e63a/attachment-0001.html 

From djlewis at acm.org  Wed Jun 21 17:03:11 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 21 Jun 2006 14:03:11 -0700
Subject: [Masterview-devel] How to we post release announcement on RubyForge
	news page?
Message-ID: <20060621210315.RLKF22974.fed1rmmtao01.cox.net@DLI92cx797990>

I can't do that op on our project area w/out Admin access, it seems.

Also added to TODO: get the user docs (?and rdoc?) posted on Docs tab of
rubyforge

~ Deb 



From jeff.barczewski at gmail.com  Wed Jun 21 17:30:40 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 21 Jun 2006 16:30:40 -0500
Subject: [Masterview-devel] How to we post release announcement on
	RubyForge news page?
In-Reply-To: <20060621210315.RLKF22974.fed1rmmtao01.cox.net@DLI92cx797990>
References: <AcaVdhnMXthrLEBWRgy4nNx09bGtCg==>
	<20060621210315.RLKF22974.fed1rmmtao01.cox.net@DLI92cx797990>
Message-ID: <19cda190606211430h4ace9109q8bf10a95e161b787@mail.gmail.com>

I posted a news article to our project. It didn't say on the page how to get
it added to rubyforge home page but said that it was a moderated thing. Not
sure if I have to email anyone or whether it will potentially just get
picked up.

I will make a note to add you to the news admin.

Jeff

On 6/21/06, Deb Lewis <djlewis at acm.org> wrote:
>
> I can't do that op on our project area w/out Admin access, it seems.
>
> Also added to TODO: get the user docs (?and rdoc?) posted on Docs tab of
> rubyforge
>
> ~ 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/20060621/7ce253fc/attachment.html 

From jeff.barczewski at gmail.com  Mon Jun 26 14:53:28 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 26 Jun 2006 13:53:28 -0500
Subject: [Masterview-devel] We are now on Rubyforge.org front page news
	items, rubyforge mailing lists still not up?,
	Dave Thomas was interested in our project
Message-ID: <19cda190606261153m7b8b102cid55f5d01e6bd9358@mail.gmail.com>

I guess they finally added our news item to the front page. Not sure if you
had done anything special or whether they just read our news and added it to
front.

I guess mailing lists are not working, no emails since June 21st.

I made a few commits this morning. One to add image_tag and to add support
for Mongrel.

Rails conference was great! I talked with Dave Thomas and he was interested
in the project, wanted me to send him an email after the conference so he
can take a look. He also thought Justin Ghetland and Stuart Holloway would
be interested.

Will fill you in more later.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060626/1dc70491/attachment.html 

From djlewis at acm.org  Mon Jun 26 15:22:39 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 26 Jun 2006 12:22:39 -0700
Subject: [Masterview-devel] We are now on Rubyforge.org front page news
	items, rubyforge mailing lists still not up?,
	Dave Thomas was interested in our project
In-Reply-To: <19cda190606261153m7b8b102cid55f5d01e6bd9358@mail.gmail.com>
Message-ID: <20060626192243.HHO18458.fed1rmmtao10.cox.net@DLI92cx797990>

excellent!  No, haven't done anything since the release, aside from dropping
some reminder notes in TODO; ended up fire-fighting a work emergency most of
the w/e, so anxious to get back to some MV things soon.
 
Dave Thomas liked the idea?  most excellent!  Do copy me on mail to him if
there's some followup discusion, would like to hear his feedback.
 
I gave a short talk on MV to my local ocruby group last thursday - just
impromptu to a few folks, but they liked it and thought it might fill a real
need in the Rails world.  I've asked for a presentation slot in upcoming mtg
to give a prepared presentation when I have a chance to organize some
material. 
 
Observation on the video: it's too long.  Needs to be about 10 minutes,
after that we start losing the audience (like... me! I still haven't made it
through to the end!  That's what happened by my ocruby group when we started
watching it as well).  Maybe can prune the middle section demonstrating
various edits to the templates from std WYSIWYG editor - one or two quick
examples (change some text, fiddle a style or layout) would be sufficient to
get the idea across.  Maybe also one or two diagram shots to depict overview
of what's happening (here's how your templates fit into rails...) - that
could be a good addition to the docs in any case, we can put this on our
docs todo list.
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Monday, June 26, 2006 11:53 AM
To: dlewis at glaivestone.com; masterview-devel at rubyforge.org
Subject: We are now on Rubyforge.org front page news items, rubyforge
mailing lists still not up?, Dave Thomas was interested in our project


I guess they finally added our news item to the front page. Not sure if you
had done anything special or whether they just read our news and added it to
front.

I guess mailing lists are not working, no emails since June 21st. 

I made a few commits this morning. One to add image_tag and to add support
for Mongrel.

Rails conference was great! I talked with Dave Thomas and he was interested
in the project, wanted me to send him an email after the conference so he
can take a look. He also thought Justin Ghetland and Stuart Holloway would
be interested. 

Will fill you in more later.

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060626/524ac7c5/attachment.html 

From jeff.barczewski at gmail.com  Mon Jun 26 18:31:52 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 26 Jun 2006 17:31:52 -0500
Subject: [Masterview-devel] test to masterview-devel
Message-ID: <19cda190606261531p53e35d37vf410578d46b83538@mail.gmail.com>

test
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060626/0c654d04/attachment.html 

From jeff.barczewski at gmail.com  Mon Jun 26 01:22:24 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 26 Jun 2006 00:22:24 -0500
Subject: [Masterview-devel] MasterView generation from existing rhtml
In-Reply-To: <0e5401c698d9$b2aff900$0402a8c0@sergeyl>
References: <0e5401c698d9$b2aff900$0402a8c0@sergeyl>
Message-ID: <19cda190606252222s37b821edk2841f541ddc08abd@mail.gmail.com>

Sergey,

I haven't come up with a way to take existing rhtml and create xhtml from
them. However you can co-exist with existing rhtml nicely. You can have some
thing in masterview templates and other things in simple rhtml and use both
interchangeably in your project.

If you want to view the generated rhtml files simply to see what masterview
is generating behind the scenes then simply do rake mv:view_rhtml
RHTML=store/list.html and it will output to stdout.

If you want to generate the files to the filesystem so that they will be
loaded from there then you can change the  setting in
config/masterview/setting.rb like so
config.generate_rhtml_files = true
When this setting is set it will generate rhtml to the file system and it
will be loaded from there just like your existing rhtml.

Refreshing the browser will reparse the template (and regenerate the rhtml).

You can also kick off rhtml generation from the command line using rake
mv:parse

Let me know if this all makes sense and answers your questions.

All the best,

Jeff


On 6/25/06, Sergey Shalatskiy <sshalatskiy at guerillaviralmarketing.com>
wrote:
>
>  Hi Jeff,
>
> MasterView is excellent! Just a couple of questions:
>
> Is it possible to generate (x)html from existing rhtml etc. ?
> It is very important if someone wants to switch to masteview from regular
> rails apps.
> Possibly, it would be also convenient to have an option to use existing
> files without regeneration, as you mentioned in one of your messages on
> forum.
> Also, I was not able to generate rhtml files from masterview templates.
> How do I do that? It looks like in order to smoothly upgrade existing
> projects,
> we need roundtrip options. It will help a lot to understand the framework
> better and switch to MasterView quickly. Complex applications will require a
> lot of manual
> work if there is no such options.
>
> Thanks
>
> Sergey Shalatskiy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060626/c3f35ce5/attachment-0001.html 

From jeff.barczewski at gmail.com  Mon Jun 26 12:30:16 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 26 Jun 2006 11:30:16 -0500
Subject: [Masterview-devel] MasterView generation from existing rhtml
In-Reply-To: <0e6201c698f1$f4e53480$0402a8c0@sergeyl>
References: <0e5401c698d9$b2aff900$0402a8c0@sergeyl>
	<19cda190606252222s37b821edk2841f541ddc08abd@mail.gmail.com>
	<0e6201c698f1$f4e53480$0402a8c0@sergeyl>
Message-ID: <19cda190606260930u31de6dfcx523aa7c142fcafdb@mail.gmail.com>

Yes, I think what you mentioned could work but the only when I was thinking
through this a while back I was having trouble figuring out how to know what
all pieces (rhtml partials and layouts) to pull in. Honestly I didn't spend
much time looking at it but it did seem like it would be a nice thing to do
if possible.

I will put it on the todo list.

Thanks for the idea and approach.

Jeff

On 6/26/06, Sergey Shalatskiy <sshalatskiy at guerillaviralmarketing.com>
wrote:
>
>  Jeff,
>
> Thanks for a quick answer. It helped a lot.
> Regarding the issue with generating html from rhtml, I don't see why it
> can be difficult. If the difficulty you see is in converting the erb
> statements, you could use erb itself, I believe, by replacing standard rails
> methods for things like
> error_messages_for, or any other methods that have equivalents in
> MasterView directives, by masterview proxies that generate its own output by
> converting them into directives. Basically, it seems to me, you just need a
> reverse method for every directive. The rest is to combine everything in a
> template and generate html per every rhtml.
> Not sure, though, what to do with rjs files, if anything.
> Although, maybe I oversimplify things here.
> Does it make sense to you?
>
> Thanks,
>
> Sergey Shalatskiy
>
>
> ----- Original Message -----
> *From:* Jeff Barczewski <jeff.barczewski at gmail.com>
> *To:* Sergey Shalatskiy <sshalatskiy at guerillaviralmarketing.com>
> *Sent:* Monday, June 26, 2006 1:22 AM
> *Subject:* Re: MasterView generation from existing rhtml
>
> Sergey,
>
> I haven't come up with a way to take existing rhtml and create xhtml from
> them. However you can co-exist with existing rhtml nicely. You can have some
> thing in masterview templates and other things in simple rhtml and use both
> interchangeably in your project.
>
> If you want to view the generated rhtml files simply to see what
> masterview is generating behind the scenes then simply do rake mv:view_rhtml
> RHTML=store/list.html and it will output to stdout.
>
> If you want to generate the files to the filesystem so that they will be
> loaded from there then you can change the  setting in
> config/masterview/setting.rb like so
> config.generate_rhtml_files = true
> When this setting is set it will generate rhtml to the file system and it
> will be loaded from there just like your existing rhtml.
>
> Refreshing the browser will reparse the template (and regenerate the
> rhtml).
>
> You can also kick off rhtml generation from the command line using rake
> mv:parse
>
> Let me know if this all makes sense and answers your questions.
>
> All the best,
>
> Jeff
>
>
> On 6/25/06, Sergey Shalatskiy <sshalatskiy at guerillaviralmarketing.com>
> wrote:
> >
> >  Hi Jeff,
> >
> > MasterView is excellent! Just a couple of questions:
> >
> > Is it possible to generate (x)html from existing rhtml etc. ?
> > It is very important if someone wants to switch to masteview from
> > regular rails apps.
> > Possibly, it would be also convenient to have an option to use existing
> > files without regeneration, as you mentioned in one of your messages on
> > forum.
> > Also, I was not able to generate rhtml files from masterview templates.
> > How do I do that? It looks like in order to smoothly upgrade existing
> > projects,
> > we need roundtrip options. It will help a lot to understand the
> > framework better and switch to MasterView quickly. Complex applications will
> > require a lot of manual
> > work if there is no such options.
> >
> > Thanks
> >
> > Sergey Shalatskiy
> >
>
>  ------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.9.4/375 - Release Date: 6/25/2006
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060626/1f4168c3/attachment-0001.html 

From jeff.barczewski at gmail.com  Mon Jun 26 18:17:48 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 26 Jun 2006 17:17:48 -0500
Subject: [Masterview-devel] MasterView generation from existing rhtml
In-Reply-To: <000b01c69963$f00aa7c0$3e01a8c0@sergeyl>
References: <0e5401c698d9$b2aff900$0402a8c0@sergeyl>
	<19cda190606252222s37b821edk2841f541ddc08abd@mail.gmail.com>
	<0e6201c698f1$f4e53480$0402a8c0@sergeyl>
	<19cda190606260930u31de6dfcx523aa7c142fcafdb@mail.gmail.com>
	<000b01c69963$f00aa7c0$3e01a8c0@sergeyl>
Message-ID: <19cda190606261517p561e408ds8d29aa4348f71987@mail.gmail.com>

On 6/26/06, Sergey Shalatskiy <sshalatskiy at mdlogix.com> wrote:
>
> >>----- Original Message -----
> >>From: Jeff Barczewski
> >>To: Sergey Shalatskiy
> >>Sent: Monday, June 26, 2006 12:30 PM
> >>Subject: Re: MasterView generation from existing rhtml
>
>
> >>Yes, I think what you mentioned could work but the only when I was
> >>thinking through this a while back I was >>having trouble figuring out
> how
> >>to know what all pieces (rhtml partials and layouts) to pull in.
>
> It looks like erb will do the heavy lifting for you in this case, and
> possibly all you need would be just to pick up an rhtml file to parse and
> convert it to html by passing to erb with all the proxies I mentioned
> loaded
> instead of original Rails helpers (just don't load helpers).
>
>
>
> >>Honestly I didn't spend much time looking at it but it did seem like it
> >>would be a nice thing to do if possible.
>
> IMHO, this feature will be the deciding factor for marketing MasterView.
> The
> idea and original implementation are
> escellent, but the ability to create html from existing files in the
> application will be crucial to success of the project.
>
> >>I will put it on the todo list.
>
> >>Thanks for the idea and approach.
>
> You are very welcome.
>
> Sergey
>
> P.S.  I don't quite understand how the masterview template is used. It
> seems
> like it duplicates the contents of the view html files, but I don't see
> the
> purpose of it.


Might just be misundersting of terminology. We call the masterview html
files masterview templates in that they create a bunch of other rhtml files
under the covers.

For instance in the default generator, the list.html file generates the
layout/foo.rhtml, foo/list.rhtml and other partials. The other files like
edit.html creates edit.rhtml and imports the layout/foo.rhtml and any other
partials they need to allow you to see a full page view when designing. So
there is duplication only so that you can get a full page view of what
everything will look like. If you change the layout section in
list.htmlthen you can have MasterView rebuild the other files to get
the layout part
sync'd up so that you'll have a consistent view when working with that file
in your editor (otherwise it doesn't really matter).

The generator can generate a version of file that is a single page
containing all the other views, so there is no duplication. However this has
drawbacks in that it is a single page that keeps getting bigger and bigger
(hard to have multiple people working at once), and it is more difficult to
switch between views when desiging, have to change which css is on to hide
other sections, etc. So it appeared that having a small amount of
duplication made things work easier.


Can you tell me a couple of words about it? - It would give me an insight on
> what's going on, and then I could possibly try to help you with
> implementing
> the idea I coined. (It shows my lazyness perhaps, but we all have too
> little time to spend on something that we are not paid for...)
> Also, how can I add new views? It is not quite clear to me. The
> documentation is focused on the CRUD set of actions, and it would be nice
> to
> have a few words how to work with new actions and views.


Yes, I was even planning to do a little video on this. Basically you can
either create a new file manually or I have streamlined it so that you can
copy an existing action and it will automatically pull in the layout and
such, saving one a little trouble in getting things setup. We will document
and get the video out shortly.


________________________________________________________
> On 6/26/06, Sergey Shalatskiy < sshalatskiy at guerillaviralmarketing.com>
> wrote:
> Jeff,
>
> Thanks for a quick answer. It helped a lot.
> Regarding the issue with generating html from rhtml, I don't see why it
> can
> be difficult. If the difficulty you see is in converting the erb
> statements,
> you could use erb itself, I believe, by replacing standard rails methods
> for
> things like
> error_messages_for, or any other methods that have equivalents in
> MasterView
> directives, by masterview proxies that generate its own output by
> converting
> them into directives. Basically, it seems to me, you just need a reverse
> method for every directive. The rest is to combine everything in a
> template
> and generate html per every rhtml.
> Not sure, though, what to do with rjs files, if anything.
> Although, maybe I oversimplify things here.
> Does it make sense to you?
>
> Thanks,
>
> Sergey Shalatskiy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060626/cf3f36ed/attachment.html 

From jeff.barczewski at gmail.com  Tue Jun 27 18:14:13 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Tue, 27 Jun 2006 17:14:13 -0500
Subject: [Masterview-devel] First draft of Simple diagram to help explain
	MasterView operation
Message-ID: <19cda190606271514w5b9e20d1x6a3e2bee86a7d022@mail.gmail.com>

I committed a simple diagram to try and help explain MasterView operation.
See what you think and feel free to update it, however if you move the divs
around, be careful it took me some care to make something that looked
similar on Firefox unix, firefox windows, and IE. Might be that I didn't
specify a font and size, but not sure.

Anyway see if this would help new users to understand what is going on here.

I also put it on the website if you want to hit it there. I don't have a
link to it yet from any other pages.

http://masterview.org/simple_diagram.html

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060627/0e8d3bdc/attachment.html 

From jeff.barczewski at gmail.com  Wed Jun 28 10:35:16 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 28 Jun 2006 09:35:16 -0500
Subject: [Masterview-devel] I would like to do a release today for 0.2.1,
	let me know if that is ok, and need input on a few new config items
Message-ID: <19cda190606280735i36ff633au33a23347bc228a44@mail.gmail.com>

I would like to do a release for 0.2.1 today since it has an important fix
to support Mongrel.

I found out that I needed to change the init slightly to support running
from mongrel otherwise MasterView didn't get loaded.

Mongrel has been showing much popularity these days, so I would like to get
this out asap.

That being said, there is one other thing that I would like to add to the
initialization and I need some help with the naming and explanation around
that.

I added the feature to image_tag, stylesheet_link, and javascript_include so
that if you don't specify an absolute in the attr_value that it will use a
regular expression to find the relative path from the src attribute.
Currently these are constants embedded in each of these three directives,
however after talking with Ed Howland one of our users, the way he was using
things it might be better if these are configurable constants. This would
allow you to put your images, javascripts, and stylesheets elsewhere on your
file system for designing and not be locked into public/*.

So I am looking for naming and description for

JAVASCRIPT_SRC_EXTRACT_REGEX = /public\/javascripts\/(.*)/
IMAGE_SRC_EXTRACT_REGEX = /public\/images\/(.*)/
STYLESHEET_SRC_EXTRACT_REGEX = /public\/stylesheets\/(.*)/

Basically the way I designed these is that if the src value finds a match
with this regular expression then it takes the contents of the first group
(which in these examples is the relative path) and uses that for the path to
the appropriate helper. If the regex did not match, then it just uses the
entire contents of src since it doesn't know what else to do.

Hope that makes sense. Deb I can make the updates if you can just help me
with the naming and description for these.

I guess this doesn't have to be put in 0.2.1 but since it was fresh in my
mind I thought I would knock it out if possible.

I have also updated the content with the diagram and put a new shorter video
up.

Thanks,

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060628/449c6895/attachment.html 

From djlewis at acm.org  Wed Jun 28 10:51:54 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 28 Jun 2006 07:51:54 -0700
Subject: [Masterview-devel] I would like to do a release today for 0.2.1,
	let me know if that is ok, and need input on a few new config items
In-Reply-To: <19cda190606280735i36ff633au33a23347bc228a44@mail.gmail.com>
Message-ID: <20060628145158.OTJK18458.fed1rmmtao10.cox.net@DLI92cx797990>

Jeff - by all means do the update for mongrel today.  (and include your fine
new diagrams!)
 
I'll look at the naming/config issue for assert refs and get back to you
asap, but have meetings this morning so I'll have to juggle it in.  Suggest
not holding the update for this; let's not rush config additions and names
until we've had a chance to consider properly, better to let it wait a day .
 
Ed's example is actually a case I've already run into with my own
stylesheets and images, so it was already kind of in my mind to look at
while going over directives impls and asset support.  I think his suggestion
is on the right track, it's roughly what I'd been thinking of.  I keep a
separate design-time stash of stylesheets that have a more palatable rel ref
for use in my MasterView templates; the stylesheets themselves actually just
contain the nasty ../../public/stylesheets sorts of paths (and can be easily
replaced or modified when working separately from my rails dev setup), along
with any design-time overrides/additions I want in my styles.
 
~ Deb
 
>> I added the feature to image_tag, stylesheet_link, and javascript_include
so that 
>> if you don't specify an absolute in the attr_value that it will use a
regular expression
>> to find the relative path from the src attribute. Currently these are
constants 
>> embedded in each of these three directives, however after talking with Ed
Howland 
>> one of our users, the way he was using things it might be better if these
are 
>> configurable constants. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060628/9cef927f/attachment.html 

From jeff.barczewski at gmail.com  Wed Jun 28 10:57:25 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 28 Jun 2006 09:57:25 -0500
Subject: [Masterview-devel] I would like to do a release today for 0.2.1,
	let me know if that is ok, and need input on a few new config items
In-Reply-To: <20060628145158.OTJK18458.fed1rmmtao10.cox.net@DLI92cx797990>
References: <19cda190606280735i36ff633au33a23347bc228a44@mail.gmail.com>
	<20060628145158.OTJK18458.fed1rmmtao10.cox.net@DLI92cx797990>
Message-ID: <19cda190606280757j6196844eha7a41a2a14735f60@mail.gmail.com>

Sounds good! Will do the mongel release this morning.

On 6/28/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  Jeff - by all means do the update for mongrel today.  (and include your
> fine new diagrams!)
>
> I'll look at the naming/config issue for assert refs and get back to you
> asap, but have meetings this morning so I'll have to juggle it in.  Suggest
> not holding the update for this; let's not rush config additions and
> names until we've had a chance to consider properly, better to let it wait a
> day .
>
> Ed's example is actually a case I've already run into with my own
> stylesheets and images, so it was already kind of in my mind to look at
> while going over directives impls and asset support.  I think his suggestion
> is on the right track, it's roughly what I'd been thinking of.  I keep a
> separate design-time stash of stylesheets that have a more palatable rel ref
> for use in my MasterView templates; the stylesheets themselves actually just
> contain the nasty ../../public/stylesheets sorts of paths (and can be easily
> replaced or modified when working separately from my rails dev setup), along
> with any design-time overrides/additions I want in my styles.
>
> ~ Deb
>
> >> I added the feature to image_tag, stylesheet_link, and
> javascript_include so that
> >> if you don't specify an absolute in the attr_value that it will use a
> regular expression
> >> to find the relative path from the src attribute. Currently these are
> constants
> >> embedded in each of these three directives, however after talking with
> Ed Howland
> >> one of our users, the way he was using things it might be better if
> these are
> >> configurable constants.
>
> _______________________________________________
> 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/20060628/af9eb45f/attachment-0001.html 

From ed.howland at gmail.com  Wed Jun 28 11:17:40 2006
From: ed.howland at gmail.com (Ed Howland)
Date: Wed, 28 Jun 2006 10:17:40 -0500
Subject: [Masterview-devel] I would like to do a release today for 0.2.1,
	let me know if that is ok, and need input on a few new config items
In-Reply-To: <20060628145158.OTJK18458.fed1rmmtao10.cox.net@DLI92cx797990>
References: <19cda190606280735i36ff633au33a23347bc228a44@mail.gmail.com>
	<20060628145158.OTJK18458.fed1rmmtao10.cox.net@DLI92cx797990>
Message-ID: <3df642dd0606280817t482a7fcfu517c07d7738691@mail.gmail.com>

On 6/28/06, Deb Lewis <djlewis at acm.org> wrote:
>
>
>
> Ed's example is actually a case I've already run into with my own
> stylesheets and images, so it was already kind of in my mind to look at
> while going over directives impls and asset support.  I think his suggestion
> is on the right track, it's roughly what I'd been thinking of.  I keep a
> separate design-time stash of stylesheets that have a more palatable rel ref
> for use in my MasterView templates; the stylesheets themselves actually just
> contain the nasty ../../public/stylesheets sorts of paths (and can be easily
> replaced or modified when working separately from my rails dev setup), along
> with any design-time overrides/additions I want in my styles.
>
> ~ Deb
>

Nice tip, I'll pass that along to Jeswin. And I'm incouraging him to
join this list. Lurking he can learn, and he has a lot of good ideas
design-wise. He too is a type of masterview user.

The problem I expressed to Jeff last night (btw, great presentation on
RailsConf Jeff, ) was that under Linux I can easily create a symbolic
link from app/views/masterview/images to public/images. But Jeswin is
working out of Subversion, on Windows. I don't know any way to have
symbolic links in WinXP.I don't want his images (or other stylesheets
or javascripts) to get out of sync with the true place for these
files.

Also, designers like to group related images into subdirectories under
the main images dir. So, I think Jeff's explanation of his current
implementation should allow for that.

I'll get an experimental HEAD tag from SVN tonight and try it out.

> >> I added the feature to image_tag, stylesheet_link, and javascript_include
> so that
> >> if you don't specify an absolute in the attr_value that it will use a
> regular expression
> >> to find the relative path from the src attribute. Currently these are
> constants
> >> embedded in each of these three directives, however after talking with Ed
> Howland
> >> one of our users, the way he was using things it might be better if these
> are
> >> configurable constants.


-- 
Ed Howland
http://greenprogrammer.blogspot.com

From jeff.barczewski at gmail.com  Wed Jun 28 14:28:17 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 28 Jun 2006 13:28:17 -0500
Subject: [Masterview-devel] [ANN] MasterView Release 0.2.1
Message-ID: <19cda190606281128k23e56b6yb45aa64662ae506b@mail.gmail.com>

Release 0.2.1 adds Mongrel support, a new image_tag directive and some
additional illustrations and links to videos. Also javascript_include
and stylesheet_link directives can infer the path from the src
attribute if the attr_value is empty. More information is available in
the directive documentation.

Also added additional logging around startup and the version of
MasterView that is running and a new admin page to visually see what
MasterView features are currently loaded (tidy,auto parsing on change,
parse on startup, reading rhtml direct from masterview (eliminating
rhtml file generation))

Release 0.2.1 is available via gem, rubyforge download, or svn
If using SVN then the recommended tag to pull is
svn://rubyforge.org/var/svn/masterview/tags/masterview which will
always point to the latest release.

Release 0.2.0 was a big release with much new functionality and
refactoring. As a result of the cleanup, configuration changed,
default template src path was changed from app/masterview to app/views
and one directive was renamed for clarity. Details below.

This release also received a major upgrade in the consolidation of IO
which allows for much flexibility in where and how templates and files
are read and written. Because of this upgrade it was easy for us to
extend Rails to load the rhtml (erb) directly from MasterView without
serializing to the file system (although can be configured optionally
to do so).


UPGRADE NOTES: If you have customized your MasterView configuration
in the init.rb file of your existing plugin installation, you *MUST*
migrate your configuration to the new settings file configuration mechanism
(config/masterview/settings.rb and environment settings files).

Also note that a directive was renamed from gen_render to gen_partial to
more clearly represent the functionality and eliminate future confusion.
Be sure to change any references to gen_render to gen_partial.

The default location for MasterView templates is now the standard Rails
app/views directory rather than app/masterview.  Either move your
existing templates into app/views or update the MasterView
config.template_src_dir_path setting in your
config/masterview/settings.rb to reference your existing templates
source directory.

If you have any questions or problems with the new release, let us know.

Thanks,

Jeff

From jeff.barczewski at gmail.com  Thu Jun 29 10:11:19 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Thu, 29 Jun 2006 09:11:19 -0500
Subject: [Masterview-devel] Updated short video,
	added screenshots and some more info on index
Message-ID: <19cda190606290711o73152e8bxe12b7daca9b9fc38@mail.gmail.com>

I updated the short video on the website, added screenshots and some
more info on the index page and meda_list page. Everything is checked
in and uploaded to the website.

Wanted to clarify some key points.

Jeff

From jeff.barczewski at gmail.com  Thu Jun 29 16:31:05 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Thu, 29 Jun 2006 15:31:05 -0500
Subject: [Masterview-devel] Updated the site with some new graphics,
	let me know what you think
Message-ID: <19cda190606291331v2c8216d3h6f108f8dadff98c9@mail.gmail.com>

I created a logo and added some small graphics here and there to
http://masterview.org/

When you have a chance to check it out, let me know what you think.

Jeff

From djlewis at acm.org  Thu Jun 29 19:42:38 2006
From: djlewis at acm.org (Deb Lewis)
Date: Thu, 29 Jun 2006 16:42:38 -0700
Subject: [Masterview-devel] Updated the site with some new graphics,
	let me know what you think
In-Reply-To: <19cda190606291331v2c8216d3h6f108f8dadff98c9@mail.gmail.com>
Message-ID: <20060629234242.CWVM22974.fed1rmmtao01.cox.net@DLI92cx797990>

now that is just way too cool.  can I hire you to do some site logos and
graphics for me?!

That's starting to look very polished, and first impression will definitely
help reassure visitors that this is real stuff, not just half baked junk
that they should run away from immediately.

[note to self: fix the docs header so clicking on the MV logo at upper left
goes back to home page, people kind of expect that sort of thing]

outstanding.

~ Deb 

-----Original Message-----
From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Thursday, June 29, 2006 1:31 PM
To: masterview-devel at rubyforge.org; djlewis at acm.org
Subject: Updated the site with some new graphics, let me know what you think

I created a logo and added some small graphics here and there to
http://masterview.org/

When you have a chance to check it out, let me know what you think.

Jeff



From jeff.barczewski at gmail.com  Fri Jun 30 07:20:12 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 30 Jun 2006 06:20:12 -0500
Subject: [Masterview-devel] Updated the site with some new graphics,
	let me know what you think
In-Reply-To: <20060629234242.CWVM22974.fed1rmmtao01.cox.net@DLI92cx797990>
References: <19cda190606291331v2c8216d3h6f108f8dadff98c9@mail.gmail.com>
	<20060629234242.CWVM22974.fed1rmmtao01.cox.net@DLI92cx797990>
Message-ID: <19cda190606300420n5137617dl7fe4a685fab95a2d@mail.gmail.com>

Thanks. If I am in the docs first I'll put the link to home in.

On 6/29/06, Deb Lewis <djlewis at acm.org> wrote:
>
> now that is just way too cool.  can I hire you to do some site logos and
> graphics for me?!
>
> That's starting to look very polished, and first impression will
> definitely
> help reassure visitors that this is real stuff, not just half baked junk
> that they should run away from immediately.
>
> [note to self: fix the docs header so clicking on the MV logo at upper
> left
> goes back to home page, people kind of expect that sort of thing]
>
> outstanding.
>
> ~ Deb
>
> -----Original Message-----
> From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com]
> Sent: Thursday, June 29, 2006 1:31 PM
> To: masterview-devel at rubyforge.org; djlewis at acm.org
> Subject: Updated the site with some new graphics, let me know what you
> think
>
> I created a logo and added some small graphics here and there to
> http://masterview.org/
>
> When you have a chance to check it out, let me know what you think.
>
> Jeff
>
>
> _______________________________________________
> 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/20060630/55a5899c/attachment.html 

From jeff.barczewski at gmail.com  Fri Jun 30 12:37:19 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 30 Jun 2006 11:37:19 -0500
Subject: [Masterview-devel] MasterView release 0.2.2 - maintenance release,
	fixes rhtml error, documentation updated
Message-ID: <19cda190606300937y75b3d4dcqa7b0c85a38c73d43@mail.gmail.com>

MasterView 0.2.2 - maintenance release

Fixes problem when rails encounters exception in either compiling or
involving RuntimeError in the generated rhtml. The rails TemplateError
class looks at the file system for the template contents. So when
generate_rhtml is false (no file is generated) rails was not able to
find source and was not outputting an error page. Rails TemplateError
class was extended to look at MasterView store first and then fallback
to file system.

Documentation was updated with some more details around
generator and including screenshots and an illustration.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060630/7398d765/attachment.html