Showing posts with label textarea. Show all posts
Showing posts with label textarea. Show all posts

Wednesday, March 28, 2012

Atlas, Firefox, and TinyMCE

I can't get TinyMCE to work with Firefox and Atlas.

Any changes made to the TextArea that tinyMCE is attached to are lost on postback. However, IE is fine, and removing the <atlas:ScriptManager> tag fixes it in Firefox too.

The following simple page fails:

<%@dotnet.itags.org. Page Language="C#" AutoEventWireup="true" ValidateRequest="false" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>Untitled Page</title>
<script language="javascript" type="text/javascript" src="tinymce/jscripts/tiny_mce/tiny_mce.js"></script>
<script language="javascript" type="text/javascript">tinyMCE.init({mode : "textareas"});</script>
</head>
<body>
<form id="form1" runat="server">
<atlas:ScriptManager ID="ScriptManager1" runat="server" />
<asp:TextBox id="tb" runat="server" Rows="10" TextMode="multiLine" Text="Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua."></asp:TextBox>
<br />
<asp:Button ID="saveBtn" runat="server" Text="Postback" />
</form>
</body>
</html>
Has anyone successfully used tinyMCE and Firefox with Atlas enabled? Having said that, this 'Write a New Post' form looks very much like TinyMCE, and I'm using Firefox!?!
Any ideas?

Are people using other rich text editors successfully with Atlas?

Freetextbox?

FckEditor?


I've run into the same problem. Have you been able to figure this out? If so, what was your solution?

Thanks,
kevin


I had the same problem and solved it as follows:

- remove the ValidateRequest=false directive to avoid possible security issues

- add encoding : "xml"to the tinyMCE.Init code. This translates the HTML-code to XML and by doing this the secuity message won't appear.

- when filling the tinyMCE control with text, use TinyMCE.Text = Server.HtmlDecode(value); to translate it back into HTML

This worked out fine for me. I use the TinyMCE in a user control. The HTLM-translation is implemented in the Text property of the control.

Hopefully this helps.

Wednesday, March 21, 2012

ATLAS Prototyping Gone Awry?

Hello,

The company I work for has spent some considerable time developing a WYSIWYG/TextArea custom hybrid editor for our forums and websites. Within the javascript file for this editor we have the following line...

var btn = toolbarArray[btnGroup][btnItem].toLowerCase();

This works all well and good, that is, until I include the ATLAS xml block on the control...

 <atlas:ScriptManager runat="server" id="scriptManager"> <services> <atlas:servicereference path="~/Services/EmailService.asmx" /> </services> </atlas:ScriptManager>
Now, the once simple var[array][array] is tranformed into something compeltely different.
It now becomes var[array](function). The following is a copy/paste from an alert window displaying the function contents...
--------
Microsoft Internet Explorer
--------
function(index) {
    return this[index];
}
--------
OK
--------
Now why on earth is ATLAS going around prototyping stuff it has no business messing with? This is basically killing our ability to use our editor on any ATLAS enabled page.
 

hello.

hum...not sure if i follow you...are you saying that atlas changes the meaning of predefined methods? could you give more info on that problem?


There's not much more info to give. If you have an understanding of javascript's syntax the issue is pretty easy to follow.

Before the ATLAS xml block is used this is valid...

var btn = toolbarArray[btnGroup][btnItem].toLowerCase();

After the ATLAS xml block is used the above becomes invalid and the following becomes valid...

var btn = toolbarArray[btnGroup](btnItem).toLowerCase();

The difference is pretty significant, and we've spent a large amount of time narrowing the issue down to the fact that in the normal case, ATLAS is not used. Once ATLAS has been added to a page, it appears to prototype our standard var[array][arrayindex] to var[array](arrayindex). It basically changes a standard getItem on an array object to a function (which I pasted in my first post).

This is hugely irresponsible and is breaking a large amount of our code.


hello again.

well, i have basic javascript knowledge, but i think i will be able to follow if you're able to give a concrete example of this problem (ie, can you build some sort of sample and past it here so that i can understand what's going on?). to my knowledge, the array object has been augmented with new methods and none of the previous ones has been changed. the team has also extended the function object extensivelly to improve oo programming in javascript.


var toolbar = [['1'], ['2'], ['3', '4']];

for(var item in toolbar)
{
var thing = toolbar[item][0];
}

Run it without ATLAS and thing will return '1'

Run it with ATLAS and thing will return that function definition I pasted in the first post.

This has been confirmed for Opera 9, Firefox 1.5.0.4 and IE 6 XPSP2


hello again.

ah, oki...you've got a point. Expanding the array object introduces several metods to its prototype property (which i think is empty by default). that's why you'd get the expected results when you used that syntax when you didn't add atlas to your app. btw, there's a quick fix for this: use the traditional for approach or use the new forEach method that's appended to the array class.


Great, I'm glad I'm not the only one seeing this. Was thinking that my mind took a vacation.

You are correct, you can fix this by taking the traditional for(var i = 0; i < x; i++){} route. However, the ATLAS team is breakingEXPECTED functionality. That's where the problem lies. I've searched the documentation and can find no mention of this. It should definately be rectified, and at the very least, well documented.

I'm hoping that this post helps out some other developers in the future, and that the team takes a look at this post and makes a note of it. Thanks for your participation.


hello.

well, in my opinion, the documentation on msdn (jscript center) is wrong because i think it shoud only say that it returns each property of an object instead of giving the impression that this is different with arrays (which, in my opinion, is not correct)...


I would agree with you if not for the fact that this is standard behavior in every js engine/implementation I have been able to find.

hello again.

well, yes, i understand what you mean...what i'm trying to say is that the way the arry behavior is a side effect of the way it's defined...for instance, if i'm not mistaked, the javascript says something like this about the for...in statement:

The

for...instatement iterates a specified variable over all the properties of

an object. For each distinct property, JavaScript executes the specified statements

in the

block.

ForInStatement:

for (Identifier in ObjectReference) Block

ObjectReference

is an identifier that is the object for which the properties are

iterated.

though i might be wrong, to me it looks like this syntax should only be used to iterate over all the properties of an object (that's why i say that the array default behavior can be seen as a side effect of the way it's used).