Masterview devel - Jun 2006 - Docs reorganized and a bit of cleanup

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.

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

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

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

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

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

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