Been investigating Hobo DRYML:
In the Template class (template.rb) there are a few methods that
return a string that in the end is output into the final .erb code
generated for a page.
Currently tags result in string concatenations using the concat
function (and nested concats!).
The DRYML generated erb is something like:
concat(x(), concat(y(), "blip"))
To make DRYML even more DRY, I think the concat should not be
hardcoded (as it is currently in several of these strings). Instead it
should be configurable at some level (see the following).
The TemplateEnvionment class contains the functions to handle
compilation of the tags into templates. Fx:
def call_tag_parameter_with_default_content(the_tag, attributes ...)
is called for a tag with default content inside
Now I can add some meta-information, fx
<comma separator=",">
<default content here ...>
</comma>
And inside the call_tag_parameter_with_default_content I can extract
this info
separator = attributes.key?(:separator) ? attributes[:separator] :
""
Now, how would I go about holding on to this information (the
separator variable) so that I have it available when I get to the
outputting function in Template, fx:
def tag_call(el)
name = call_name(el)
param_name = get_param_name(el)
attributes = tag_attributes(el)
newlines = tag_newlines(el)
...
call = maybe_make_part_call(el, "<% concat(#{call}) %>")
It seems I can extract a lot of useful info here... I wonder if this
separator can also be extracted here.
What is this el?
Would be really nice if someone could add inline code documentation to
key parts of Hobo, and especially the DRYML classes so we could get
some decent API documentation for RDoc!
I wonder if this kind of approach would work?
separator = attributes.key?(:separator) ? attributes[:separator] : ""
if separator != ""
call = maybe_make_part_call(el, "<% concat_separator(#{separator}, #
{call}) %>")
else
call = maybe_make_part_call(el, "<% concat(#{call}) %>")
end
Then I just have to make a concat_separator function, which takes the
separator to join with as first argument, and concatenates the
remaining arguments (only for arguments that result in non-empty
strings!). That should be enough for the Javascript/Json integration
in general :)
Of course this could be extended into a more general/generic approach,
and I would like their take on how to design for this in DRYML in
general.
Note: In the above code there is even more duplication of code! The
whole string output business should be encapsulated in single place
IMO.
Something like this:
def tag_call(el)
...
erb_output = TemplateErbHelper.wrap_call("#{call}", {:separator =>
separator})
call = maybe_make_part_call(el, erb_output)
I will try this approach today... I'm not exactly sure what el is in
this context and if it (or the info it contains) is accessible in all
the places required for extending DRYML like this...
I suppose EL means "Expression Language"?
Now to make DRYML more flexible, it would be nice if we weren't
limited to setting and passing attributes around... maybe we could
have a general purpose context?
template_environment.rb
---
def call_tag_parameter_with_default_content(the_tag, attributes,
context ...)
if xyz?
context[:separator] = ","
end
template.rb
---
def tag_call(el)
context = get_context(el)
if context[:separator]
# do the magic
...
end
Ideally I think it is dangerous with these long argument lists for
function calls. Makes the whole thing very brittle and inflexible to
change. Why not have:
def call_tag_parameter_with_default_content(the_tag, context)
where the context includes an :attributes key etc.
Thought, comments, other ideas?
Kristian
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Hobo
Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/hobousers?hl=en
-~----------~----~----~----~------~----~------~--~---
