Log in

No account? Create an account
June 1st, 2003 - LiveJournal Development [entries|archive|friends|userinfo]
LiveJournal Development

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

June 1st, 2003

Problem with BML [Jun. 1st, 2003|01:37 pm]
LiveJournal Development


[mood |confusedconfused]

Okay this is driving me nuts. I am trying to write a new generic.look file, and all this block of code is returning is the word nothing, rather than the sidebar (I have it returning to the word nothing just to make sure it is returning somthing.


$ret = "";

sub dump_entry
my ($ret, $listref, $depth) = @_;

foreach my $mi (@$listref)
if ($depth==0) {
$$ret .= "<P><IMG SRC=\"<?imgprefix>/insane/bullet.gif\" WIDTH=10 HEIGHT=10 HSPACE=2 ALIGN=ABSMIDDLE>";
} else {
$$ret .= " " x ($depth*3+1);
$$ret .= $mi->{'cont'} ? "  " : "- ";

my $name = $mi->{'name'};
$name =~ s/ / /g;
if (! defined $mi->{'uri'}) {
if ($depth == 0) {
$$ret .= "<B>$name</B><BR>";
} else {
$$ret .= "$name<BR>";
} elsif ($mi->{'match'} ?
(BML::get_uri() =~ /$mi->{'match'}/) :
(BML::get_uri() eq $mi->{'uri'})
$$ret .= "<B><SPAN style=\"background-color: #FFFFFF\"><FONT COLOR=#0000D0>$name</FONT></SPAN></B><BR>";
} else {
$$ret .= "<A HREF=\"$mi->{'uri'}\">$name</A><BR>";

if ($mi->{'children'} &&
($mi->{'recursematch'} ? $ENV{'REQUEST_URI'} =~ /$mi->{'recursematch'}/ : 1)) {
&dump_entry($ret, $mi->{'children'}, $depth+1);


&dump_entry(\$ret, \@sidebar, 0);

$ret .= "\nnothing\n";
return $ret;


Here is an example of what it looks like http://insanejournal.com/?usescheme=insanelooknew
link7 comments|post comment

Colours in the Core Layer considered Harmful! [Jun. 1st, 2003|03:13 pm]
LiveJournal Development



I noticed a while back that the default implementation of the EntryPage uses a core-defined colour for the “entry heading” bars, but I've not commented on it until now because I've been too busy to actively persue the subject. Now that I'm done with uni for the summer, I have plenty of time to debate this!

I think it is a bad idea to have any colours at all in the core layer. The most obvious reason against this is that, when an EntryPage is produced entirely with the core layer (so that the entire page is from core code) the entry bars are the only part of the page with a colour specification, which sets the background colour. The text inherits from the page text colour, which isn't specified and thus falls back on user settings. Consequently, users with a white-on-black colour scheme will be seeing white on that odd blueish colour on core-only comment views.

In addition, it is against the principle of the core layer for it to have colours at all. While it is quite easy to work around having this colour set in core when writing a layout, it adds inconsistancy to the system since until now colours have been the domain of the layout, with the layout free to define and use colours in any way that is appropriate, with an appropriate descriptive label specific to that layout.

What are the benefits to having this colour in core? Sure, it means that the default EntryPage implementation looks quite a bit like the old talkread page, but this is hardly a major win as layouts are going to redefine it anyway. I can see that it might be considered nice to have some easy visual feedback to show where comments start, but perhaps we could do that with CSS-added borders instead, which can thus inherit the text colour of the container?

As layouts get comment support, this default core implementation will become essentially invisible, so having a colour from it showing through into layoutspace seems slightly weird.

linkpost comment

[ viewing | June 1st, 2003 ]
[ go | Previous Day|Next Day ]