Editor WYSIWYG - Commenti incorporati

1

Sto lavorando su un sito cms guidato dall'utente. Pensalo come un eccesso di stack. Gli utenti possono scrivere post e pubblicarli sul web. Sto usando un editor WSGI per generare il contenuto.

Una delle funzionalità che sto implementando è la possibilità per gli utenti di commentare una particolare sezione di un post dell'utente. Sto cercando di pensare a un modo pulito per implementare questa funzione.

Il mio piano attuale è quello di personalizzare l'editor WYSIWYG per generare un id univoco per <p> e quindi archiviare i commenti separatamente, e quando la pagina viene caricata legge anche i commenti e fa un po 'di magia jquery. Tutti gli utenti che genereranno contenuti saranno utenti admin, quindi non ho paura di qualcuno che si occupa di id.

Questo è un approccio che ho trovato, ma speravo di ottenere qualche feedback o modi alternativi per realizzare ciò di cui ho bisogno. Un'altra cosa che sto cercando di capire è come posso gestire un utente che modifica un post che è stato commentato ...

    
posta Nix 25.02.2013 - 16:23
fonte

3 risposte

1

Non lasciare che il browser esegua qualcosa che abbia rilevanza per il database (come la generazione di ID). Pessima idea Le persone lo useranno per inviare i dati del cestino solo per vedere cosa succede.

Lascialo inviare il testo, quindi diviso in elementi, preferibilmente per terminazioni di riga, potresti ottenere o meno quei tag <p> . Quindi lascia che il controller generi gli ID per loro.

Ma tutto sommato sembra complicato e vorrei solo fare ciò che la maggior parte degli altri forum fa in citazioni di situazioni simili all'interno del testo di risposta:

This is one approach I have found, but I was hoping to either get some feedback or alternative ways to accomplish <Nix>

Forse aggiungi il nome dell'utente citato. Forse un link "genitore" che mostra il testo originale (simile a Reddit).

    
risposta data 25.02.2013 - 16:51
fonte
1

Penso che il tuo concetto di avere ID univoci per paragrafo, con i commenti memorizzati separatamente, sia piuttosto solido. Ma, come dici tu, sei bloccato con i problemi degli utenti che modificano i loro post.

Se hai la cronologia delle revisioni dei post forse i commenti potrebbero rimanere con una particolare revisione.

Potresti usare uno strumento diff o un calcolo della distanza di Levenshtein per aiutarti a decidere cosa succede con un commento. Devi ancora rispondere alle domande: il commento dovrebbe rimanere se un paragrafo è stato modificato? Il commento dovrebbe essere cancellato se il paragrafo è cancellato? ecc. Ma avere il lavoro svolto da uno strumento diff, ad esempio, può semplificare le cose perché dovrebbe essere in grado di dirti semplicemente se una riga viene aggiunta, cancellata o modificata.

Semplificando, se non sai cosa è successo a un testo modificato, elimina i commenti o convertili da un commento su un paragrafo specifico a un commento sull'intero post (se possibile).

    
risposta data 25.02.2013 - 22:20
fonte
0

Questo algoritmo che consiglio dipende dal mantenimento del modello di dati per le operazioni nel database e dall'utilizzo di quel modello per generare le interfacce e i collegamenti nella modalità lettura del documento, piuttosto che consentire l'accesso diretto modifica del documento principale. Un approccio basato sul collegamento nella vista renderizzata (non in modifica) consente a qualcuno di partecipare al flusso di lavoro dei commenti senza consentire loro di modificare direttamente il documento principale; puoi semplicemente utilizzare le aree di testo oi campi di inserimento nel popover o un nuovo modulo basato su pagine per queste interazioni. Ho utilizzato questo approccio per le revisioni a livello di dipartimento.

Fare clic su un paragrafo potrebbe non essere un comportamento ovvio per i nuovi utenti. Quando si genera l'id per un componente degno di commenti (che si tratti di paragrafi, voci di elenco, blockquote o simili), considerare l'aggiunta di un collegamento in apice alla fine con un'etichetta o un'icona chiara che invita a fare clic per l'interazione. Quindi, fai clic su una finestra con il modulo o apri una nuova pagina (in base alle preferenze di accessibilità) per accettare quell'input, adattato all'ID generato. Dovrai indicizzare quel commento memorizzato dall'ID documento e dall'ID componente corrispondente.

Per il rendering dei commenti, quando un componente ha un nuovo commento, puoi aggiungere un nuovo link "vedi commenti" seguendo il link originale "commenta qui"; di nuovo, questo collegamento aggiunto può far apparire una finestra con la finestra di dialogo (dato che potrebbe essere uno o più contributori) con chiave per quel componente, o collegare a commenti in stile endnote visualizzati convenzionalmente sotto il documento. Credito extra per l'aggiunta di controlli di disposizione all'interno del gruppo di commenti di ciascun componente che tiene traccia di come hai utilizzato o respinto i suggerimenti!

Come fai a mantenere tutto questo interfacciamento di revisione separato dal contenuto del documento pulito stesso? Per i sorgenti HTML, manterrei solo l'attributo id / name sui componenti stessi e aggiungo i link di revisione in fase di visualizzazione basandoci su come camminare nell'albero dei documenti e applicare i collegamenti nel DOM prima della rappresentazione. Di solito ho un sorgente basato su XML, quindi uso un modello XSLT per riconoscere questi nodi e aggiungere il markup durante la conversione nell'albero dei risultati HTML. In entrambi i casi, la tua fonte originale rimane priva del markup di commenti / recensioni eccetto quando è in una vista in cui intendi consentire la creazione di commenti. Puoi disattivare questo passaggio aggiunto quando la revisione è terminata o quando il commento è chiuso.

    
risposta data 25.02.2013 - 20:14
fonte

Leggi altre domande sui tag