Ok, this is again expected, though admittedly undesirable behavior.
Currently, with all zones, a \n\n is added automatically to wrap the
last line in a p tag. In your case, you have one line, which makes it
the last line. So the p tags wrap the whole div exactly as your html
shows. Not ideal perhaps, but it solve some other problems, so I'm
not likely to scrap that unless we can find something better.
It does suggest to me at least a fix however:
Suppose you change the case of the zone in the skin, ie [[TOP]]
instead of [[top]]. This would set the zone to something uppercase and
block the extra line breaks automatically. That is assuming you have
made the change I mentioned in the last email:
if ($zone != '' && $zone == strtolower($zone)) $out = $out . "\n\n";
There are two other tweaks that are required. One, near the top of
BOLTgetzones, this line must be commented out.
// $zone = strtolower($zone);
And in BOLTmakepage we have to allow capital letters...
$out = preg_replace('/\[\[([a-zA-Z]+)\]\]/e', "BOLTgetzones('$1')",
$out);
The result of these changes seem to be that if you put [[top]] in a
skin, you get the line returns added. If you use [[TOP]] you don't.
Nice enough, if a bit quirky.
But I should add you could also do this--which is my general
approach--to insert the markup directly into the skin:
==[(pagecount)][[main|[^tnetwiki-header.gif alt='Some Alt Desc'
title='Some Title'^]]][if ! set {?myid}]<(persist)>[if]$$actions==
It is faster, because it saves BoltWire the trouble of having to load
the top page, and you don't get the \n\n because it is not in a zone.
In fact you could use html to generate the link and any other markup
you might want, and speed up the processing that much more. Anything
you can push to the skin already processed to html should speed
performance a bit.
I'm going to make the above changes to the core unless someone spots a
problem with them. We needed a way to distinguish between when we want
p's added and when we don't. The addition of capitalized zones is as
good an approach as any I can think of right off. I'm open to
suggestions of course...
Cheers,
Dan
On Wed, Nov 25, 2009 at 10:15 AM, Kevin <[email protected]> wrote:
> I have a similar problem with the top zone where the resulting code is not
> valid XHTML.
>
> With 3.3.
>
> In my top zone I have on 1 line with no line breaks:
>
> [(pagecount)][[main|[^tnetwiki-header.gif alt='Some Alt Desc' title='Some
> Title'^]]][if ! set {?myid}]<(persist)>[if]$$actions
>
> The code generated is...
>
> <div id='top'><p><a href="http://somewebsite/main"; ><img
> src='http://somesite/home/files/tnetwiki-header.gif' alt='Some Alt desc'
> title='Some Title' width="401" height="53" /></a><div class='actions' >
> </div></p>
> </div>
>
> Validator is not logged in, so none of the actions show up as I have them
> all hidden when the user is not logged in.
>
> While I can make the spacing in the <p>'s disappear in CSS, I can't make
> them themselves disappear which is resulting in XHTML validation errors that
> I can't seem to prevent. Since this is the top zone of basically every
> page, all pages won't validate.
>
> If I take out the page link, the <p>'s disappear but so does the clickable
> link in the title.
>
> [(pagecount)][^tnetwiki-header.gif alt='Some Alt Desc' title='Some
> Title'^][if ! set {?myid}]<(persist)>[if]$$actions
>
> So it is related to the link code which insists on placing a <p> in there.
>
> Then I run into the exactly same problem in the side zone... I have buttons
> created using <div>'s. The system adds <p>'s which makes it no longer valid
> XHTML
>
> I thought of perhaps an option to say don't do that in a specific zone but I
> suspect the output in even the body using that would be invalid.
>
> On Wed, Nov 25, 2009 at 6:06 AM, The Editor <[email protected]> wrote:
>>
>> On Tue, Nov 24, 2009 at 2:09 PM, Markus <[email protected]>
>> wrote:
>> >
>> > The goal should be that no if-hacks are needed like this one:
>> >
>> > [if whatever]...[if][if whatelse]
>> > here I need the line break but not that huge white space (see above)
>> > when whatelse is false[if]
>>
>> It looks like you are getting exactly what is expected. If you put the
>> line return outside the [if whatever] [if] then it will appear whether
>> the condition is passed or not. If you want the line return to only
>> appear when the condition is met, you need to put it inside the
>> conditional. It is simply a question of seeing the actual line return.
>> In your example it is **after** the closing [if].
>>
>> Though this issue has come up before, I think it is much more a hack,
>> and even counter-intuitive to extend the conditional to a line break
>> that follows or precedes the if wrappers. In other words, the if
>> statement's are behaving very literally, and in my view doing exactly
>> what they should be doing.
>>
>> Cheers,
>> Dan
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "BoltWire" 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/boltwire?hl=en.
>>
>>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "BoltWire" 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/boltwire?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"BoltWire" 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/boltwire?hl=en.
