Here's the question in brief:
My blog posts at...
http://www.seanbradley.biz/blog
...totally lacks formatting. They're just a big block of plaintext. Any code or HTML tags such as /n or < br / > ...let alone h1, h2, etc...have no demonstrable effect on the way text appears on the page.
I'm running Flask with WTForms deployed on GAE. How can I fix this? Is there a way to implement a WYSGIWYG editor--like TinyMCE--into the form field for new blog post entries?
I'm going for a look as simple and elegant as...
http://www.quietwrite.com
or
http://lucumr.pocoo.org/
...or at a minimum something akin to Stackoverflow's own editor.
Formatting is rendered in the posts in all of the above upon publication (rather than via the grody overblown toolbar of an editor).
I'm not sure if what's prohibiting HTML tags from rendering in my posts is related to customization of a class in WTForms, or something which must be treated specially in GAE's datastore, or something I need to fix within Flask (e.g., the model for posts). Any clear solution on how I--as a relatively junior dev--can incorporate formatting into these blog posts earns the bounty. Specific code from the app below...
Note: there's also a Flask-Markdown extension, but I'm equally unsure as to how to integrate it to achieve the effect I want.
The question in detail, plus snippets from the code base
I'm running Flask (with Jinja templates / Werkzeug routing, of course) on Google App Engine, and confused about how to integrate a WYSIWYG editor into the page I have dedicated for blog posts...
I'm assuming, if incorporating TinyMCE, the call for the JavaScript goes in the header of the template...like so:
<script type="text/javascript" src="/static/js/tiny_mce/tiny_mce.js">
But, then--because, per se, there's no within the template or the rendered page itself, it's not merely--per TinyMCE's install docs--a matter of also adding the following block of code into the template...
<textarea cols="80" rows="10" id="articleContent" name="articleContent">
<h1>Article Title</h1>
<p>Here's some sample text</p>
</textarea>
<script type="text/javascript">
tinyMCE.init({
theme : "advanced",
theme_advanced_toolbar_location : "top",
theme_advanced_toolbar_align : "left",
mode : "exact",
elements : "articleContent"
});
</script>
Presently, within the tags of the template file...
<label for="title">{{ form.title.label }}</label>
{{ form.title|safe }}
{% if form.title.errors %}
<ul class="errors">
{% for error in form.title.errors %}
<li>{{ error }}</li>
{% endfor %}
</ul>
{% endif %}
<label for="prose">{{ form.prose.label }}</label>
{{ form.prose|safe }}
...more WTForm validation / error handling...
I suspect the problem is in the way the form is constructed / managed via WTForms. WTForms resides in my /packages/flaskext directory. Is something like the following required somewhere...?
class wtforms.fields.TextAreaField(default field arguments, choices=[], coerce=????????, option_widget=????????)
But TextAreaField is imported from (I don't know where)...and don't know if that's even the right place / thing to tweak. Is the answer in the init.py, file.py, and/or html5.py of the WTForm module?
Again, I'd be happy if just HTML tags I include in the post are rendered upon publication...but slick way to make it easy for someone who is not accustomed to HTML to likewise format their posts would be doubly appreciated. Any help pointing me in the right direction is super appreciated!
Add'l code, if needed, follows...
I have the following class in my models.py...
class PostModel(db.Model):
"""New Post Model"""
title = db.StringProperty(required = True)
prose = db.TextProperty(required = True)
when = db.DateTimeProperty(auto_now_add = True)
author = db.UserProperty(required = True)
And the following class in my forms.py...
class PostForm(wtf.Form):
title = wtf.TextField('Title: something buzz-worthy...', validators=[validators.Required()])
prose = wtf.TextAreaField('Content: something beautiful...', validators=[validators.Required()])
The issue of having your HTML be HTML-encoded is most likely an issue that happens at render time rather than at writing time. When you receive the data back and persist it in the datastore if your HTML is still HTML and not <tag> then you need to mark your rendering as safe:
{% for post in posts %}
<h2>{{ post.title | safe }}<h2>
<article>{{ post.content | safe }}</article>
{% endfor %}
Also, in WTForms, Field.Label (as in form.prose.label) actually renders a full label (no need to wrap the call to it in pre-rendered labels.)
Related
Is there a way to summon the description of post B (which is stated in its front matter) in post A?
The liquid tag {{page.description}} summons only the description of post A. Is there a way to include an url or something, thus using liquid tags across different files?
Or is there a better way to do this?
Unfortunately, front-matter variables are only accessible from within that file.
Between these triple-dashed lines, you can set predefined variables (see below for a reference) or even create custom ones of your own. These variables will then be available to you to access using Liquid tags both further down in the file and also in any layouts or includes that the page or post in question relies on.
Jekyll documentation
However, you can work around this for posts by looping through every post and including only what you want using an if statement.
{% for post in site.posts %}
{% if post.title == "Desired Post Title" %}
{{ post.description }}
{% endif %}
{% endfor %}
Say I have a form named myform with an input field named myinput. By default, symfony will generate HTML widget like:
<input name="myform[myinput]" ... >
This doesn't work with my current javascripts and I need to get the following instead:
<input name="myinput" ...>
I've searched quite a bit and found 2 ways to achieve this:
return null in getBlockPrefix() method in form type class.
create the form using FormFactoryInterface::createNamed() and pass null as name.
It seems like the first method is not recommended, since it would limit the ability to customize form rendering using prefixed blocks.
The 2nd method was recommended here and here.
However both methods will change the name of the form to null and as a result symfony will generate the form like:
<form name="" ...>
This is probably because form_div_layout.html.twig looks like:
<form name="{{ name }}" ...
Which doesn't validate as HTML5.
According to this page, "this is not a bug".
I know I can override the form_start block in the template and remove the name altogether, but it seems that the form wasn't designed to be used with null names in general (hence no check for name length in the template).
So my question is: What is the recommended and HTML5 compatible way to remove input name prefixes for symfony forms?
It was a bug in form rendering. I've submitted a pull request to symfony repo which was accepted.
Until the change is released, a temporary solution would be to add this code to your form theme:
{# fix HTML5 validation of forms with null names #}
{% block form_start %}
{% set name = name|default(block_prefixes.1) %}
{{ parent() }}
{% endblock %}
Regarding PHP, I think either option is OK.
Regarding Twig, I'd go for creating a custom form theme and, optionally, apply it to all forms on the site. I think that's the Symfony way of rendering a form according to your, specific, needs (nullable form name).
Be patient is my first question and my english is also poor ;P
Btw... im using fos for my website and all work fine, actually my problem is that i have the "pages" template made with twig and it have, at the bottom, a call to action button that slideDown an hidden div where i want to put my registration form.
I setup the hidden div and try to put inside my include:
{% block fos_user_content %}
{% include "FOSUserBundle:Registration:register_content.html.twig" %}
{% endblock fos_user_content %}
obviously it dosn't work:
Variable "form" does not exist in kernel.root_dir/Resources/JuliusUserBundle/views/Registration/register_content.html.twig at line 2
probably for some reasons related to routing or firewall or security?
anyone have a solutions, suggestions or ideas for that?
thanks and cheers!
As error said, you need to define 'form' variable in your action, or you could try to render FOSUser registration action instead of this.
For example:
{% render(controller(FOSUserBundle:Registration:register")) %}
If you need to use include then you have to pass the form variable to your included template. Optionally you can render that template also from its corresponding controller.
So for the first case you have:
{% include("FOSUserBundle:Registration:register_content.html.twig") with {'form':form} %}
Where form here is the variable you pass from your own controller. Your second choice would be to render the FOSUB template like so:
{% render(controller("FOSUserBundle:Registration:register")) %}
Apparently i found a good solution using Edge Side Includes (ESI) includes that give me also additional benefits in cache control:
<esi:include src="http://localhost:8004/login" />
Exists in the Perl world any template system with template inheritance?
Just checked in the wikipedia Comparison_of_web_template_engines (really incomplete list) - and here isn't listed any.
Inheritance = Supports the ability to inherit a layout from a parent
template, separately overriding arbitrary sections of the parent
template's content.
Mean something like python's Jinja2:
#body.html
<body>
{% block content %}
<!-- the content go here -->
{% endblock %}
</body>
#hi.html
{% extends "body.html" %}
{% block content %}
<h1>Hi!</h1>
{% endblock %}
rendering hi.html gives
<body>
<h1>Hi!</h1>
</body>
Don't looking for exact Jinja2 syntax, simply looking for any template engine from the perl world what supports inheritance. (not only plain includes - like Template::Toolkit)
Asking here because searching CPAN is a pain for words like "template inheritance" - shows thousands modules what not related to this question.
Ps: ... and it shouldn't be something like embedded perl - should be "user editable" allowing users builds own templates without compromise a whole system - therefore can't use Mason or HTML::Mason)
I'll second the suggestion for Text::Xslate. Its syntax is even quite similar to your Jinja2 examples:
In layouts/main.tx:
...
<div id="page">
: block sidebar -> { }
<div id="content">
: block header-> { <h1>Default Title</h1> }
: block content -> { }
</div>
</div>
...
In another template:
: cascade layouts::main
: override header -> {
<div id="header">
...
</div>
: }
: override content -> {
<div id="content-body">
...
</div>
: }
A colleague recently started using Text::Xslate.
Template::Jade, a port of Jade to perl.
parent.jade
doctype html
html
head
title Jade template
body.class
p#id_name
block content
child.jade
extends parent
block content
p.
This is a test.
This is a test.
This is a test.
DTL::Fast Is my Perl implementation of Django templates with inheritance and other stuff.
For rendering form errors in a twig template, you just have to use the form_errors twig macro without difference if it is a global form error or a field error.
But in my case, a global error is not rendered like a field error, so I can't use the form_errors twig macro for the two cases. I decide to use the macro for the field error & I would like to get the global form errors from the Symfony\Component\Form\FormView object. The goal is to iterate the global errors in the twig template & render them like I want.
Actually, I don't find any ressources on the symfony2 documentation which can help me.
Finally, I found the solution by myself. For the people who want to do the same thing, the solution is to call $formView->get("errors") which gives you an array of FormError
I'm using symfony 2.5 and it worked perfect for me in this way.
MyController
$error = new FormError(ErrorMessages::USER_NOT_AUTHENTICATED);
$form->addError($error);
MyView
{% for error in form.vars.errors %}
<div class="alert alert-danger" role="alert">
{{ error.messageTemplate|trans(error.messageParameters, 'validators')~'' }}
</div>
{% endfor %}
hope this will save someones time.
in symfony 2.3 all accessor methods have been removed in favor of public properties to increase performance.
$formView->get("errors");
is now:
$formView->vars["errors"];
Visit UPGRADE-2.1.md and refer to section "Deprecations" for more information.