Deb,<br><br>Here is a first draft of a DSL for creating directives which should clean up the API considerably, let me know what you think<br><br>class MyDirective < DirectiveBase<br> event :etag do |e|<br> e.arg :object # get arg[0] from parse(attr_value) and assign it to @object
<br> e.arg :method, :quote_simple_string => true # get arg[1] from parse(attr_value) and if is not already quoted and is simple string then quote it, store in @method<br> e.arg :options, :optional_default = {} # get arg[2] from parse(attr_value), it is optional, but if we need to add it to outgoing arg list then we can use {} for default if nil to @options
<br> e.arg :html_options, :merge => [Common, :rows, :cols] # get arg[3] from parse(attr_value), merge in common html attributes and rows and cols to @html_options<br><br> # do more business logic here, use e.content
, e.yield() and other DirectiveBase methods<br><br> e.erb 'text_area', args(:object, :method, :options, :html_options) # renders a <%= text_area ARGS_HERE %> it builds the args, joining with comma, eliminating if nil unless an arg after it is not nil in which case it will use the optional_default.
<br>end<br><br><br>Other methods<br><br>e.erb_code 'a = a + 1' # generates <% a = a + 1 %><br>e.render 'hello world' # generates hello world<br><br>Also other methods on e.arg for manipulating the data<br><br>e.arg :foo {|o| o+'bar' } # manipulate arg[x] by concatenating 'bar' to it and then finally store it in @foo, you could obviously do other things with the data
<br>e.arg :foo { e.content } # override the arg with element content and store in @foo, link_tag uses something like this to allow users to enter link text to be consistent with rails helpers, but then overrides it with whatever was in the element text.
<br><br><br>The basic idea is to wrap up much of the repetive work around building directives into something simple yet allow custom things to be done as necessary.<br><br>Much of the tediousness is simply parsing out args from the attr_value, quoting if necessary, merging in html options and other simple logic. Finally we build up output to write outputting <%= %> and joining together args, accounting for the fact that some args might be missing and if later args are suddenly non-empty because of a merge, then we need to output good defaults for the nil previous ones.
<br><br>So I was kind of patterning this dsl off of what we need to do and how rake and active record migrations dsl's work.<br><br>It seems clearer to me what happens doing this and much of the monkey business is abstacted away using a few key words.
<br><br>Let me know what you think.<br><br>Jeff<br>