Flutterby™! : Two coding questions

Next unread comment / Catchup all unread comments User Account Info | Logout | XML/Pilot/etc versions | Long version (with comments) | Weblog archives | Site Map | | Browse Topics

Two coding questions

2011-11-04 17:21:49.563305+00 by Dan Lyke 7 comments

Two questions:

  • What's the right way to associate resource files with a Perl module? The code that maintains Flutterby.net is spitting out a bunch of JavaScript, and the right way to do this would be to put it in a .js file with a little parsing to split it into its component pieces and insert the dynamic data, so that I have the JavaScript all in one place, and so that the Emacs mode knows what to do.
  • Anyone got experience with KML and OpenLayers? I see the KML layer, but it doesn't appear to be rendering anything and I'm not sure why. I'm also trying to figure out what the magic incantation to get my base layers to render as base layers is, but that's a different problem.

[ related topics: Perl Open Source Graphics Clowns hubris ]

comments in ascending chronological order (reverse):

#Comment Re: made: 2011-11-04 17:36:39.811523+00 by: other_todd

I'm not sure I understand the first question. Is the code writing the JavaScript on the fly, or is the code taking apart an existing .js file and parsing/reprocessing it? I tend to keep .js files somewhere near my body of standing HTML files, if I have any ... but if you don't have any, then it really just falls to you to pick an arbitrary location for the .js and stick to that, so everyone knows where to find the .js.

I guess - as I also said on Twitter - I'm not clear on what you mean by "associating" a resource with a module. I don't know if that concept actually exists in the Perl world. But I suspect I'm just being thick here, and missing whatever it is you mean.

#Comment Re: made: 2011-11-04 18:04:34.902213+00 by: other_todd [edit history]

OK, so, I gather from your Twitter comments that you've got lots of in-place literal blocks (<<EOF) which you spit out with some parsing (variable substitution perhaps). Those become a pain in the ass. Unfortunately I don't know if you want to adopt my solution, which is to use a full-blown templater - I use Template Toolkit for all my page-generating code and keep all the boilerplate blocks in the templates, not in the Perl.

Anyway, assuming you're not using a templater, there's still no "association" per se. If you want to store the boilerplate snippets outside of the script, it becomes a matter of keeping your own track of where your snippets files are*, then having the code read the snippet of boilerplate, parse it, and spit it back out ....

If you're just trying to get all those in-place blocks to the bottom of your code where they'll be out of the way, you could look into the use of the _DATA_[Wiki] magic word**, which says, "everything after here is not interpretable code and can be accessed by a special filehandle as if it were an external data file." Look here http://perldoc.perl.org/perldata.html and scroll down to "Special Literals."

*As was noted by genehack, there are libraries which could help with that if need be, e.g. http://search.cpan.org/~adamk/...areDir-1.03/lib/File/ShareDir.pm **Magic word is DATA with two underscores on either side of it. I couldn't find a way to keep it from being parsed here.

#Comment Re: made: 2011-11-04 18:20:05.617728+00 by: John Anderson

To expand on my Tweeted answer: one idiomatic way to do "I want to distribute this non-code file in my module and get at it later, once my module is installed and the paths are all wacky" is File::ShareDir. It does what it says on the tin.

Also seconding TemplateToolkit, since it sounds like what you've got is a "generate a file from dynamic data" problem, and TT is excellent at that.

#Comment Re: made: 2011-11-04 18:57:28.739412+00 by: Dan Lyke

Thanks, I think File::ShareDir is as close as I'm going to get to what I'm looking for.

So, yeah, as clarified on Twitter: I've got a bunch of JavaScript strewn throughout this Perl. It's a bitch to read, Emacs indenting is confused as hell, it needs to be templated in another file. I figured that if I could figure out where the .pm file is, I could read the "OpenLayers/LineSegment.js" file, stuff in my own coordinates, and dump that into the output HTML.

I want a separate file mostly because I want Emacs modes to work correctly. I've done the "Build step which coalesces a number of files into a single Perl file" thing before and that has a bunch of limitations.

I'll look again at TemplateToolkit. I've used it a couple of times and always felt like it was the wrong level of whatever-it-is for what I'm doing. On the other hand, sometimes adjusting my workflow for the accepted standard is fine.

#Comment Re: made: 2011-11-04 19:52:50.250458+00 by: John Anderson

If it's just a single file, it's sometimes simpler to just use the DATA filehandle plus TemplateToolkit, and manually switch the file mode in Emacs when you need to edit the embedded file. TIMTOWDI. 8^)

#Comment Re: made: 2011-11-04 20:20:30.781736+00 by: Dan Lyke

It'll be a bunch of different segments of files. I've got the "create a map" template, then the "add a typed layer" templates for KML, GeoRSS, popup markers, and line segments. I had been doing this all with the Google Maps API, but the types map a little less closely from the Mediawiki <googlemaps> plug-in syntax to the OpenLayers calls. So I've got prefix boilerplate, some data munging and output (and that may include letting JavaScript do geographic projection transformations, or doing it in Perl), and then closing the block for each of those layer types.

I think the right way is more than one file, but I may put in some comment blocks which let me break up a single file smartly.

#Comment Re: made: 2011-11-05 10:23:57.293199+00 by: meuon

Re: .js files, I use links in the html to static .js files for things that don't change, so they get cached well, and abuse in line <script>code here</script> much more than I should for the dynamic things. But "joe" deals with it well format-wise.