Masterview users - Jun 2006 - Logging from within a directive

Hi,

I assume that the default logging level is Logger::DEBUG since by
setting that in init.rb, I get lots of log messages in the WEBrick
console window, like when the log level is not set. But if I put

Log.debug "content_str #{content_str}"

in my etag method of my directive, I don''t see any output in that same
window (or in log/development.log)

Any ideas?

TIA,
Ed



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

The Logger is set on the MasterView module so you would probably need to
refer to it like

MasterView::Log.debug "foo"

or even better use

MasterView::Log.debug { "foo" }

The second form is better since it is a block and the block won''t get
executed if the output level is above debug which saves cpu if you were
doing any string building concatenating, etc.

On 6/8/06, Ed Howland <ed.howland at gmail.com>
wrote:
>
> Hi,
>
> I assume that the default logging level is Logger::DEBUG since by
> setting that in init.rb, I get lots of log messages in the WEBrick
> console window, like when the log level is not set. But if I put
>
> Log.debug "content_str #{content_str}"
>
> in my etag method of my directive, I don''t see any output in that
same
> window (or in log/development.log)
>
> Any ideas?
>
> TIA,
> Ed
>
>
>
> --
> Ed Howland
> http://greenprogrammer.blogspot.com
> _______________________________________________
> Masterview-users mailing list
> Masterview-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/masterview-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-users/attachments/20060608/0d34f5c0/attachment.htm

Ed Howland wrote:
 
>> I assume that the default logging level is Logger::DEBUG ... [based on]
masterview plugin''s init.rb
 
The next release of MasterView will include a rework of the mechanisms for
customizing the MasterView configuration.  The new approach will be similar
to the style used for rails app configuration, where you customize the
settings for your app by providing initialization specs in your config
directory, setting values in the configuration and allowing for
environment-dependent settings which override/augment the general config for
your app.
 
There''ll be documentation on all the supported configuration options
and
description of how to use them, along with some sort of example/prototype
config file so it''s easy to drop in and get going if you want something
different than the standard defaults,.
 
I''ll make sure there are options supported to allow configuring the
logging
facilities.  (that area isn''t quite sorted out, working on that right
now)
 
[p.s. introducing myself: I''m currently working with Jeff on some
enhancements to MasterView, having recently picked it up to use in a rails
development project I''m doing and deciding there were some things I
wanted
added or done differently.  kudos to Jeff, he''s done a really nice job
creating MasterView]
 
~ Deb

  _____  

From: masterview-users-bounces at rubyforge.org
[mailto:masterview-users-bounces at rubyforge.org] On Behalf Of Jeff Barczewski
Sent: Thursday, June 08, 2006 1:29 PM
To: masterview-users at rubyforge.org
Subject: Re: [Masterview-users] Logging from within a directive


The Logger is set on the MasterView module so you would probably need to
refer to it like

MasterView::Log.debug "foo" 

or even better use

MasterView::Log.debug { "foo" }

The second form is better since it is a block and the block won''t get
executed if the output level is above debug which saves cpu if you were
doing any string building concatenating, etc. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-users/attachments/20060609/4d51c6eb/attachment-0001.htm

On 6/9/06, Deb Lewis <djlewis at acm.org> wrote:
>
>
> The next release of MasterView will include a rework of the mechanisms for
> customizing the MasterView configuration.  The new approach will be similar
> to the style used for rails app configuration, where you customize the
> settings for your app by providing initialization specs in your config
> directory, setting values in the configuration and allowing for
> environment-dependent settings which override/augment the general config
for
> your app.
>
> There''ll be documentation on all the supported configuration
options and
> description of how to use them, along with some sort of example/prototype
> config file so it''s easy to drop in and get going if you want
something
> different than the standard defaults,.
>
> I''ll make sure there are options supported to allow configuring
the logging
> facilities.  (that area isn''t quite sorted out, working on that
right now)
Great news. Looking forward to it. Do you have a timescale?
>
> [p.s. introducing myself: I''m currently working with Jeff on some
> enhancements to MasterView, having recently picked it up to use in a rails
> development project I''m doing and deciding there were some things
I wanted
> added or done differently.  kudos to Jeff, he''s done a really nice
job
> creating MasterView]
>
> ~ Deb
Introducing myself as well. I''ve just started using MV in a recent
newly minted, but ongoing project. I''ve only completed the outer layer
of the first seach page so far, Today I hope to get the new entry
forms converted. (At the very least, I can through out a lot of my
other
small templates which had to be edited by hand each time I got them
back from the designer.

I''ve know Jeff for a few months through the StL.rb (St. Louis Ruby
brigrade.) He also gave a talk on it there and mentioned it during his
RoR talk at the StLLUG meeting where I''ve attended since naught-0.

So far it has been working out OK. I am getting our designer on
Subversion this afternoon, so we can share the files that way. As we
talked about in a recent post, the relative path was the only
confusing part to him. He lives in Dreamweaver-land and all paths are
below the project directory. Too bad there aren''t things like symlinks
in Windows.

****
BTW, so I am not too far ahead of the projected directive syntax, will
one version of ''image_tag'' look like this:

<img src="../../../public/images/my.gif"
mv:image_tag="my.gif">

Currently, to support image sizes and other attributes, I am forced to
do this for all my image tags:

<img src="../../../public/images/my.gif" height="17"
width="16
mv:image_tag="''my.gif'', :size =>
''17x16''">

So even <img src="../../../public/images/my.gif"
needs:
 mv:image_tag="''my.gif''">

That is because I need to pass the complete argument as a string to
the image tag inside the erb. The quoting and unquoting of strings
inside attribute values of mv: is a real pain. Clearly, I need more
help on writing directives.

?

Thanks
Ed

>
>  ________________________________
>  From: masterview-users-bounces at rubyforge.org
> [mailto:masterview-users-bounces at rubyforge.org] On Behalf
> Of Jeff Barczewski
> Sent: Thursday, June 08, 2006 1:29 PM
> To: masterview-users at rubyforge.org
> Subject: Re: [Masterview-users] Logging from within a directive
>
>
> The Logger is set on the MasterView module so you would probably need to
> refer to it like
>
> MasterView::Log.debug "foo"
>
> or even better use
>
> MasterView::Log.debug { "foo" }
>
> The second form is better since it is a block and the block won''t
get
> executed if the output level is above debug which saves cpu if you were
> doing any string building concatenating, etc.
>
> _______________________________________________
> Masterview-users mailing list
> Masterview-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/masterview-users
>
>

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

We are working diligently to get this out as soon as possible. I would like
to have something out before the Rails conference if possible. So we will
probably just release whatever is ready and then continue on.

Some of the high priority goals are to shore up the config mechanisms and
layout of the files, clean up the docs, create some how to videos and
examples.

Beyond that we want to build out the main missing directives, provide direct
to Erb cache (eliminating intermediate rhtml file), add more advanced
directives, cleanup api for building directives (so easier to use and
understand) and provide good examples for how to build your own.

Lots of killer possibilities for powerful directives including ajax''d
grids,
calendars, custom rendering, ...

But we are just taking it one day at a time, trying to prioritize what needs
to be done first so that we won''t break things as we build, so if we
have a
good extendable foundation we can keep adding with minimal impact to users
(or that is the goal).

Of course Deb and I have our own personal things that we need in there for
various projects, but we will also be looking at how the users are wanting
to use the system as we go forward, so we can continue to reprioritize
feature additions.

On 6/9/06, Ed Howland <ed.howland at gmail.com>
wrote:
>
>
> Great news. Looking forward to it. Do you have a timescale?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-users/attachments/20060609/32e2dd6c/attachment.htm

RE: mv:image_tag attribute notation and Ed''s remarks:
>> Currently, to support image sizes and other attributes, I am forced 
>> to do this for all my image tags:
>> <img src="../../../public/images/my.gif"
height="17" width="16
>>      mv:image_tag="''my.gif'', :size =>
''17x16''">
Ed - we''ll probably have to think about that a bit before responding
further.

In the meantime, you might consider some alternative techniques approaches
using css style rules with your <img> elements.

Option 1: if you have a small set of specific images that you use in a
number of places, consider defining a class in your css stylesheet for these
so you don''t have to hard-code the size attributes in the <img>
markup.

    <img src="../../../public/images/my.gif" height="17"
width="16
         mv:image_tag="''my.gif'', :size =>
''17x16''" />

could be replaced with style rule and simplified markup:

    img.my-gif {  width: 16px;  height: 17px; }
    <img src="../../../public/images/my.gif"
class="my-gif"
         mv:image_tag="''my.gif'', :class =>
''my-gif''" />

(don''t like the need to duplicate the style rule class, but IMO
that''s still
a better than bolting down image file size attributes directly in content
pages)

Option 2: if you have a number of standard-sized images that you use
frequently, do a variation of the preceding with a style rule, say, some
name by ''visual-cue-img'', whatever makes sense.

And a possible option 3: create a custom masterview directive to encapsulate
a standard pattern than you want to use across a number of pages in our
site.  

(I actually have a situation that #3 solves nicely in I''m doing right
now,
so after working out details will probably contribute it to the next
MasterView release as an example of how to do a custom masterview directive)
>>> So even <img src="../../../public/images/my.gif"
needs:
>>  mv:image_tag="''my.gif''"
Jeff - this might be interesting, let''s take a look at this case when
we
have a chance.  It''s quite similar to the target substitution magic
we''re
working on right now for mv:generate.  The template being processed already
provides some info about what the directive should produce and it would be
nice if the author didn''t have to repeat the image asset''s
name.  e.g. some
sort of mv:image="{this_src}" notation, if we can specify a sensible
rule
about how to determine the relevant portion of the <img> tag''s
existing src
attribute to use in the generated output.

(?? mv:image_tag="{src_filename}" notation could work for images
directly
contained in the std rails public/images dir; not sure how far to push on
trying to automagically determine a relative path name w/in the images dir,
there are issues of nesting in the template src dir that make ugly .. paths
like the above tricky)

~ Deb

Yeah, I think we can easily make a tag that will intuit the path from the
src, and of course it can pick up the height and width from the settings.
Many times the wysiwyg editor will set those for you automatically, so if we
just pick those up then that would be a big help.

We could take it a step further and determine the image size ourself, cache
it, and if not specified auto use the image size.

Will start simple and then play around to see what we can do.

On 6/9/06, Deb Lewis <djlewis at acm.org> wrote:
>
> RE: mv:image_tag attribute notation and Ed''s remarks:
>
> >> Currently, to support image sizes and other attributes, I am
forced
> >> to do this for all my image tags:
> >> <img src="../../../public/images/my.gif"
height="17" width="16
> >>      mv:image_tag="''my.gif'', :size =>
''17x16''">
>
> Ed - we''ll probably have to think about that a bit before
responding
> further.
>
> In the meantime, you might consider some alternative techniques approaches
> using css style rules with your <img> elements.
>
> Option 1: if you have a small set of specific images that you use in a
> number of places, consider defining a class in your css stylesheet for
> these
> so you don''t have to hard-code the size attributes in the
<img> markup.
>
>     <img src="../../../public/images/my.gif"
height="17" width="16
>          mv:image_tag="''my.gif'', :size =>
''17x16''" />
>
> could be replaced with style rule and simplified markup:
>
>     img.my-gif {  width: 16px;  height: 17px; }
>     <img src="../../../public/images/my.gif"
class="my-gif"
>          mv:image_tag="''my.gif'', :class =>
''my-gif''" />
>
> (don''t like the need to duplicate the style rule class, but IMO
that''s
> still
> a better than bolting down image file size attributes directly in content
> pages)
>
> Option 2: if you have a number of standard-sized images that you use
> frequently, do a variation of the preceding with a style rule, say, some
> name by ''visual-cue-img'', whatever makes sense.
>
> And a possible option 3: create a custom masterview directive to
> encapsulate
> a standard pattern than you want to use across a number of pages in our
> site.
>
> (I actually have a situation that #3 solves nicely in I''m doing
right now,
> so after working out details will probably contribute it to the next
> MasterView release as an example of how to do a custom masterview
> directive)
>
> >>> So even <img src="../../../public/images/my.gif"
needs:
> >>  mv:image_tag="''my.gif''"
>
> Jeff - this might be interesting, let''s take a look at this case
when we
> have a chance.  It''s quite similar to the target substitution
magic we''re
> working on right now for mv:generate.  The template being processed
> already
> provides some info about what the directive should produce and it would be
> nice if the author didn''t have to repeat the image
asset''s name.  e.g.
> some
> sort of mv:image="{this_src}" notation, if we can specify a
sensible rule
> about how to determine the relevant portion of the <img>
tag''s existing
> src
> attribute to use in the generated output.
>
> (?? mv:image_tag="{src_filename}" notation could work for images
directly
> contained in the std rails public/images dir; not sure how far to push on
> trying to automagically determine a relative path name w/in the images
> dir,
> there are issues of nesting in the template src dir that make ugly ..
> paths
> like the above tricky)
>
> ~ Deb
>
>
> _______________________________________________
> Masterview-users mailing list
> Masterview-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/masterview-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-users/attachments/20060609/c3c3d38e/attachment.htm

Ed - the next release of MasterView will support configuration settings for
both the flavor of logger used (Log4r, the default if available, or Logger
from the standard Ruby library), along with a log_level setting.

The current default log level is DEBUG from Logger, ALL from Log4r.  (their
logging level naming conventions are somewhat different, but both support
DEBUG, INFO, WARN, ERROR as standard levels)  

We might want to modify the logger''s built-in defaults that we
currently
pick up so that the MasterView log is a bit smarter about choosing its
defaults, e.g., maybe DEBUG or ALL/ANY if development mode, WARN in
production.

~ Deb 

-----Original Message-----
From: masterview-users-bounces at rubyforge.org
[mailto:masterview-users-bounces at rubyforge.org] On Behalf Of Ed Howland
Sent: Thursday, June 08, 2006 9:42 AM
To: masterview-users at rubyforge.org
Subject: [Masterview-users] Logging from within a directive

Hi,

I assume that the default logging level is Logger::DEBUG since by setting
that in init.rb, I get lots of log messages in the WEBrick console window,
like when the log level is not set. But if I put

Log.debug "content_str #{content_str}"

in my etag method of my directive, I don''t see any output in that same
window (or in log/development.log)

Any ideas?

TIA,
Ed



--
Ed Howland
http://greenprogrammer.blogspot.com
_______________________________________________
Masterview-users mailing list
Masterview-users at rubyforge.org
http://rubyforge.org/mailman/listinfo/masterview-users