#pyramid

[pyramid] stevepiercy pushed 3 new commits to style-guide: https://git.io/v1qU8

pyramid/style-guide b99ada6 Steve Piercy: restore Typographical Conventions, an edited and condensed version of the Style Guide

pyramid/style-guide fa84255 Steve Piercy: fix warning about duplicate name

pyramid/style-guide 351a741 Steve Piercy: Merge pull request #2843 from stevepiercy/style-guide...

there’s a new celery, but i’m going to consider using an alternative scheduling queue because the overhead of celery has always been a pita. anyone have thoughts on apscheduler?

Pylons/pyramid#4462 (style-guide - 351a741 : Steve Piercy): The build passed.

Change view : https://github.com/Pylons/pyramid/compare/08a02...

Build details : https://travis-ci.org/Pylons/pyramid/builds/179...

how would you configure a view which should render a Chameleon template, but the template depends of the X-Template header?

would you use a wrapper ? a decorator ? a view predicate ?

or even a custom renderer ?

I'd like to do the following logic: if request content-type is "application/json" then use the json rendered, else if requested content-type is "text/html" then if there is a x-template header then render this template else template:context.entity.content_type.name and render the $template/show.pt template :)

are you sure you don't want a different set of urls for the json stuff

rweir: no, I plan to use this with a REST interface

I have something like this ATM https://gist.github.com/silenius/fbac1b2fd3f328...

ok but are you sure you don't want a different set of urls for the json stuff?

this idea is to use inheritance with SQLAlchemy (one resource per entity), and use some "defaults"

rest has anothing to do with that, nor pyramid, it's just about sanity

like /foo.html and /foo.json ?

literally anything that makes it clear one is an api

maybe I could, but I'd like to support /foo too with the accept header

that would be odd

why? :)

e.g. making it annoying to guess what a url does and making curl tedious to use is probably worth avoiding

in my point of view it's "cleaner" to always access the same resource "foo" through /resource/foo and choose the response format based on the preference in the accept header

but I may be wrong

any recommendations for modern wsiwyg editors? quill, prosemirror, trix?

TinyMCE ?

mage_: bad licenses

that stuff requires commercial licenses

Ergo you just named 3 I'm not aware of... :P

i know about ckeditor etc. but im looking into something that works with a graph instead some sphagetti dom stuff

blaflamme: im doing some research and it turns out that world has changed a lot since last time i needed something like that

looks interesting

same for me, last time I used ckeditor

and the one in kendoui (commercial)

ckeditor requires commecial licenses

at least for anything saas

at first quill looks cool

is there a built-in "file-like" browser ?

blaflamme: prosemirror is interesting - it can output markdown if needed

mage_: all of those solutions require you to extend them afaik

but they seem powerful

like you can put in custom blocks like tweets or whatever

last I've came across is draft https://facebook.github.io/draft-js/

but a react thing

blaflamme: yeah that looks good but react only

i think it also operates same way as the others mentioned above

at first quill seems interesting

choosing a WYSIWYG editor is almost as hard as choosing a react ui library nowadays :(

yeah... react is slowly becoming a mess...

mage_: i decided on polymer instead

its awesome

mage_ js.coach is a good place to find some good stuff

YT is getting rewritten in it

vue.js also looks interesting

I'm now looking at aurelia

yep vue.js looks good

thanks for the js.coach link

mage_: ive migrated some parts of rhodecode to polymer

we've been very happy with the results

mage_: https://www.polymer-project.org/1.0/ - worth looking at

it's difficult to choose one

use multiple

mage_: my decision was driven by #usetheplatform - i try to use what is implemented inside browsers themselves :-)

besides only pure webcomponent solutions are interoperable with legacy codebases

that has a value too

we manipulated webcomponents with jquery

blaflamme: honnestly I'm a bit tired to learn a new js framework every year :(

mage_: thats why its best to use something that lives in browsers - you learn browser APIS

they dont go away/change often

you learned css and html once

same here

mage_ problem is even if you choose one, within a year you have to learn new stuff inside it

its just DOM model

in-browser DBs are a fine example for the context

in "the past" I used to just return html from my backend with and use addEventListener based on data- attributes

mage_: you can still do that :-)

no one forces you to adopt new tech

of course :)

as someone who hasn't hung himself yet with frontend development, vue.js seems more intuitive than react.. more, pythonic?

in fact I'm in the process of converting our main cherrypy app to pyramid, and I wanted to use React too

react has really established the most critical mass / community around itself .. and frontend developers are fatigued by the constant change in landscape so maybe react will be around for a while

anyway, web components are the futur I guess, and polymer looks interresting on this side

but if the Alibabas of China are organizing around vue.js , they may quickly develop its ecosystem

does polymer works on Internet Explorer ?

probably with polyfills

mage_ https://www.polymer-project.org/1.0/docs/browsers

mage_: yes - even with IE9 (on some stuff we tested)

but it can break any moment - normally ie10+ is supported

I can also vouch for vue.js. It's learning curve is lower than the other frameworks. Seems to have a passionate following.

mage_: btw - parts of chrome - the browser are built in polymer

download page, settings, dev tools

what are the reasons to *not* choose polymer?

mage_: less hype ;-) polyfills

That makes sense, Chrome is eating Goggle's food, since polymer is a Google framework