#musicbrainz

<img src="/static/images/release_editor/edit-off.gif" class="hidden switchable" title="Set" alt="Set" />

oh, yea - those too then, heh

basically, everything but the row wrapper, the main label, and the errors template

generic/row.tt will handle those

ok, you will also need to be able to pass object, too, to row.tt

else you have no intelligence

so [%- INCLUDE 'forms/generic/row.tt' field=form.field('artist_$i')label=l('Artist') object="artist_$i" type='switchable' %]

that's no problem, that will cascade down just fine

doesn't need any changes

ok, moved that bit to widget/switch.tt, and changed tracks.tt to ^^

how now does row.tt know to use switch.tt ?

pass type='switch'

but, as switch.tt includes some input.tt templates, those will also need a type given, or you'll end recursivly creating switch.tt's

you already do that on the checkbox, but line 13 needs type='text' on it

amazing how we're never on the same page, but still get shit done. :)

some of us are always drunk while the others are toiling at work. so odd.

ruaok: btw, having learned from our experiences in the past, btw, every single bit of js I write is getting documented as to exactly how to use / implement it :)

stubs was just to much a pita to make work :P

ruaok: always drunk you say? I'll get right on it!

Muz, good plan

Muz: thanks for picking up the slack.

brianfreud: I'm glad that experience helped. :-)

WTF @ the last three comments: http://blog.musicbrainz.org/?p=369

she sounds like my ex. :-(

haha

looks like blog spam to me :P

ruaok: The "Annual Report" link, links to 2006 - maybe that should be taken down, or renamed?

On MetaBrainz.org

brianfreud: http://bugs.musicbrainz.org/browser/mb_server/b... is a better version of the JS lookup code

I suppose.

luks: thanks. Even though it's called ArtistSelect(), does it also now do the label lookup?

yeah

k

it will need the server side to be written, too

the JSON server?

this script uses a different format than the current one, but since it doesn't exist in TT yet it shouldn't be a problem

yeah, the script that gives you search results in json

k. We actually have another need for data to be fed out with JSON too. I don't really know anything about the server end for JSON, not sure if both can be fed out from the same server, or if "server" is even really the right terminology.

it's just a regular page, but instead of html it will return json

ah, like the languages list page?

hmm, wonder if a JSON page can be templated then?

gettext for javascript uses JSON results to pass l() translations to js code

no, there are modules to generate JSON for you from a perl object

you can use templates for that, but I don't see why

like I say, I know nothing (yet) about the server side for JSON - only that gettext and your lookup both need JSON results to be fed in for them towork

hm, right, translating JS will be more fun

there's a JQuery plugin for it, made sure of that a week ago.

that should work

The .js client end seems straightforward enough. Now I just need to spend the next couple of days reading up on the server end of JSON

we will need a separate .po files for JS and the rest

why?

because there will be a lot of translations, but only few of them used in JS

sending all of them doesn't seem like a good idea

ah, not a technical thing, but rather, for faster response

if it's a webservice, though, rather than a hard-coded page, shouldn't it just be sending back only the requested string(s)?

Maybe Im crazy, but shouldn't this be set to "Interview" as per its last edit? http://musicbrainz.org/release/0775f70b-c750-47...

brianfreud: that would be slooooow :)

<link href="path/to/translation.json" lang="ro" rel="gettext"/>

And why are the release events not sorted the same as on http://musicbrainz.org/release/26b95b5c-e6c7-4e...

our "path/to/translation.json" will return all trasnlations in one request

for every language?

just the currently selected one

k

navap: hmm, well, it changed it from album to interview, but then the album one was cancelled...

But kot the Interview..

not*

so I guess it was something to do with the two edits cancelling each other or whatever

I will likely have to work with you a bit in figuring out how to pull off the server end of things for both JSON needs

I can do the server part if you want

yes, but when the spokenword->album one was cancelled, I presume it thought it was reverting the edit, changing interview to spokenword

well, to paraphrase ruaok, lol, first I'd at least like to learn how, even if you end up doing it in the long run :)

I am guessing, though, that that means writing a .pm over in /lib?

in lib/MusicBrainz/Server/Controller to be more specific

hm, I see..the edits should actually be in a different order.

do you recall what file held the old JSON server's code?

so it should be interview, but a glitch in the way the edits are handled broke it :P

but the new version should be simpler

wth are those comments rob :P

spam or psycho hose beast.

hmmm, looks straightforward enough

ok, scary... perl has begun to be comprehensible :P

depends on who's perl code are you reading :)

luks: more from a speed of code point of view, did you worry about eval() protections, or are we safe using it without too much concern, do you think?

eval() used where?

for anything fed to the client specifically by the two JSON feeds we're talknig about

eval(posted_vars[1])

what do you have json for?

notice you didn

er, jquery for

well, yes - and that plugin uses it

var messages = eval('(' + data + ')'); /// var fn = eval('(function(' + v + ') {return ' + expr + ';})');

LOL http://xkcd.org/

Indeed

:(

but I notice you didn't in your code

I need to find a GF like that. I'd be proud to be her BF.

brianfreud: my code uses $.getJSON

I'll take a look what does the gettext plusin uses eval instead

too bad such a useful function has to be so dangerous, by nature

I don't find it useful :)

in fact, I was never in a situation when I needed to use eval in any language

hm, actually that's a lie, I used it once in python:)

I've managed in a non-framework manner to avoid using it before, but you can end up doing cartwheels (I did, at least) trying to do what you need, and only what you need, for JSON feeds that tend to send WAY too much info back

how about DB transactions in perl?

pretty much need to use eval for that...

well, I mean different kind of eval

eval { } is the only way to catch errors in perl

ok

I meant eval with a string variable

oh fun, more snow coming down hard again

hmm, ok, a script file with a comment like this must be high on the list to port: /* TODO: remove this function */ :D

brianfreud: gonna merge now, that sound good?

such TODO usually means the function can't be simply removed, because other code depends on it :)

sure - you merging pronik's patches from yesterday too?

brianfreud: somewhere in the perl it says "Delete this when we use a real database" that makes me chuckle

brianfreud: if you've merged them into your branch, then yes, probably :P

luks: yes... hence why, whenever possible, I'm throwing out old stuff, as a lot of it just fixed things other things broke.

in this particular case, movefocus.js fixed one thing... and broke Opera anyhow

YAY! :)

what's the yay about?

Been talking with Neil via email... he just did a quick code audit and relicensed Diff Match and Patch as LGPL 2.1 (as opposed to Diff_Match_Patch, which is identical, but remains Apache 2.0)

brianfreud: huh?

neil who?

Fraser - the guy who now works for Google, and who wrote the js diff engine that's a ton better (and faster) than the one by John Resig which we were using

I don't think git is really working out how it should be because of git-svn :(

i just tried to merge your branch, and even bits where there's no conflict, git thinks are conflicts

common problem from what I've read aCiD2

:(

is it safe to call the situation a mess yet?