what's the difference between metal:block and tal:block?
I'm not understanding when to use either. I sometimes see a tal:block nested in a metal:block, and sometimes the either way, or sometimes just one of the two. What's the difference between them? TIA, Gerry
Gerry Kirk wrote:
I'm not understanding when to use either. I sometimes see a tal:block nested in a metal:block, and sometimes the either way, or sometimes just one of the two.
What's the difference between them?
A <metal:block> tag allows you to use METAL statements without having to prefix each attribute with 'metal:', while <tal:block> does the equivalent for TAL statements. Cheers, Evan @ 4-am
I'm not understanding when to use either. I sometimes see a tal:block nested in a metal:block, and sometimes the either way, or sometimes just one of the two.
What's the difference between them?
A <metal:block> tag allows you to use METAL statements without having to prefix each attribute with 'metal:', while <tal:block> does the equivalent for TAL statements.
One uses these when there's no obvious or necessary tag in which to put a METAL or TAL declaration. It's quicker to write than a div/span plus a tal:omit-tag. Note that the name of the tag after the namespace (block) can really be anything. But 'block' seems to be our de facto standard. --jcc
J Cameron Cooper wrote:
One uses these when there's no obvious or necessary tag in which to put a METAL or TAL declaration. It's quicker to write than a div/span plus a tal:omit-tag.
Note that the name of the tag after the namespace (block) can really be anything. But 'block' seems to be our de facto standard.
--jcc
JCC, I guess I understand the syntax part of the question, but what I don't understand is why in some cases a METAL declaration is needed. Let me give you an example, a code snippet from a stock Plone site. This code is inside a <metal:block define-macro>: <tal:block tal:condition="no_types"> <select id="filter_selection" name="filter_by_portal_type:list" style="float: left" onChange="submitFilterAction()" tabindex="" tal:attributes="tabindex tabindex/next|nothing;"> <option value="#" tal:attributes="selected python:test((len(filterTypes)>1 or len(filterTypes)==0), 'selected', '');" i18n:translate="label_show_all_items"> Show All Items </option> <metal:block tal:repeat="type types"> <option value="#" tal:define="typetitle type/Title; typeid type/getId" i18n:translate="label_show_x_only" tal:attributes="value typeid; selected python:test( len(filterTypes)==1 and (typeid in filterTypes), 'selected', '');" ><span i18n:name="type"><span i18n:translate="" tal:content="string:${typetitle}" tal:omit-tag="" /></span>s only</option> </metal:block> </select> <input type="hidden" name="filter_by_Subject:tokens" value="" /> <!--you can filter by subject keywords by filling in this value--> </tal:block> TIA, Gerry
I guess I understand the syntax part of the question, but what I don't understand is why in some cases a METAL declaration is needed. Let me give you an example, a code snippet from a stock Plone site. This code is inside a <metal:block define-macro>:
<tal:block tal:condition="no_types">
<select id="filter_selection" name="filter_by_portal_type:list" style="float: left" onChange="submitFilterAction()" tabindex="" tal:attributes="tabindex tabindex/next|nothing;">
<option value="#" tal:attributes="selected python:test((len(filterTypes)>1 or len(filterTypes)==0), 'selected', '');" i18n:translate="label_show_all_items"> Show All Items </option>
<metal:block tal:repeat="type types"> <option value="#" tal:define="typetitle type/Title; typeid type/getId" i18n:translate="label_show_x_only" tal:attributes="value typeid; selected python:test( len(filterTypes)==1 and (typeid in filterTypes), 'selected', '');" ><span i18n:name="type"><span i18n:translate="" tal:content="string:${typetitle}" tal:omit-tag="" /></span>s only</option> </metal:block>
</select>
<input type="hidden" name="filter_by_Subject:tokens" value="" /> <!--you can filter by subject keywords by filling in this value-->
</tal:block>
You mean the option repeat toward the end, right? I can see why that would be confusing. There really isn't any reason (apart, perhaps, from historical) for that to be a metal:block. If it needs to be a block, it would be better written as '<tal:block repeat="type types">'. Of course, that tal:repeat could/should probably be moved into the option tag, which is what is really repeating. (Though perhaps the use of the define nixes that. I'd have to check the order of operations.) Similarly, the very first tag has redundant information, and could be written '<tal:block condition="no_types">'. Note the extract above works just fine (although perhaps a little slower than it might otherwise be) because of the way namespaces work. Saying <metal:block> gets you nothing more than the ability to use metal attributes without their own namespaces in a non-rendering tag, and unless you actually use a metal statement in it, it's essentially equivalent to, say, <span tal:omit-tag="">, but shorter and less explicit. (Plus a little extra compiler work, I guess.) And, as the first tag points out, there's no problem with explicitly specifying the namespaces even when they're implied. It's just a little more typing. --jcc
participants (3)
-
Evan Simpson -
Gerry Kirk -
J Cameron Cooper