afuna_archive

For instance:


    foreach var string module ( $*modules_available ) {
        # FIXME: get the values in less hacky manner
        var string section = get_plural_phrase( 0, "module_${module}_section" );
        var int order = int(get_plural_phrase( 0, "module_${module}_order" ));

        $*module_sections{$section}[$order]=[$module];
    }

(but I should probably not let something like that creep into core. Long list of if-statements, it is.)

(Originally posted to Dreamwidth http://afuna.dreamwidth.org/6673.html)

Current Mood: geeky

One thing that has frustrated me about interacting with LiveJournal programmatically, is that ?format=light does not work on all pages. It's not really something that affects most users would notice, but certain (Greasemonkey) scripts would be much much easier to write if the entry/journal pages could be guaranteed to follow the same format.

Mostly I've kludged around it by working off of the archive pages, which respond to ?format=light, so I could get data consistently. I have a script which scrapes the lj-cut text, so it can be seen in the inbox which does this.

murklins has done me one better, with a script which lj-cuts your inbox, like the entry text. I do not know how I ever lived without this. Lifesaver. Adore, love. Seriously.

But for other pages, it's been a process of trial and error, trying to figure out whether ?format=light is supported (tag page supports it, showing a page based on s1shortcomings). Uh. Archive pages, as mentioned above. Reply pages and entry pages, obviously, using core, I think.

Not affected by ?format=light are friends and recent entries. LJ site scheme pages, meanwhile depend on the user's site scheme, unless you append ?usescheme=blah, which I always forget to /o\

It's all possible, but it can get messy depending on what you're trying to do. Which is why I love that LJ offers a mobile view. Love <3

The gist of it is that LiveJournal offers a minimalistic view for mobile phones/browsers (I suspect screenreaders could benefit). No header graphics, less junk overall, more consistent look/feel, and most importantly if you're hijacking it for scripting, it works consistently! To trigger, you need to supply the appropriate user agent:

GM_xmlhttpRequest({
   method: "GET",
   headers: {"User-Agent":"w"},
   url: $url_here,
   onload: function(details) {
       // do something with details.responseText
   });

The important part is the useragent line. The rest is just the normal stuff you need to fetch and process a page.

I haven't used it in an actual script. And since I don't play around with LJ much anymore, I'm not sure when I will. But it is a potential solution to what has up to now been a tedious problem.

Not the inside-inside, Perl guts, but trying to update all (DW) layout layers, to get all the updated features!

Long-term goal (actually, medium-term, because once the site goes live, everything needs to be stable, so I won't be able to do any drastic changes) is to turn this layout/feature chart entirely green. I know it's not possible; I can at least try what is reasonable.

~~One~~ The hard thing about developing with S2 "officially" is that the quickest (only?) way to get feedback on your changes is to apply the layout to your journal, use the S2 compiler (layeredit.bml), apply changes, check journal, rinse repeat. However, then you have to copy the updated layer to bin/upgrading/s2layers. I've found that last step error-prone: tedious to pick out the changes bit by bit and transfer them manually. If I try to replace the entire layer in one go, I find that I have a hard time copy-pasting more than a screenful in vi (hm, have I ever tried just truncating the file and then pasting everything into a blank file? I don't think I have. Maybe I should do have tried that before trying to work around it).

So, anyway! Perl script! You give it the name of the layout. It reads the updated version which is currently "live" (on your dev site ~~need to set the base URL; localhost works fine~~ reads from ljconfig.pl). It then updates the static file in bin/upgrading/s2layers. After that, just need to do cvsreport.pl or hg diff or svn diff or commit or whatever. I've stuck in my ~/bin, so I can run it from anywhere, which is pretty convenient:

http://afunamatata.com/scripts/dreamwidth/s2sync.old

(This assumes that $LJHOME is set properly, and live versus cvs directories are in their normal LJ-setup locations, though this is really more for DW, since it overwrites bin/upgrading in DW-free)

( Sample in action )

At some point, I may find it useful to modify it so that it accepts and upgrades multiple layouts (and themes??), but too much trouble to do so now, since I'm not touching themes at all.

And hopefully this will make development that much easier :) I was dreading keeping my live layout versus my diff-able layout in sync, but I am looking forward to coding this weekend now.

Update

exor674 just came up with a much prettier version <3 http://pastebin.com/f2fc673b3

I'm appropriating it for my own use.

Update2
Slightly tweaked version here: http://afunamatata.com/scripts/dreamwidth/s2sync!

(Basically, sanity check to make sure it's a layout layer, and also put the output directory into a variable, so that people who want to stick it straight into live instead of under cvs/ can change just the one line)

It now accepts either layer id (as a number), or layout name or redist_uniq, so either of these will work:

$ s2sync 333
$ s2sync bob/layout
$ s2sync bob

Also, output slightly changed:

dh-afuna@li-166:~/dw/cvs/dw-free$ s2sync 336
Can only handle layout layers at /dreamhack/8080-afuna/bin/s2sync line 33.
dh-afuna@li-166:~/dw/cvs/dw-free$ s2sync 333
bob/layout written to /dreamhack/8080-afuna/dw/cvs/dw-free/bin/upgrading/s2layers/bob/layout.s2

Current Mood: geeky

Back in January, I realized that you could probably figure out which individual tags filter you were viewing by using the (newly-added) parameter to each Userlite data_link:

3:09 AM me: hm
3:10 AM me: ma thinking of s2 at the moment
does this entry : http://community.livejournal.com/changelog/4356263.html mean that we can determine what tagspage we're on by checking the data link?
3:13 AM murklins: Looks like, but how do you check the data link?
3:14 AM me: Page has a hash of data links

I meant to play around with it, so I posted about it to remind myself, and then promptly forgot.

Then in May,

murklins(<3) needed to customize certain tags views, and reminded me about my idea:

12:51 AM murklins: Hey, this is how we find out if we're on a tags subset of the recent entries page right?
if ((size $this.data_links_order) > 0) {
  if ($this.data_link{"rss"}) {
    var Link dlink = $this.data_link{"rss"};
    if ($dlink.url->contains("?tag=")) {
      print "A Tags Page";
    }
  }
}
12:55 AM me: hee
I don't know :)
I don't tihnk I've ever seen that before
though the concept seems familiar, but my mind might be playing tricks on me
12:56 AM murklins: Oh, it was your idea! :)

And I remembered that I'd had that idea before, and decided to do something with it some day. (And then promptly forgot about it again.)

Then someone made an entry in

s2flexisquares asking whether it was possible to hide a sticky post when filtered by tags. And I was happy that I'd finally have a chance to play with the idea (almost a year after I first thought of it), so I wrote code and replied with it. Then she asked me whether it would be possible to make it so that you could show the sticky post only for certain tags, and after shaking off some rust I came up with this code.

It could be more flexible -- right now it won't work if you filter by multiple tags, but it's good enough, and I'm not crazy enough to try implementing a join/split function in S2.

(What if I made the tags an array instead of a hash? That would make it easier to input tag names -- ["tag1", "tag2"] instead of {"tag1"=>true, "tag2"=>true}, and it's unlikely that the list of tags this is used on would be long enough to affect performance either way.)

Other possibilities are to change colors or images depending on the tag that you're filtering by, or to change the behavior of entries with certain tags (for example, only show summaries for fic-related tags). And others! If you were motivated enough, you could make subtle changes to your layout for each tag you have. I'm not that motivated. :-)

Current Mood: accomplished

S	M	T	W	T	F	S
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30

Entries tagged with s2

I love me some little hacks

Getting more consistent "light" results

Playing with S2, from the inside

S2: detecting individual tags views (and doing stuff with it)

Profile

June 2009

Syndicate

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags