Entries tagged with template toolkit

Current Mood: tickled
Current Location: Rat te Kāinga
Current Music: Elder Scrolls History - Morrowind

Entry tags:

18 June - 18 July 2020 code tour! HANG ON TO YOUR TIARAS

There was SO MUCH CODE CONVERSION oh my gosh.

kareila finished a knitting project and didn't pick up another one so CODE MACHETE TIME.

roadrunnertwice is still working on the spite-fueled redesign (also less DRAMATIC WOODCHUCK now).
80 issues, thirteen pages in the notepad before putting in the information. HAIL THE DEVS.

( hang on your shoes folks, where we're going we don't need roads!...we do need seatbelts though )

80 total issues resolved
Contributors:

kaberett,

kareila,

martindemello,

momijizukamori,

nfagerlund

That's all for me today, make sure to thank your devs!

Entry tags:

Creating AJAX post parameters for TT Controller?

I'm in the process of updating /customize/ to move it away from BML and a million widgets, and I've got most of the HTML-y stuff done, but I'm having trouble with the Javascript. The biggest part of this is redoing the AJAX queries, which were previously done in widget-specific ways and passed through a bunch of the Widget class handlers. Working off jQuery, I've gotten as far as getting it to submit a POST request which reaches the controller - but the param formatting is all wrong and missing a bunch of the parameters sent with a TT form POST request. Do we have methods for creating proper POST requests from AJAX?

Entry tags:

template toolkit

Converting BML to TT and routing in the presence of a widget

The workflow given in http://wiki.dreamwidth.net/wiki/index.php/Routing_and_Template_Cookbook:_BML_Conversion_Workflow doesn't indicate what to do when you find yourself in the presence of a widget, like for htdocs/support/submit.bml. Some questions an addition could cover:
- Can/Should I use the widget itself directly in a controller?
- Which parts of the widget need to go where?
- When is it safe to get rid of the widget itself? (eg, how do I know it's not used anywhere else)

I probably forgot some questions/issues. Discuss here and I'll try to summarize to the wiki?

Entry tags:

template toolkit

dw-nonfree overriding dw-free routing

I'm pretty sure this is a question for the magnificent

exor674, but here goes:

Let's say I convert the index page over to controllers/TT--it has two different versions, one for dw-free and one for nonfree!

How would one override the dw-free controller and/or template with the dw-nonfree one? What if one only needed to replace the template but not the controller, or visa versa?

ETA: Later I might try experimenting with detecting if a "home-local.tt" exists or whatnot, but my initial attempts at translating those pages with dw-nonfree are running into an interesting snag! Logged in it loads fine, logged out, there's some magical redirect that keeps happening until it goes boom. I'm trying to trace through the code to see where this is happening but no luck so far.

ETA2: Okay, the redirect was me forgetting to add anonymous => 1 to the controller call, woo! For the home page that sends it into a never ending loop of despair instead of being obvious. So far experimentation proves that putting a template with the same name in the dw-nonfree/views overrides dw-free/views, which is very good I think!

ETA3: Confirmed that just putting a new Home.pm controller in dw-nonfree/cgi-bin/DW/Controller does not override the dw-freecgi-bin/DW/Controller/Home.pm one. Going to try

fu's suggestion of hooks to add in extra variable content to the template rendering!

Current Mood: accomplished

Entry tags:

template toolkit

vim syntax highlighting for TT

If you use vim and you are editing TT files, and you don't have syntax highlighting set up, here's how to do it:

Grab this file and save it to ~/.vim/syntax/

One way to do that would be:

wget https://raw.github.com/vim-perl/vim-perl/master/syntax/tt2.vim ~/.vim/syntax/

Then add the following to your ~/.vimrc file:

"syntax highlighting for TT
au BufNewFile,BufRead *.tt setf tt2
:let b:tt2_syn_tags = '\[% %] <!-- -->'

Now everything should be much more readable!

Entry tags:

template toolkit

Converting a tricky recursive bit of BML code into Template Toolkit

I'm posting this to show a conversion of an old recursive bit of BML code into Template Toolkit. It's from customize/advanced/layerbrowse.bml -- You can view the page here. The section in question is the right column under the "Classes" heading. It is a list of all of the classes in an S2 layer, in a hierarchical fashion where subclasses are under their parent classes. Warning: this post deals with things like recursion, so if it's all gobbledegook to you, do not worry and feel free to ask questions if you want.

( On to the example! )

Entry tags:

template toolkit

A summary of linecounts of BML pages that need translating to Template Toolkit

Total files: 279

( List sorted by number of lines )

Entry tags:

template toolkit

Template Toolkit

This week, I am planning to start working on a patch that will require creating a new page. ( http://bugs.dwscoalition.org/show_bug.cgi?id=1843 )

From this post, I gather that it would be good if it could be done in Template Toolkit right from the start, am I correct?

Related questions: Is the end goal to replace all BML pages? If so, and if one feels the desire (I am looking at you, recent_comments.bml!), can we just open bugs and convert the pages? Is there going to be some organized push towards that goal? (it seems like a nightmare, but a few converted pages a month and it should be done in 2012 ;))

Entry tags:

Template access to LJ::set_(active|dynamic)_crumb and LJ::need_res

foxfirefey's let's keel BML ded (and eat its head) nudged me into TTizing the stats pages before they get too unwieldy. So (because that page uses crumbs) I'm looking at how to set a crumb in the template (which I think is the proper place to do it, since templates map better onto pages than controllers do IMO). The interface I'm thinking of (tentatively - I haven't actually tried this yet) is something along the lines of:

(something relying on RAWPERL, which is (and will likely remain) disabled, so filter/plugin it is instead, per exor674's comment below)

I'm also wondering whether to make it a filter (or something) in DW::Routing::Apache2 instead, but I don't want to make further work on it harder if I can avoid it.

Anyone has a thunk about this? (Specifically exor674 and foxfirefey, since they're leads on this, but not limited to them)