[Building Sakai] Melete Problem
Noah Botimer
botimer at umich.edu
Wed Dec 11 07:54:19 PST 2013
We've historically had to be careful about the defaults on this. What happens is that content created previous gets handled differently (surprisingly, to the user) if the setting changes. They end up with a mix of p's and br's, and have trouble.
Basically, I think we should have always been using p tags. The issue with this is that many users want simple line breaks, not paragraph breaks, and we have not done a great job with tech literacy on the topic of writing on the web. Both line and paragraph breaks have always been available -- shift-enter does a line break when paragraphs are active, for example. But we have used br's for so long to meet that desire that p's seem wrong to many and there is a big mixed-mode legacy to deal with.
I'm just saying -- let's be careful about changing the default because it's wrong 50% of the time either way.
Thanks,
-Noah
On Dec 11, 2013, at 9:55 AM, Matthew Jones wrote:
> No, you'd have to put that in ckeditor.launch.js right now and then clear your cache afterward.
>
> In a deployed instance that would be in (library.war)
> ${TOMCAT_HOME}}/webapps/library/editor/ckeditor.launch.js
>
> In source it's in
> reference/trunk/library/src/webapp/editor/ckeditor/ckeditor.launch.js
>
> You'd need to add autoParagraph to the ckconfig setting so before the CKEDITOR.replace line, add it in
>
> + ckconfig.autoParagraph = false;
> CKEDITOR.replace(targetId, ckconfig);
>
> Which would put it up into the ckconfig variable. We've wanted to make this easier to configure (via properties or something) just nobody has done it yet. If this works this seems like it should be the default though.
>
>
>
> On Wed, Dec 11, 2013 at 1:26 AM, Coetzee, Nico <Coetzeen at unisa.ac.za> wrote:
> This message (and attachments) is subject to restrictions and a disclaimer. Please refer to http://www.unisa.ac.za/disclaimer for full details.
>
> Hi Mallika
>
>
>
> Thanks for the reply, I only saw the thread after I posted, sorry. Do you perhaps know where to put the autoParagraph=false setting, must this be in sakai.properties or somewhere else?
>
>
>
> Regards
>
> Nico
>
>
>
>
>
> From: sakai-dev-bounces at collab.sakaiproject.org [mailto:sakai-dev-bounces at collab.sakaiproject.org] On Behalf Of Mallika M Thoppay
> Sent: 10 December 2013 07:25 PM
> To: sakai-dev at collab.sakaiproject.org; dev at etudes.org
> Subject: Re: [Building Sakai] Melete Problem
>
>
>
> Nico,
>
> If you followed the thread that was reported for this issue, supposedly autoParagraph: false fixed it for someone. You can try that.
>
> Thanks,
> Mallika
> Melete Team
>
> On 12/9/2013 10:57 PM, Coetzee, Nico wrote:
>
> This message (and attachments) is subject to restrictions and a disclaimer. Please refer to http://www.unisa.ac.za/disclaimer for full details.
>
>
>
> Dear All,
>
>
>
> We are using Sakai 2.9.1, Melete 2.9.1 and the CK Editor that comes with Sakai 2.9.1.
>
>
>
> When using the CK Editor to enter “Textual” content, after clicking Save the editor adds an extra line at the beginning of the document. In fact it adds the following html code <p><br /> </p>.
>
>
>
> The same html code is added every time a SAVE or DONE button is pressed. This only happens on Melete and not any other sakai tools.
>
>
>
> I initially thought that it relates to the CK Editor options – in particular the following
>
> breakBeforeOpen : true,
>
> breakAfterOpen : false,
>
> breakBeforeClose : false,
>
> breakAfterClose : true
>
>
>
> After toggling the above CK Editor ptions, I am still having the same problem.
>
>
>
> Is the a place in melete that sets the behaviour of the CK Editor?
>
>
>
> The closest I could get to a solution is this problem: http://collab.sakaiproject.org/pipermail/sakai-dev/2009-May/001330.html
>
>
>
> “Melete uses sakai:inputRichText tag to render FCK editor while most of
>
> the other sakai tools use sakai:richTextArea tag. When we were working
>
> on this issue it was recommended to use sakai:inputRichText tag and the
>
> other tag was being deprecated but it never did and is actually a better
>
> tag.”
>
>
>
> Could the sakai:inputRichText be responsible for this odd behaviour?
>
>
>
> Has anyone ever seen this before and what was the solution to it?
>
>
>
> Regards
>
>
>
> Nico Coetzee
>
>
>
>
>
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
>
>
>
> --
> Mallika M Thoppay
> Learning Systems Developer
> Etudes Inc
> http://etudes.org
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20131211/ef443ea9/attachment.html
More information about the sakai-dev
mailing list