Well looks like Pylons is now Pyramids, and here go hell come. Now I could go on explaining the differences (Which most likely I will once I get farther in), but this is more just a quick post.
ANSWER:
In the development.ini file, place this under the [app:pytrends] area
mako.directories=projectName:folderWhereYourTemplatesAre
For example, the project I have is pyzazz (Don’t ask me what that is cause I don’t even know) and the template folder is… well templates. So I have it as:
mako.directories=pyzazz:templates
MORE USELESS WORDS:
When using pylons I used mako. It was fast and well it was by default. Now the default template engine is Chameleon which (Sorry Chameleon creator) sucks. First time using it, it was throwing parser errors in javascript lines like:
if (urlParams.actual && urlParams.actual == 'true')
and it forced me to end an input with the </input> tag. And if you know anything about HTML, input tags DO NOT HAVE END TAGS. True story, go check w3.org if you feel like. Little things like that just annoy the hell out of me. Yeah I know it’s just html and javascript, the runts in the litter as far as programmers care, but you still can’t jack things up like that. And on that note: if someone who uses chameleon (Or helped write it) actually comes here, you are welcome to shoot down my claims.
Thanks for the tip! I had the same problem with Chameleon. It will take without , but only in the most vanilla of templates. The second you throw jquery into the mix everything goes bezerk.
Yeah and so far mako has been pretty good with pyramids. There are slight differences but that’s mainly due to how pyramid works.
should work fine in Chameleon.
Meh, forward slash was eaten. that is LESS-THAN input SPACE FORWARD-SLASH GREATER-THAN should work in Chameleon.
I think you are right but the issue is that it’s not good html. Now I realize that due to the nature of templating and dynamic content, there’s going to be torn up html. However, the valid html left over should be valid.
I beg to differ. Input tags, while generally not having a separate end tag, should have a forward slash at the end. That is the correct way to handle input, br, hr, and a few other tags in HTML.
Actually they don’t according to html specifics but closing is accepted too. The point was it’s annoying that simple things like that completely derail the system. I suppose one could argue that I get what I pay for, but why not just default to Mako since it works and was the default in pylons? Anyway, I was nerd raging a bit more than I should have and have since been happy with Mako. I’d probably just remove that part from the post but I don’t generally like deleting what I type since that seems weak at best.
Without looking at the whole is hard to tell but In xhtml the tag must be properly closed ie. .
bah, above.
Either I need make more nerd rage posts about Chameleon or HTML standards ’cause the comments is off the chain.
I believe that the intention of our Guest here was to suggest that input tags do need closed in XHTML. However, it seems a bit unnecessary to require XHTML coders to consider what the parser is doing, it probably does provide the parser with a bit less guess work. Chameleon doesn’t like guess-work, and wants you to set up your XML properly – so, you get an error.
Usually, you would close the tags in shorthand syntax instead of using a full second tag to close your input. This is easily done by adding an extra slash before the open tag is terminated. So, you would end up with something like this:
<input type=text value=”Some text.” />
This – of course – tells an XHTML parser to open this tag with the following attributes, and that it can also go ahead and close the tag. This is probably what the author of our article forgot to use.
Also, HTML5 doesn’t “require” these slashes to close a singleton tag – which might make more sense. However, I can’t help but wonder if there is a save in processing time for people that still provide the closed singleton tags…
I suppose I could also see it as a mark up rule for Chameleon itself, not unlike how asp.net web forms syntax is not the same as html. In that light I have no real ground to stand on.
You make a good point. Probably along the line they made a design decision to require the closing tags to eliminate the “guess work” that you pointed out since parsing html can be a pain in the -ss to as the least.