August 24th, 2002

concerned, frustrated
  • mart

core1.s2 proposals: Breadcrumb and Parent links

Here's another updated proposal paraphrased from an email. It's wide again, I'm afraid. (Am I allowed to put linebreaks inside docstrings? What other docstring syntax rules should I be aware of?)

First, to make the rest of this easy, we can use a Link class. This is a modified version of a similar thing used for links in my LiveJournal core layer.

class Link
"Used to represent links between different pages within a user's site."
{
    var string url "The URL which the link should point to.";
    var string caption "The caption for the link";
    var string dest_view "A string representing the viewtype being linked to (eg 'gallery', 'index', 'picture').";
    var bool current_page "True if the link is linking to the page the viewer is already on.";
    function to_string() : string "Return a link to the destination view.";
}
# default implementation of to_string()
function Link::to_string() : string {
    return linkif($.current_page, $.caption, $.url);
}

With this in place, some interesting new things can be added to the Page class:

   var Link[] breadcrumbs
  "An array of links to everything from the user's front
   page to the currently-viewed page in link descent order";

  var Link parent_page
   "Use this link to create an 'Up' link to the current page's parent page.";

The breadcrumb array looks a bit like GalleryDescent at first glance, but is a lot more flexible as it allows other kinds of pages such as the user's main index page, picture pages and other miscellaneous pages (rendered by MiscPage) to be included in the breadcrumb links. Also, I only just today worked out what GalleryDescent is because the name made me think it was an array of galleries under the current gallery, so maybe a different name for that would be a good idea. (GalleryAscent? It is a bunch of links allowing you to ascend to higher galleries…)

Benefits of the Link class:

  • Keeps it all tidy in one package and simplifies the link output code.
  • The $.dest_view member makes it easy for layouts to add an icon depending on what kind of view is being linked to: in case it wasn't clear, it should be set to whatever $.view will be set to on the target page. If it wasn't clear, I'll have to think of a better docstring.

The LJ Link class has some extra allowances for i18n. However, since everything on FotoBilder has an externally-defined title right now (either a gallery name, an image name, or the global title) I didn't allow for it here. My concern with this is anything which is rendered by MiscPage: they will have static titles, of course, but there's nothing really to stop them pulling those titles from UI-free properties. The way I see it working is that the MiscPage populator would just put that property name in the Link caption as well as the page title, thus negating any i18n issues here.

I have a concern that the fact that users are going to be required to set $*global_title in every single style they make sucks. (Sucks more than the structure of that last sentence, in fact) Unless $*global_title is set identically in all styles, the links will become unintuitive. The only minor benefit to making this a style property is that Brad's German holiday photos could say “Brad's Photos” (an example global title) in German, but even that might be considered harmful. I dunno. It feels like “Global Title” (read: “Name of my photo site”) should be a user account setting rather than a style setting.

amused, happy
  • mart

S2 Language Proposal: Read-only Data Members (and also, hidden stuff naming convention)

Sorry. I'm madly switching back and forth between compiler and core as I go over my Sent Items mail folder looking at all of the old stuff I sent. I don't think I actually sent this as a proposal directly, but I was reminded of it when reading over an old proposal for changing the Color class on LJ, which turned out to be not such a good idea.

The Color class has some ‘internal’ members which store the current red, green and blue values for the color. They're named with an underscore prefix right now, which I think is bad because (as I've proposed before) I feel that names starting with underscores should be reserved for the use of the backend. ($_ctx is used to represent the S2 context for the perl backend, for example. That variable name in particular is currently reserved, but it'd be better to generalize it to allow both for future expansion and also for classes handled in the builtin layer (like Color) to store ‘hidden’ data members.) One current application of hidden data members is that the ItemRange class could store a simple URL template in a hidden member for use with its url_of() method.

However, we can't really hide the red, green and blue values because they're needed for generating color codes in formats other than HTML's (since S2 should theoretically be able to generate anything), so let's make them regular variables but not allow S2 code to assign to them, only the backend. This means that their underscore prefix can be removed, and ensures that they'll never end up containing an invalid color value (anything outside the range 0‒255). It also ensures that the string member containing the HTML color (also readonly) will always be in sync. A final nicity is that the docstring viewer thingy can automatically put “Read-only” in front of the docstrings for read-only members, so that people know not to try to set them.

The syntax can be simple enough…

class Color {
  var readonly int r;
  var readonly int g;
  var readonly int b;
  var readonly string as_string;
  # and the methods, afterwards
}

The S2 compiler can then simply throw an exception whenever it encounters an assignment operator where the left operand is a read-only data member. The read-only keyword should obviously only be valid for class member variables. It just means that the variables have to carry an extra boolean value in their type representation in the compiler. I could probably implement the assignment-trapping part myself, but I'm not too sure on dealing with the readonly keyword because I've never fooled with anything in the compiler that isn't an operator before.

amused, happy
  • mart

viewer_logged_in() and viewer_is_owner()

Any special reason why viewer_logged_in() and viewer_is_owner() are functions rather than just boolean data members of the Page class? Seems to me that since the remote user (if any) must already be known, (so that the backend can decide what to insert into the data structure based on security settings) the data members could just be assigned to directly, thus saving a function call and making for simpler S2 code.

On a slightly related note, it seems to be a bad idea to make styles display “Log In” links when the user is not logged in, because most sites running FotoBilder will be private installations which only have an account for one or two users, and in this case a log in link for users browsing the galleries makes little sense. Perhaps this should be a boolean style property which defaults to off, thus allowing users to choose?

amused, happy
  • mart

Accounts Without Gallery Abilities

This was originally part of my last post, but it got off-topic so I thought I'd begin another post. Heh.

I'm hoping that it's going to be possible to have accounts which don't have associated galleries. For example, I would want to give some of my friends accounts on my installation so that they can view my pictures, but that doesn't mean they should also get their own galleries alongside that account.

LJ's ’policy’ has always been that it doesn't matter that all accounts have journals because the empty journals attached to accounts used for reading don't do any harm, but on a private FotoBilder installation it'd be considerably more annoying to have fifteen blank galleries just so fifteen of my friends can see pictures. I'd like to be able to configure the UI so that the “Create Account” page can be set to allow the creation of both gallery and read-only accounts, or each of those separately, or no accounts at all. It'd also be nice if certain accounts were able to create different kinds of accounts despite the site-wide settings.

Example of this: photos.fitzpat.com has the site-wide setting set to not allow the creation of any accounts, but the ‘brad’ account has access to create both full accounts and read-only accounts, which Brad Fitzpatrick can use to create full accounts called ‘cole’, ‘kelly’, ‘ryan’ and ‘sandy’. Each of these accounts can be set by Brad so that they can create read-only accounts, and then Cole can make read-only accounts for his friends Tim, Waldo, Fred and Joe so that they can view the special pictures he took at some social gathering.

This is starting to look a lot like LJ's privs system. In this example, Brad would have the ‘admin’ priv which allows him to bestow other privs just like on LJ, and the ‘createaccount’ priv with the arg set to ‘all’ so that he can create all kinds of accounts (which at the moment is only two, but more might be needed later for some reason). Cole (and all of the other family members) would only have the ‘createaccount’ priv with the arg set to ’readonly’, and no ‘admin’ priv at all because Cole isn't allowed to give his friends access to create new accounts. (or, maybe he's only allowed to give access to his friends to create read-only accounts, priv ’admin’ arg ’createaccount:readonly’.)

This behavior is already how the LJ priv system works, so can we just pull that over wholesale, including the management interface? I can see privs being useful for other things down the line, and site-local privs will probably be useful on PicPix.com when it gets so popular that it becomes time to enslave overly-generous geeks again. ;)

belize
  • brad

S2 changes

Per Mart's bug report and request, string stuff in S2 has been cleaned up.

Quick review:

# this already worked... string to object(string) constructor:
var Color c;
$c = "#123456";

# this already worked:
"Your color is: $c";

# but due to an optimization bug, this was broken:
"$c";
# (but it works now)

# this is new:
var string s;
$s = $c;

In that last case, NodeAssignExpr just forces its rhs expected type to string when it sees its left side is a string.

The basic change in the compiler is getType() takes an optional wanted type which different nodes can try and coerce their contents into.

Next up: readonly class variables. That should be easy.
belize
  • brad

Framed style, proof-of-concept

Using Page.args{} and Page.self_link, it's now easy to make a frame style. This one took is incredibly crude, but it only took a couple minutes:

http://www.picpix.com/brad/gallery/0000g61t

Now that core1.s2 is starting to mature, I'm going back to working on the FotoBilder/S2 interface code, so the S2 code has full access to everything it already thinks it does.

That means that halkeye can then rejoice and start making styles.