If you knew me, you would know I am all about examples. There is no
clearer way, IMO, of expressing the intent of a library method than
with an example(s). But examples are sometimes hard to do, at least to
do right. Check the win32 API docs for examples of not done right
examples.
That said, it took a little bit to wrap my head around mv:block, at
least from the example. I got the intent of the directive, but the
example left me wanting. That said, I''d like to propose this version,
modified from the original: (Sorry if it wraps wrong in the email)
<div id="result_list">
<div mv:block="products.each do |product|"
mv:content="product.desc">foobar1</div>
<div mv:replace="">foobar2</div>
<div mv:replace="">foobar3</div>
</div>
becomes
<div id="result_list">
<% products.each do |product| %>
<div><%= product.desc %></div>
<% end %>
</div>
What struck me was that you''d want to use the bound variable
''product''
inside the loop, and therfore inside the content of the tag. What
isn''t clear to end users is that MV directives are stacked, and
therefore get rendered as they are popped off the stack*. So combining
directives on the same tag creates the resulting XML structure
correctly. Hopefully, this example makes that clearer.
Generally, I don''t like to combine more than one library method in an
example, and here I have 3. But MV is a different sort of a beast.
Directives are not always meant to used in isolation, so the examples
should reflect that. The final two mv:replace''s could be left out, but
I felt that in visuallizing the template HTML, the user would probably
have 3 example lines in his block for verticle spacing reasons.
Ed
*One hopes they are stacked the correct way, regardless of the order
in the directive, IOW some priority ordering is in place?
--
Ed Howland
http://greenprogrammer.blogspot.com
Yes the example in the docs for block could definitely be improved. One might do something like <table> <tr mv:block="products.each do |product"> <td mv:content="product.name">namehere</td> <td mv:content="product.price">pricehere</td> </tr> </table> Alternatively its a better practice these days to use partials for these iterations (however using partials will currently be slower than using direct blocks like above so it is a trade off for maintainability and clean looking code). The following masterview tags will do the same thing by creating and using a _product partial. <table> <tr mv:gen_render=":partial => ''store/product'', :collection => @products"> <td mv:content="product.name">namehere</td> <td mv:content="product.price">pricehere</td> </tr> </table> Yes, you are right we should show the combinations of directives that make sense. Good point!! And yes, output from directives is based on the priority of the directive (if specified) so that regardless of how you declare them in the element, they get nested appropriately. Things like mv:if taking precedence over mv:block for instance. The priority if not specified is medium and then some directives override this to be higher or lower so they will nest properly. Thanks for the ideas and input!! Jeff On 7/6/06, Ed Howland <ed.howland at gmail.com> wrote:> > If you knew me, you would know I am all about examples. There is no > clearer way, IMO, of expressing the intent of a library method than > with an example(s). But examples are sometimes hard to do, at least to > do right. Check the win32 API docs for examples of not done right > examples. > > That said, it took a little bit to wrap my head around mv:block, at > least from the example. I got the intent of the directive, but the > example left me wanting. That said, I''d like to propose this version, > modified from the original: (Sorry if it wraps wrong in the email) > > <div id="result_list"> > <div mv:block="products.each do |product|" > mv:content="product.desc">foobar1</div> > <div mv:replace="">foobar2</div> > <div mv:replace="">foobar3</div> > </div> > > becomes > > <div id="result_list"> > <% products.each do |product| %> > <div><%= product.desc %></div> > <% end %> > </div> > > What struck me was that you''d want to use the bound variable ''product'' > inside the loop, and therfore inside the content of the tag. What > isn''t clear to end users is that MV directives are stacked, and > therefore get rendered as they are popped off the stack*. So combining > directives on the same tag creates the resulting XML structure > correctly. Hopefully, this example makes that clearer. > > Generally, I don''t like to combine more than one library method in an > example, and here I have 3. But MV is a different sort of a beast. > Directives are not always meant to used in isolation, so the examples > should reflect that. The final two mv:replace''s could be left out, but > I felt that in visuallizing the template HTML, the user would probably > have 3 example lines in his block for verticle spacing reasons. > > > > Ed > > *One hopes they are stacked the correct way, regardless of the order > in the directive, IOW some priority ordering is in place? > > -- > 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/20060707/dce28c38/attachment.html
On 7/7/06, Jeff Barczewski <jeff.barczewski at gmail.com> wrote:> Yes the example in the docs for block could definitely be improved. > > One might do something like > > <table> > <tr mv:block="products.each do |product"> > <td mv:content=" product.name">namehere</td> > <td mv:content="product.price">pricehere</td> > </tr> > </table> > > Alternatively its a better practice these days to use partials for these > iterations (however using partials will currently be slower than using > direct blocks like above so it is a trade off for maintainability and clean > looking code). The following masterview tags will do the same thing by > creating and using a _product partial. > > <table> > <tr mv:gen_render=":partial => ''store/product'', :collection => @products"> > <td mv:content="product.name">namehere</td> > <td mv:content="product.price">pricehere</td> > </tr> > </table> > > > Yes, you are right we should show the combinations of directives that make > sense. Good point!! > > And yes, output from directives is based on the priority of the directive > (if specified) so that regardless of how you declare them in the element, > they get nested appropriately. Things like mv:if taking precedence over > mv:block for instance. The priority if not specified is medium and then some > directives override this to be higher or lower so they will nest properly. > > Thanks for the ideas and input!! >Glad to know I guessed that right. I like the partials idea. You should use that as an example for the gen_render directive. Somewhere the 2 directive example should be shown so people can get a feel for that. And your first table/td example should be the first example for mv:block, since it is clean. Ed> Jeff > > > On 7/6/06, Ed Howland <ed.howland at gmail.com> wrote: > > > If you knew me, you would know I am all about examples. There is no > clearer way, IMO, of expressing the intent of a library method than > with an example(s). But examples are sometimes hard to do, at least to > do right. Check the win32 API docs for examples of not done right > examples. > > That said, it took a little bit to wrap my head around mv:block, at > least from the example. I got the intent of the directive, but the > example left me wanting. That said, I''d like to propose this version, > modified from the original: (Sorry if it wraps wrong in the email) > > <div id="result_list"> > <div mv:block="products.each do |product|" > mv:content="product.desc">foobar1</div> > <div mv:replace="">foobar2</div> > <div mv:replace="">foobar3</div> > </div> > > becomes > > <div id="result_list"> > <% products.each do |product| %> > <div><%= product.desc %></div> > <% end %> > </div> > > What struck me was that you''d want to use the bound variable ''product'' > inside the loop, and therfore inside the content of the tag. What > isn''t clear to end users is that MV directives are stacked, and > therefore get rendered as they are popped off the stack*. So combining > directives on the same tag creates the resulting XML structure > correctly. Hopefully, this example makes that clearer. > > Generally, I don''t like to combine more than one library method in an > example, and here I have 3. But MV is a different sort of a beast. > Directives are not always meant to used in isolation, so the examples > should reflect that. The final two mv:replace''s could be left out, but > I felt that in visuallizing the template HTML, the user would probably > have 3 example lines in his block for verticle spacing reasons. > > > > Ed > > *One hopes they are stacked the correct way, regardless of the order > in the directive, IOW some priority ordering is in place? > > -- > Ed Howland > http://greenprogrammer.blogspot.com > _______________________________________________ > Masterview-users mailing list > Masterview-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/masterview-users > > > _______________________________________________ > Masterview-users mailing list > Masterview-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/masterview-users > >-- Ed Howland http://greenprogrammer.blogspot.com
Glad to know I guessed that right. I like the partials idea. You> should use that as an example for the gen_render directive. Somewhere > the 2 directive example should be shown so people can get a feel for > that. And your first table/td example should be the first example for > mv:block, since it is clean. > > EdYeah, and actually I goofed in my partial example, it is mv:gen_partial (since we renamed that from mv:gen_render to be clearer) <table> <tr mv:gen_partial=":partial => ''store/product'', :collection => @products"> <td mv:content="product.name">namehere</td> <td mv:content="product.price">pricehere</td> </tr> </table> I will take your advice and we''ll update the examples/documentation accordingly. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-users/attachments/20060707/0f4beca0/attachment.html