From lasizoillo en gmail.com  Sat Dec  8 19:50:08 2018
From: lasizoillo en gmail.com (lasizoillo)
Date: Sun, 9 Dec 2018 01:50:08 +0100
Subject: [Python-es] 
 =?utf-8?q?=5BPy-MAD=5D_=C2=BFForo_integrable_en_djan?=
 =?utf-8?b?Z28/?=
In-Reply-To: <CADrijz2jtRLD0bD-JM5+OsJhAP9ndLaj+XZ2aM-U7+aU=S8Fww@mail.gmail.com>
References: <CADrijz2jtRLD0bD-JM5+OsJhAP9ndLaj+XZ2aM-U7+aU=S8Fww@mail.gmail.com>
Message-ID: <CAG=kWeec8HpW7bkw1K5r40_zP4b52EOO4f9HZ1aup16qUf8pNw@mail.gmail.com>

Buenas,

Respondo entre lineas.

DISCLAIMER: Hace años que no hago nada con django, pero creo que no va a
hacer falta para esto

El vie., 7 dic. 2018 a las 21:49, César García Tapia (<tapia en openshine.com>)
escribió:

> ¡Hola!
>
> Ando buscando un foro que pueda integrar en una aplicación ya existente en
> Django. "Integrar" en este caso significa:
>
> - Poder usar nuestro propio modelo de usuario ya existente.
>

Me resultaría muy raro uno en el que no puedas usar tu propio modelo ya
existente (tras los debidos ajustes) o incluso integrar la autenticación
con Ldap u OAUTH. Hay que ser muy cutre para hacer una aplicación que no
permita esto, otra cosa es que no esté documentado.


> - Que la sesión creada en el foro se mantenga en la aplicación y
> viceversa, sin necesidad de autenticarse por separado.
>

Supongo que el foro se ejecuta en el mismo proceso todo y les vas a dar el
mismo dominio para que compartan la cookie de autorización ¿no? Si es así
este requisito sobra, si no es así habrá que hacer un poco de "magia", pero
se puede hacer.


> - Idealmente, que si necesitamos alguna funcionalidad custom, podamos
> hacerlo con plugins, sin necesidad de forkear nuestra propia versión del
> foro.
>

¿Qué sería funcionalidad custom? No es lo mismo algo que se pueda hacer con
un par de queries en el context request que algo que afecte a los
requisitos intrínsecos de un foro. Supongo que ya habrás visto esta página
pero la pongo por si acaso:

https://djangopackages.org/grids/g/forums/

Aquí se listan algunas funcionalidades muy genéricas: pre-moderación,
post-moderación, notificaciones,... Esta lista debería ser la importante
para ayudarte para ver qué está cubierto y qué no. Normalmente las cosas
demasiado plugables acaban convirtiéndose en infiernos para la
escalabildad, casi es mejor buscar un framework que un "lo hago todo pero
nada bien".

De todas formas, si el foro está varias separado en subapps (y estas tienen
bajo acoplamiento), es posible que solo forkeando una de ellas tengas lo
que necesites minimizando el dolor.


> - Y ya si el foro fuera medianamente modernillo y no recordara a
> forocoches o a un phpBB de hace 20 años, me haríais feliz. :-)
>

Muy mal se tiene que dar la cosa para que no esté hecho con plantillas y
pueda personalizarse. Pero si, que por defecto sean bonicas es un plus ;-)


>
> Opciones que hemos medio descartado:
>
> - Misago [1] parece muy majo, tiene bastante comunidad y el desarrollo
> está activo, pero es una aplicación completamente standalone. Ni permiten
> la integración ni se lo plantean a futuro.
>

"Ni permiten la integración, ni se lo plantean a futuro", ni falta que hace
(añadiría yo). La verdad es que tras revisar el código fuente creo que la
documentación buena es el código fuente.

Versión fácil:
-------------------
Si tiene integración para registrarse con github (como puede verse en el
propio foro del proyecto) seguro que puedes cambiar el proceso de registro
para que se autentique contra tu otra aplicación y tenerlo en un plis. Eso
si, con un nivel de integración con tu aplicación bastante bajo (olvídate
de urls del tipo reverse("delaotraapp:index") si no haces un trabajo de
duplicación), pero tirando a muy sencillo de mantener.

https://misago.gitbook.io/docs/socialauth

Versión dificil:
--------------------

La integración es más cuestión de documentación que de implementación. Y la
verdad es que esa documentación, si fuese el dueño del proyecto, como mucho
la pondría en un link o un apéndice para que no echase para atrás a futuros
usuarios porque es algo tedioso.

Si miras el código fuente verás que en efecto usan su propio modelo de
usuario:
https://github.com/rafalp/Misago/blob/master/devproject/settings.py#L159

Y es normal que lo hagan porque hacen bastantes cosas con el:
https://github.com/rafalp/Misago/blob/master/misago/users/models/user.py#L133

Pero hay algo que da muy buena espina y es que no han hardcodeado el modelo
sino que parece que han tenido cuidado:
https://github.com/rafalp/Misago/blob/master/misago/users/models/user.py#L488

No conozco tu modelo, pero el objetivo para hacer la integración es adaptar
tu modelo con todas las cosas que necesita el foro y hacer la migración. No
se si usas directamente el modelo de usuario de django (te va a tocar
migrar a tu modelo propio modelo de usuario) o tienes tu propio modelo de
usuario (que va a ser más fácil porque "solo" vas a tener que añadirle lo
que necesita misago (ojo cuidado que nos complica la mantenibilidad, pero
por lo demás todo va a quedar integrado a tope).

Ojito que misago usa su propio authentication backend:
https://github.com/rafalp/Misago/blob/master/misago/users/authbackends.py#L32

No parece nada del otro mundo, pero es posible que si te calzas ese
"truqui" del select related que hace se degraden las queries al foro.
Apúntate también todos los modelos relacionados con el usuario por si te
toca crearlos en el script de migrate. Yo me apunto el truqui ese del
select-related por si me toca hacer una app django un día de estos, me ha
gustado para quitar queries innecesarias.

Y hablando de los scripts de migrate, que sepas que cuando se lancen los
scripts de migrate al dar de alta las apps de misago en tu proyecto se van
a crear las foreign keys según tengas configurado tus settings, por si
pensabas hacer una salida en oculto del foro y luego migrar el modelo de
usuario más adelante cuando estés convencido con el resultado:
https://github.com/rafalp/Misago/blob/master/misago/users/migrations/0001_initial.py#L181

Si quieres hacer salidas en oculto te recomiendo un feature flipper
(django-waffle me hizo feliz en su día):
https://djangopackages.org/grids/g/feature-flip/

También quedaría el tema de adaptar el registro de usuarios (que supongo
querrás unificar en un solo sitio). Esto sería algo que corre también de tu
cuenta personalizar. Teniendo un api como tienen seguro que puedes
integrarlo fácil en tu proceso de registro. Y sería cosa de capar esa
funcionalidad del foro.

Luego está el tema de personalizar estilos de templates (evitar el efecto
frankenweb), incluir urls, escribir los nuevos settings, ... Y todo esto
teniendo en cuenta la que se te puede liar en cada actualización porque
tienes que repasar las personalizaciones. Cuanta más integración quieras,
más dolor al actualizar. Hay cosas que parecen fáciles de integrar, como el
tema de añadir más secciones a la visualización del profile, a la edición
de profile o pestañas en el listado de usuarios (por ejemplo filtrar por
departamento). Y a pesar de eso está tan penósamente documentado que lo vi
mirando el código, es posible que haya más cosas fáciles de personalizar
que no te obliguen a hacer forks.

Pero vamos todo esto es algo que podría llevarte un par de días según
algunos, vamos a decir un par de semanas para que esté todo bien pulido
(testeos de migración, personalizar templates, empollarse bien el proyecto,
revisar que no cause problemas en tu app,...):
https://misago-project.org/t/looking-for-a-forum-solution/564/post/2725/

No he mirado los demás. Pero viendo el código de este así en un ratillo
parece bastante posible hacer lo que pides, que también es cierto que a
nivel funcional has dicho bastante poco. Gracias por poner el link, me ha
gustado mucho curiosear el código y ver como resuelve algunos temas
difíciles con bastante calidad ;-)



> - Spirit [2] tiene bastantes estrellas en github, pero apenas tiene
> documentación. No he encontrado la forma de ver si permite hacer algo de lo
> que necesitamos.
> - Django-machina [3] parece que sí permite cierto nivel de integración,
> pero la mecánica del foro es algo viejuna. A pesar de eso, parece la opción
> más viable.
>
> Por otro lado, otra opción es usar otro software, tipo Discourse, y tratar
> de integrarlo con un single sign-on o algo parecido, pero preferiría
> evitarlo. Implicaría desplegar un entorno completamente distinto, otra base
> de datos, programar extensiones en otro lenguaje y framework... No suena a
> buena idea.
>
> A ver si se os ocurre algo que podamos usar. ¡¡Muchas gracias!!
>
> César.
>
> [1] https://github.com/rafalp/misago
> [2] https://github.com/nitely/Spirit
> [3] https://github.com/ellmetha/django-machina
> _______________________________________________
> Asociación Python España: http://www.es.python.org/
> Python Madrid: http://www.python-madrid.es/
> Madrid mailing list
> Madrid en lists.es.python.org
> https://lists.es.python.org/listinfo/madrid
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20181209/e5fd6abd/attachment.html>

From tapia en openshine.com  Fri Dec  7 15:42:26 2018
From: tapia en openshine.com (=?UTF-8?B?Q8Opc2FyIEdhcmPDrWEgVGFwaWE=?=)
Date: Fri, 7 Dec 2018 21:42:26 +0100
Subject: [Python-es] =?utf-8?q?=C2=BFForo_integrable_en_django=3F?=
Message-ID: <CADrijz2jtRLD0bD-JM5+OsJhAP9ndLaj+XZ2aM-U7+aU=S8Fww@mail.gmail.com>

¡Hola!

Ando buscando un foro que pueda integrar en una aplicación ya existente en
Django. "Integrar" en este caso significa:

- Poder usar nuestro propio modelo de usuario ya existente.
- Que la sesión creada en el foro se mantenga en la aplicación y viceversa,
sin necesidad de autenticarse por separado.
- Idealmente, que si necesitamos alguna funcionalidad custom, podamos
hacerlo con plugins, sin necesidad de forkear nuestra propia versión del
foro.
- Y ya si el foro fuera medianamente modernillo y no recordara a forocoches
o a un phpBB de hace 20 años, me haríais feliz. :-)

Opciones que hemos medio descartado:

- Misago [1] parece muy majo, tiene bastante comunidad y el desarrollo está
activo, pero es una aplicación completamente standalone. Ni permiten la
integración ni se lo plantean a futuro.
- Spirit [2] tiene bastantes estrellas en github, pero apenas tiene
documentación. No he encontrado la forma de ver si permite hacer algo de lo
que necesitamos.
- Django-machina [3] parece que sí permite cierto nivel de integración,
pero la mecánica del foro es algo viejuna. A pesar de eso, parece la opción
más viable.

Por otro lado, otra opción es usar otro software, tipo Discourse, y tratar
de integrarlo con un single sign-on o algo parecido, pero preferiría
evitarlo. Implicaría desplegar un entorno completamente distinto, otra base
de datos, programar extensiones en otro lenguaje y framework... No suena a
buena idea.

A ver si se os ocurre algo que podamos usar. ¡¡Muchas gracias!!

César.

[1] https://github.com/rafalp/misago
[2] https://github.com/nitely/Spirit
[3] https://github.com/ellmetha/django-machina
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20181207/b1f448aa/attachment.html>

From tapia en openshine.com  Sun Dec  9 19:02:59 2018
From: tapia en openshine.com (=?UTF-8?B?Q8Opc2FyIEdhcmPDrWEgVGFwaWE=?=)
Date: Mon, 10 Dec 2018 01:02:59 +0100
Subject: [Python-es] 
	=?utf-8?q?=5BPy-MAD=5D_=C2=BFForo_integrable_en_djan?=
	=?utf-8?b?Z28/?=
In-Reply-To: <CAG=kWeec8HpW7bkw1K5r40_zP4b52EOO4f9HZ1aup16qUf8pNw@mail.gmail.com>
References: <CADrijz2jtRLD0bD-JM5+OsJhAP9ndLaj+XZ2aM-U7+aU=S8Fww@mail.gmail.com>
 <CAG=kWeec8HpW7bkw1K5r40_zP4b52EOO4f9HZ1aup16qUf8pNw@mail.gmail.com>
Message-ID: <CADrijz3XcKq69ePirMHnjrXUMUfKY0sb2H4a_dDORh=QX9ea7Q@mail.gmail.com>

El dom., 9 dic. 2018 a las 1:50, lasizoillo (<lasizoillo en gmail.com>)
escribió:

> Buenas,
>
> Respondo entre lineas.
>

Ídem.


> ¿Qué sería funcionalidad custom? No es lo mismo algo que se pueda hacer
> con un par de queries en el context request que algo que afecte a los
> requisitos intrínsecos de un foro.
>


Me refiero a cosas como autogenerar enlaces al perfil de un usuario al
escribir "@usuario" (y el perfil sería el que ya existe en nuestra
aplicación, no el propio que genere el foro), o permitir incrustar
"tarjetas" cuando se incluyan enlaces a otras partes de la aplicación (algo
parecido a lo que hacen twitter o slack cuando envías una URL de un
periódico, por ejemplo). Ese tipo de cosas. Es decir, integrar el foro con
nuestra aplicación, y que no sea simplemente un apéndice aislado.


Luego está el tema de personalizar estilos de templates (evitar el efecto
> frankenweb), incluir urls, escribir los nuevos settings, ... Y todo esto
> teniendo en cuenta la que se te puede liar en cada actualización porque
> tienes que repasar las personalizaciones. Cuanta más integración quieras,
> más dolor al actualizar. Hay cosas que parecen fáciles de integrar, como el
> tema de añadir más secciones a la visualización del profile, a la edición
> de profile o pestañas en el listado de usuarios (por ejemplo filtrar por
> departamento). Y a pesar de eso está tan penósamente documentado que lo vi
> mirando el código, es posible que haya más cosas fáciles de personalizar
> que no te obliguen a hacer forks.
>


Claro, a este tipo de cosas me refiero. Nos hace falta que la
personalización sea algo más elaborado que simplemente compartir
autenticación y customizar plantillas. Necesitamos acceder a urls de otras
partes de la aplicación (el reverse() que mencionas), ampliar las
funcionalidades del foro, compartir permisos de moderación (tenemos sistema
de comentarios en otras partes del sistema), etc.

Al final, basándome en la experiencia, me veo que la integración va a ser
tan ad-hoc y tan acoplada a la implementación de una versión concreta de
Misago que a la larga lo más probable es que acabemos o bien forkeando, o
bien congelando la versión que usemos, simplemente para que la cosa sea
mínimamente mantenible (porque dudo mucho que una aplicación de este estilo
se ande con muchas delicadezas a la hora de mantener la compatibilidad
hacia atrás, y menos aún con los APIs internos a los que tendríamos que
acceder).

Basándome en lo que he estado mirando yo, y lo que me comentas tú, creo que
nos va a resultar más viable refactorizar y ampliar la funcionalidad de
comentarios que ya tenemos y construir el sistema de foros alrededor. No me
convence mucho, porque probablemente nos cueste bastante más tiempo, pero
me quedaré más tranquilo de cara a que podamos incluir exactamente la
funcionalidad que nos haga falta, y que dentro de dos años no nos veamos
con una deuda técnica gigante.

¡¡Muchísimas gracias por tu respuesta tan exhaustiva!!

César.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20181210/96e23931/attachment.html>

From lasizoillo en gmail.com  Mon Dec 10 12:08:56 2018
From: lasizoillo en gmail.com (lasizoillo)
Date: Mon, 10 Dec 2018 18:08:56 +0100
Subject: [Python-es] 
	=?utf-8?q?=5BPy-MAD=5D_=C2=BFForo_integrable_en_djan?=
	=?utf-8?b?Z28/?=
In-Reply-To: <CADrijz3XcKq69ePirMHnjrXUMUfKY0sb2H4a_dDORh=QX9ea7Q@mail.gmail.com>
References: <CADrijz2jtRLD0bD-JM5+OsJhAP9ndLaj+XZ2aM-U7+aU=S8Fww@mail.gmail.com>
 <CAG=kWeec8HpW7bkw1K5r40_zP4b52EOO4f9HZ1aup16qUf8pNw@mail.gmail.com>
 <CADrijz3XcKq69ePirMHnjrXUMUfKY0sb2H4a_dDORh=QX9ea7Q@mail.gmail.com>
Message-ID: <CAG=kWefucUw25Qtb1Uq5tXV6NYx_jsebn+4rw2KOcrpwJO=ukQ@mail.gmail.com>

El lun., 10 dic. 2018 a las 1:03, César García Tapia (<tapia en openshine.com>)
escribió:

>
>
> Basándome en lo que he estado mirando yo, y lo que me comentas tú, creo
> que nos va a resultar más viable refactorizar y ampliar la funcionalidad de
> comentarios que ya tenemos y construir el sistema de foros alrededor. No me
> convence mucho, porque probablemente nos cueste bastante más tiempo, pero
> me quedaré más tranquilo de cara a que podamos incluir exactamente la
> funcionalidad que nos haga falta, y que dentro de dos años no nos veamos
> con una deuda técnica gigante.
>
>
Ya tienes un sistema de comentarios así que asumo que:
- Ya teneis una interfaz de usuario para generar mensajes. Y llamo interfaz
de usuario a cualquier cosa entre un espartano textarea hasta un
complicadisimo sistema transpilando el word a webassembly
- Ya tienes un formato en el que guardar los mensajes (html, markdown,
texto plano, ...)

El tiempo que te costaría encontrar y customizar algo que permita integrar
vuestra UI y vuestro formato en un foro va a ser mayor que si lo hacéis
vosotros. Así que no te de miedo liarte la manta a la cabeza, es buena
decisión a largo y a corto plazo. Lo mismo te digo con los otros casos de
uso que comentas que necesitáis o que ya tendréis resueltas (sistema de
notificaciones, filtros anti-spam, sistema de moderación,...).

Tampoco consideraría tiempo perdido el dedicado a analizar herramientas
open-source que poder usar. Es una maravilla cuando directamente puedes
usar una herramienta open-source y te ahorras el curro de desarrollo, pero
también es provechoso cuando analizas 4 o 5 soluciones y te ahorras tiempo
pensando el funcional o inspirando algunas decisiones técnicas.

Y ahora te hago yo una pregunta técnica que siempre me surge con este tipo
de cosas: ¿Usais GenericForeignKeys para unir los hilos de comentarios a
vuestras diferentes entidades (artículo, pagina, receta de cocina, lo que
sea) o huis de ellos como de la peste? Siempre me pasa que por un lado me
parece un diseño elegante y desacoplado, pero por otro que las relaciones
n:m que se generan acaban haciendo de mi vida una pesadilla. ¿Cómo lo
resolvéis vosotros?

Un saludo,

Javi
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20181210/2eb7215e/attachment.html>

From tapia en openshine.com  Mon Dec 10 13:37:53 2018
From: tapia en openshine.com (=?UTF-8?B?Q8Opc2FyIEdhcmPDrWEgVGFwaWE=?=)
Date: Mon, 10 Dec 2018 19:37:53 +0100
Subject: [Python-es] 
	=?utf-8?q?=5BPy-MAD=5D_=C2=BFForo_integrable_en_djan?=
	=?utf-8?b?Z28/?=
In-Reply-To: <CAG=kWefucUw25Qtb1Uq5tXV6NYx_jsebn+4rw2KOcrpwJO=ukQ@mail.gmail.com>
References: <CADrijz2jtRLD0bD-JM5+OsJhAP9ndLaj+XZ2aM-U7+aU=S8Fww@mail.gmail.com>
 <CAG=kWeec8HpW7bkw1K5r40_zP4b52EOO4f9HZ1aup16qUf8pNw@mail.gmail.com>
 <CADrijz3XcKq69ePirMHnjrXUMUfKY0sb2H4a_dDORh=QX9ea7Q@mail.gmail.com>
 <CAG=kWefucUw25Qtb1Uq5tXV6NYx_jsebn+4rw2KOcrpwJO=ukQ@mail.gmail.com>
Message-ID: <CADrijz26i75jLoxGcN=PcBugNCd+Miw3=UXCjFPz10p80tVk=g@mail.gmail.com>

El lun., 10 dic. 2018 a las 18:09, lasizoillo (<lasizoillo en gmail.com>)
escribió:

>
>
> Y ahora te hago yo una pregunta técnica que siempre me surge con este tipo
> de cosas: ¿Usais GenericForeignKeys para unir los hilos de comentarios a
> vuestras diferentes entidades (artículo, pagina, receta de cocina, lo que
> sea) o huis de ellos como de la peste? Siempre me pasa que por un lado me
> parece un diseño elegante y desacoplado, pero por otro que las relaciones
> n:m que se generan acaban haciendo de mi vida una pesadilla. ¿Cómo lo
> resolvéis vosotros?
>


No como la peste, pero sí que intento evitarlos siempre que puedo, a no ser
que la variedad de entidades a enlazar sea muy muy alta (que queramos
permitir poner comentarios asociados a 20 modelos distintos), o que haya
que hacer queries transversales a todas las entidades (por ejemplo: "dime
el usuario que ha hecho más comentarios en toda la aplicación, me da igual
dónde"). En esos casos sí pueden tener sentido.

Los GenericForeignKeys tienen varios problemas, en mi opinión:

- Hay que conocerlos bien para entender lo que están haciendo, con lo que
la legibilidad y mantenibilidad del código se resiente. Si has visto código
que los use, no siempre es obvio lo que está haciendo. Si lo único que es
tener comentarios en un par de sitios, creo que no merece la pena.
- El problema más gordo de todos: el esquema de base de datos que generan
es muy, muy, muy problemático. Ten en cuenta que no son foreign keys de
verdad, sino únicamente una convención definida por Django, por lo que la
integridad referencial en la base de datos se va a tomar vientos.

La mayoría de las veces, se puede tener funcionalidad parecida simplemente
usando herencia de modelos. Por ejemplo, te creas un modelo
"CommentableModel", y todo lo que pueda admitir comentarios heredaría de
él. Luego el modelo del comentario sería algo tipo:

class Comment(models.Model):
    ...unos cuantos campos...
    parent = models.ForeignKey(CommentableModel, on_delete=models.CASCADE)

O, más fácil aún, creas modelos intermedios para cada modelo "Comentable".
Esto no es muy DRY, pero si el número de modelos comentables es pequeño, al
final acaba siendo lo más fácil de leer, entender y mantener.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20181210/71ee9763/attachment.html>