I''ve gone through everything and have an almost-working system. One
unit
test case fails (involving templates and abs. paths). I can run my rails
application and template parsing seems to be basically working.
mv:generate="{template_path}" generates my .rhtml now
glitch: mv:generate="{template_path}.css" produces foo.rhtml.css - so
the
default output extension isn''t being ignored when target specified ext.
~ Deb
Yes, this is how the keyword expander is currently implemented, it actually
just replaces the token inside of the {}.
Currently to do what you were trying to do you would use the following
mv:generate="{template_dir_path}/{template_basename}.css"
I think it is important to not blur the lines between what is substituted
since if there is business logic that is used in addition the the token
itself then this would be confusing. This also keeps our keyword
substitution light and simple which can be used for other things and not too
customized for this one case.
If you want we can create another different token which represents
{template_dir_path}/{template_basename} to make it simpler for the user to
use, but I think it is important for this to be different than the token we
are using to represent template path with default extension.
So if you want we can create {template_path_no_ext} or {template_path_base}
or something similar which logically consists of
{template_dir_path}/{template_basename} .
What do you think?
On 6/15/06, Deb Lewis <djlewis at acm.org> wrote:>
> I''ve gone through everything and have an almost-working system.
One unit
> test case fails (involving templates and abs. paths). I can run my rails
> application and template parsing seems to be basically working.
>
> mv:generate="{template_path}" generates my .rhtml now
>
> glitch: mv:generate="{template_path}.css" produces foo.rhtml.css
- so the
> default output extension isn''t being ignored when target specified
ext.
>
> ~ Deb
>
>
> _______________________________________________
> Masterview-devel mailing list
> Masterview-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/masterview-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-devel/attachments/20060615/b368d5aa/attachment.htm
RE: mv:generate="{template_dir_path}/{template_basename}.css"
way too verbose, even for me, but your argument about clearly distinguishing
when default extension will be used vs. not is good.
{template_path_base} might work, but alternatively maybe we need to revisit
{template_path}, it''s a bit confusing relative to the other keyword.
Lemme
think on this a bit more this morning.
[fwiw, I think I''m going to stop using my generates that are dumping
out
local <style> decls, but I''m keeping for the moment because it
turns out to
be a good test case for playing with our new target notations]
btw your new version of test/unit/template_spec_test fixed my unit test
failure, but am tinkering a bit more with paths and roots and init this
morning. Want to test a bit more on my own rails app and in clean installs
before commiting, but I think I can submit today.
~ Deb
_____
From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com]
Sent: Thursday, June 15, 2006 8:33 AM
To: djlewis at acm.org; masterview-devel at rubyforge.org
Subject: Re: [Masterview-devel] Integration status
Yes, this is how the keyword expander is currently implemented, it actually
just replaces the token inside of the {}.
Currently to do what you were trying to do you would use the following
mv:generate="{template_dir_path}/{template_basename}.css"
I think it is important to not blur the lines between what is substituted
since if there is business logic that is used in addition the the token
itself then this would be confusing. This also keeps our keyword
substitution light and simple which can be used for other things and not too
customized for this one case.
If you want we can create another different token which represents
{template_dir_path}/{template_basename} to make it simpler for the user to
use, but I think it is important for this to be different than the token we
are using to represent template path with default extension.
So if you want we can create {template_path_no_ext} or {template_path_base}
or something similar which logically consists of
{template_dir_path}/{template_basename} .
What do you think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-devel/attachments/20060615/27708fd5/attachment.htm
Sounds good.
I am fine with changing keyword expansion to either have another expansion
word, or if you want to simply make {template_path} the one without
extension then I that would work as well.
We could put the logic into the generate tag to always add default extension
if one doesn''t exist. In essence this would give you what you were
hoping
for.
mv:generate="{template_path}" generates foo/bar.defaultExtension
mv:generate="{template_path}.css" generates foo/bar.css
I guess maybe I should have thought about doing it that way rather then
changing the keyword expander. It does seem reasonable to me to do things
this way if we do it in the generator logic. I don''t know how much code
this
will affect, but most likely parser code that handles generator directive,
and some work in the analyzer since I have to do keyword expansion and some
substitution to be able to compare sections to determine if an imported
section is out of date with another. Basically if they specified literally
foo.bar in one place and in another file they imported {template_path} that
expands to foo.bar in another. Logically those are the same so my comparison
needs to indicate that. Rebuild or copy currently forces the built files to
have their keywords expanded since it is too difficult to accomplish
otherwise.
Let me know what you think and whether this is something that you want in
there real soon or if it could wait a while. I would like to firm up the
keywords themselves before next release, but if you felt that the adding
default extension in generator is low priority then we could wait with that
until later and not mess up anything we have defined.
On 6/15/06, Deb Lewis <djlewis at acm.org> wrote:>
> RE: mv:generate="{template_dir_path}/{template_basename}.css"
>
> way too verbose, even for me, but your argument about clearly
> distinguishing when default extension will be used vs. not is good.
>
> {template_path_base} might work, but alternatively maybe we need to
> revisit {template_path}, it''s a bit confusing relative to the
other
> keyword. Lemme think on this a bit more this morning.
>
> [fwiw, I think I''m going to stop using my generates that are
dumping out
> local <style> decls, but I''m keeping for the moment because
it turns out to
> be a good test case for playing with our new target notations]
>
> btw your new version of test/unit/template_spec_test fixed my unit test
> failure, but am tinkering a bit more with paths and roots and init this
> morning. Want to test a bit more on my own rails app and in clean installs
> before commiting, but I think I can submit today.
>
> ~ Deb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-devel/attachments/20060615/3412680e/attachment-0001.htm