Ohmigosh my bad, Yaron!
----------------------------------------------------------------------------
----
The hack as described only applies to *fixed* content, in their case to
inserting a [[category:]] unconditionally:
My quick and dirty workaround at the time was to preload the following into
the free text area:
<noinclude{{subst:Rest_Of_Preload}}
and then in Template:Rest_Of_Preload have:
>[[Category:Catname]]</noinclude>
I don't know any workaround for preventing {{#set:}} calls (executed via
templates) from being inherited by a transcluding page. And I would amend my
suggested solution to be just: (a) add command-pair {{{output}}} and {{{end
output}}}. This pair encapsulates text that is to be passed to output by the
SF processor.
Example:
{{{output}}}<noinclude>{{{end output}}}
{{{for-template|x}}} ... {{{end template}}}
{{{output}}}</noinclude><includeonly>{{{end output}}}
{{{standard input|free text}}}
{{{output}}}</includeonly>{{{end output}}}
I readily acknowledge that some preprocessing may be necessary (a different
hook?) to temporarily swap-out xml chars within the {{{output}}}{{{end
output}}} text content, but that seems a small price to fix this without
resorting to weird character sequences.
Thanks- John
----------------------------------------------------------------------------
----
-----Original Message-----
From: [email protected]
[mailto:[email protected]]on Behalf Of Yaron Koren
Sent: Tuesday, March 24, 2009 6:37 PM
To: [email protected]
Subject: [Semantic Forms] Re: <noinclude> problem
Well, did you try the workaround? Adding such a feature still seems a
little too major for Semantic Forms, given the rarity of the need, and the
fact that it's not totally necessary.... by the way, my name's Yaron.
-Yaron
On Tue, Mar 24, 2009 at 4:43 PM, John McClure <[email protected]>
wrote:
My form's templates perform {{#set}} on behalf of a page. But when the
page is transcluded, those {{#set}} commands are being executed on
behalf of the transcluding page -- clearly in error. I tried having
the form's templates output a <noinclude> and <includeonly>
elements, but that doesn't do the trick (duh). Then I tried manually
inserting the <noinclude> element via Edit Source, but when the page
is then edited by form, SF repositions the template calls outside of
the <noinclude> element that I inserted.
So I'm wondering if there needs to be an ability to identify when &
where <noinclude> & <includeonly> are to be inserted into a page
managed by SF. My two suggestions are to (a) add a wrap=elementname
parameter to the free text field which encapsulates (default) content
in an <elementname> element (b) create a special syntax, e.g., >
%elementname%< and >/elementname< and >elementname/<, to indicate a
begin, end, or empty tag to be inserted into the output.
Previous discussion about this issue (Subject: Trying to put
<noinclude>{{Books}}</noinclude> in an auto-created page) talked about
a workaround that's undesriable as a permanent solution -- I'll bet
there are better choices. I am heartened by Yoren's view (@Tue, 7 Oct
2008 23:41:51 -0400) that "it might make sense for SF to directly
handle <noinclude> tags".
Thanks - John
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Semantic Forms" 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/semantic-forms?hl=en
-~----------~----~----~----~------~----~------~--~---
