On Mon, Oct 5, 2015 at 11:46 AM Tiffany Grenier <[email protected]>
wrote:
> Hi,
>
> Thanks for reviewing all of this :-)
>
No problem. Thanks for all the great suggestions.
Concerning my use case, maybe you can find an easier way of doing it, but
> in order for you to understand what I am trying to achieve, here is what I
> currently have:
> [(template first)][t][r]
> [(template each)][if equal "female" "{+gender}" || equal "undef"
> "{+gender}"][if less {(counter 0 id=checkcounterf)}
> 4][c][else][r][c][if][if equal 4 {(counter 0 id=checkcounterf)}]<(counter
> output=false start=0 id=checkcounterf)>[else]<(counter output=false
> id=checkcounterf)>[if][check family{:newfamilyrelation}[] "{+p}" [if equal
> find={+p} list='{:family{:newfamilyrelation}}' || inlist find={+p}
> list='{:family{:newfamilyrelation}}'] checked=true[if]] {+title} [if]
> [(template last)][t]
>
If it works, great! :)
>
> I was keeping the check on $page in order to avoid breaking things already
> in place. That's it. Currently, if you have a page named
> code.embed.gui.main and a textarea in the main page, then
> code.embed.gui.main will be used. Might be a wanted feature. Or not. It's
> totally your call (and your code).
>
> I have to try this out. Again, one of what I was trying to achieve was to
> avoid breaking pages. But it looks fine to me. Although my textareas do
> have the same name (content), I can simply rename one to somehting like
> mycontent and use a command like [command content mycontent] before calling
> savedata.
>
I think it was probably not an intended feature--more likely a bug. It
certainly seems much simpler and clearer this way.
>
> I was rather thinking of having both [guibox name gui=true][guibox] and
> [box name][box]
>
> I see. But if the div solution works, let's just keep it like this.
My concern is that at the moment, we have the highlight mark-up with the
> pipes, that creates spans with class "highlight", as well as a command
> "highlight" that can be customized in order to change the colors. I was
> suggesting to use the "mark" tag in the first case. We can have both <mark>
> and <span class="highlight">, but then we will have 3 ways of highlighting
> text...
>
Oh, I see. Yes, that's a simple fix. Will change the fontstyles function to
use mark. :)
It does up the browser compatibility requirements. Is that an issue?
>> Here is what I finally came up with (you will notice that my custom
> markers are already in there, as I give special styles to the i and b tags:
>
> $BOLTfontmarkup =
> array('*'=>'strong','/'=>'em','_'=>'u','@'=>'pre','='=>'del','-'=>'del',':'=>'i','|'=>'mark',';'=>'b');
> $fontStyleMarkup = implode(',',array_keys($BOLTfontmarkup)).',#,+';
> MarkUp('style', 'fonts',
> '%(('.str_replace(',','|',preg_quote($fontStyleMarkup,'_')).')\2)(.+?)\1%me',
> "BOLTMextendedfontstyles('$2', '$3')"); // Misc BOUNDED font style
> shortcuts: *Bo/It_Un|Hi@Sp#Bx
> MarkUp('style', 'fonts2',
> '%^\s*(('.str_replace(',','|',preg_quote($fontStyleMarkup,'_')).')\2+)(.+?)$%me',
> "BOLTMextendedfontstyles('$2', '$3')"); // Misc font style shortcuts for
> WHOLE LINE: *Bo/It_Un|Hi@Sp#Bx...
>
> function BOLTMspanordiv($type, $param='', $text, $html='span') {
> $text = BOLTstripslashes($text);
> $style = $type === '' ? $html : $type;
> if (strpos($text, "\n") !== false) $html = 'div';
> if ($type == 'size') $style = 'font-size';
> if ($type == 'align') {
> $style = 'text-align';
> $html = 'div';
> }
> $attr = '';
> if($param !== '' && $style != '') {
> $attr = "style='$style:$param;'";
> }
> else if($param != '' && $type != '') {
> if($style == $html || $style == $type) $attr = "class='$type
> $param'";
> else $attr = "class='$type $style $param'";
> }
> else if($html != $style) $attr = "class='$style'";
> return "<$html $attr>$text</$html>";
> }
>
> function BOLTMextendedfontstyles($type, $text) {
> global $fontStyleMarkup,$BOLTfontmarkup;
> $extendedmarkup = $fontStyleMarkup.',>,<';
>
> preg_match('%(('.str_replace(',','|',preg_quote($extendedmarkup,'_')).')\2)(.+?)(\1|$)%m',
> $text,$matches);
> while
> (preg_match('%(('.str_replace(',','|',preg_quote($extendedmarkup,'_')).')\2)(.+?)(\1|$)%m',
> $text) == 1) {
> $text =
> preg_replace('%(('.str_replace(',','|',preg_quote($extendedmarkup,'_')).')\2)(.+?)(\1|$)%me',
> "BOLTMextendedfontstyles('$2', '$3')", $text);
> }
> $type = str_replace(Array('>', '<'), Array('>', '<'), $type);
> $len = strlen($type) - 1;
> switch ($type) {
> case '#' : return BOLTMbox('type=box', $text);
> case '+' : return BOLTtranslate($text, '');
> default: return BOLTMspanordiv('','',$text,$BOLTfontmarkup[$type]);
> }
> }
>
> I am not fully satisfied by the special cases of handling ++ and ##, but
> it suits my needs at the moment (as I have used various html tags). But I
> also need to allow giving to $BOLTfontmarkup a classname instead of a
> tagname. Maybe assume it is a classname unless it appears in $BOLTattrs...
>
This is a clever way to do it! I like the idea of being able to define the
list of allowed markups but I'm not sure how necessary this is. It is
already quite easy to add a new markup rule if someone wants a custom
markup. Or to customize an existing rule as needed. I suspect doing so
would not be much harder than defining the array. I'll think on this some
more and consider it.
Cheers,
Dan
--
You received this message because you are subscribed to the Google Groups
"BoltWire" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/boltwire.
For more options, visit https://groups.google.com/d/optout.
