Masterview devel - Nov 2006 - Fix for old directive impl compat framework in MV 0.3.0

On 11/13/06, Ed Howland <ed.howland at gmail.com>
wrote:
>
>
> Deb, these are pretty straightforward. But what does the the block
> arguments get translated into?
> Here are some examples from the developer doc page:
>     * attr_arg :argname {|value| ... } - pass arg value into block to
> allow additional manipulation of the value
>     * attr_arg :argname {|value args| ... } - pass value and remaining
> args array to the block
>     * attr_arg :argname {|value args directive| ... } - pass value,
> remaining args array, and the directive instance for which the
> argument value is being obtained to the block


The block arguments allow you a way to do some additional logic before the
value is applied to the variable. Just makes it easy to tweak things or do
some advanced things like pushing arguments back on the arg stack.

The various block types are typically used for the following.

|value| simply allows you to manipulate the value before it is set to the
instance variable, the return value is what is set to the instance variable.

|value, args| gives you access to both the value and the remaining args, you
can manipulate the remaining args (shifting something back on the arg stack,
taking params off, etc. The return value is what is used to set the instance
variable to.

|value, args, instance| like the above but also gives you easy access to
anything in this directive instance as well as the arg stack.


IOW, since the attr_arg methods are positional, do the
subsequent
> attr_arg {|value, args| ...} eat one off the top of the list of
> remaining args each time? Or, for each next attr_arg does the top of
> the previous list become the value of this arg, while the remianing
> args are collected. Similar to how car and cdr work in Lisp?


The args is the remaining arguments that have not been pulled off the stack
yet. You can manipulate the args stack as well if you want to pull
additional ones off or shift something back on.


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

On 11/15/06, Jeff Barczewski <jeff.barczewski at gmail.com>
wrote:
> The block arguments allow you a way to do some additional logic before the
> value is applied to the variable. Just makes it easy to tweak things or do
> some advanced things like pushing arguments back on the arg stack.
>
> The various block types are typically used for the following.
>
> |value| simply allows you to manipulate the value before it is set to the
> instance variable, the return value is what is set to the instance
variable.
>
> |value, args| gives you access to both the value and the remaining args,
you
> can manipulate the remaining args (shifting something back on the arg
stack,
> taking params off, etc. The return value is what is used to set the
instance
> variable to.
>
> |value, args, instance| like the above but also gives you easy access to
> anything in this directive instance as well as the arg stack.
>
...
>
>
> The args is the remaining arguments that have not been pulled off the stack
> yet. You can manipulate the args stack as well if you want to pull
> additional ones off or shift something back on.
>
This is brilliant! Clear and erudite. If the above text were on the
web page, I would have joy in my life.

In the end, I was able to get around the problems with links and
embedded images by constructing the render string from parts. As I
mentioned to Deb, it would be helpful if the helper methods and
instance variables available to custom directives were more fully
documented. Maybe, you should provide a link to the HTML RDoc for the
entire API.

Also, you should document more clearly what the namespace should be
and also what the module naming convention should be. For instance, I
forgot to take out my old:
module MasterView
  module Directives
and replace them with
 module MyDirectives

Perhaps if you provided several examples of complete working custom
directives on the web page.

Another question:  Some things in the comments in DirectiveBase say
they are not available until the etag event has occured. Am I right
this also applies to the element event as well. IOW does this event
order hold true?

stag
etag
element

Thanks
Ed


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

On 11/15/06, Ed Howland <ed.howland at gmail.com>
wrote:
>
> >
> > The args is the remaining arguments that have not been pulled off the
> stack
> > yet. You can manipulate the args stack as well if you want to pull
> > additional ones off or shift something back on.
> >
>
> This is brilliant! Clear and erudite. If the above text were on the
> web page, I would have joy in my life.


Well, we''ll include it in the future to bring joy to those that follow
:-)



In the end, I was able to get around the problems with links
and
> embedded images by constructing the render string from parts. As I
> mentioned to Deb, it would be helpful if the helper methods and
> instance variables available to custom directives were more fully
> documented. Maybe, you should provide a link to the HTML RDoc for the
> entire API.


Agreed.

Also, you should document more clearly what the namespace should
be
> and also what the module naming convention should be. For instance, I
> forgot to take out my old:
> module MasterView
>   module Directives
> and replace them with
> module MyDirectives
>
> Perhaps if you provided several examples of complete working custom
> directives on the web page.


Right.


Another question:  Some things in the comments in DirectiveBase
say
> they are not available until the etag event has occured. Am I right
> this also applies to the element event as well. IOW does this event
> order hold true?
>
> stag
> etag
> element


Yes, this is correct.

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

hey jeff, welcome back!  thanks for picking up on these, I hadn''t had
time
to pursue it further
 
[well, ok, actually i was kind of procrastinating a bit about going back
into the rendering guts to figure out to better explain it]
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Wednesday, November 15, 2006 11:36 AM
To: Ed Howland
Cc: djlewis at acm.org; masterview-devel at rubyforge.org
Subject: Re: Fix for old directive impl compat framework in MV 0.3.0


On 11/15/06, Ed Howland <ed.howland at gmail.com> wrote: 
>
> The args is the remaining arguments that have not been pulled off the
stack
> yet. You can manipulate the args stack as well if you want to pull
> additional ones off or shift something back on.
>
This is brilliant! Clear and erudite. If the above text were on the
web page, I would have joy in my life.



Well, we''ll include it in the future to bring joy to those that follow
:-)

 


In the end, I was able to get around the problems with links and
embedded images by constructing the render string from parts. As I 
mentioned to Deb, it would be helpful if the helper methods and
instance variables available to custom directives were more fully
documented. Maybe, you should provide a link to the HTML RDoc for the
entire API. 



Agreed. 



Also, you should document more clearly what the namespace should be 
and also what the module naming convention should be. For instance, I
forgot to take out my old:
module MasterView
  module Directives
and replace them with
module MyDirectives

Perhaps if you provided several examples of complete working custom 
directives on the web page.



Right.
 



Another question:  Some things in the comments in DirectiveBase say 
they are not available until the etag event has occured. Am I right
this also applies to the element event as well. IOW does this event
order hold true?

stag
etag
element



Yes, this is correct. 

Jeff

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