I am writing a cms (on .net) and have structured the whole page to work client side.
There is a treeview that lets you add/remove/move items and define their names in the languages defined. For each language I save the names of the category defined, but when there is HTML content associated with it, i fall into the JavaScript serializer problem that finds the content too long to be serialized.
What would be the best approach to make sth like this work. Shall I change everything to work with postbacks, or try to manually call _doPostBack for the editor content (which I don't want). Thank you in advance.
I guess would be great to make auto-save with time interval which will submit only diffs between current state and previous save. It will do the key if the user will edit it manually, not for copy/paste, of course. It is if we talk about really big data that we need to save.
Otherwise need to find some ways to compress the data before submitting: json+base64, etc.
Related
I am reluctant to post this, but I am having trouble understanding how markdown actually "saves" to a database.
When I'm creating a migration, I will add columns and specify the type of value (i.e. integer, text, string, etc.) and in the course of operation on the website, users will input different information that is then saved in the DB. No problem there.
I just can't seem to wrap my head around the process for markdown. I've read about saving the HTML or saving the markdown file, rendering at runtime, pros and cons all that.
So, say I use an editor like Tiny MCE which attaches itself to a textarea. When I click "Submit" on the form, how does that operate? How does validation work? Feel free to answer my question directly or offer some resource to help further my understanding. I have an app built on Laravel so I'm guessing I'll need to use a package like https://github.com/GrahamCampbell/Laravel-Markdown along with an editor (i.e. Tiny MCE).
Thanks!
Let's start with a more basic example: StackOverflow. When you are writing/editing a question or answer, you are typing Markdown text into a textarea field. And below that textarea is a preview, which displays the Markdown text converted to HTML.
The way this works (simplified a little) is that StackOverflow uses a JavaScript library to parse the Markdown into HTML. This parsing happens entirely client side (in the browser) and nothing is sent to the server. With each key press in the textarea the preview is updated quickly because there is no back-and-forth with the server.
However, when you submit your question/answer, the HTML in the preview is discarded and the Markdown text from the textarea is forwarded to the StackOverflow server where is is saved to the database. At some point the server also converts the Markdown to HTML so that when another user comes alone and requests to view that question/answer, the document is sent to the user as HTML by the server. I say "at some point" because this is where you have to decide when the conversion happens. You have two options:
If the server converts the HTML when is saves it to the Database, then it will save to two columns, one for the Markdown and one of for the HTML. Later, when a user requests to view the document, the HTML document will be retrieved from the database and returned to the user. However, if a user requests to edit the document, then the Markdown document will be retrieved from the database and returned to the user so that she can edit it.
If the server only stores the Markdown text to the database, then when a user requests to view the document, the Markdown document will be retrieved from the database, converted to HTML and then returned to the user. However, if a user requests to edit the document, then the Markdown document will be retrieved from the database and returned to the user (skipping the conversion step) so that she can edit it.
Note that in either option, the server is doing the conversion to HTML. The only time the conversion happens client-side (in the browser) is for preview. But the "preview" conversion is not used to display the document outside of edit mode or to store the document in the database.
The only difference between something like StackOverflow and TinyMCE is that in TinyMCE the preview is also the editor. Behind the scenes the same process is still happening and when you submit, it is the Markdown which is sent to the server. The HTML used for preview is still discarded.
The primary concern when implementing such a system is that if the Markdown implementation used for preview is dissimilar from the implementation used by the server, the preview may not be very accurate. Therefore, it is generally best to choose two implementations that are very similar or, if available, use the same implementations for both.
It is actually very simple.
Historally, in forums, there used be BBCodes, which are basically pseudo-tags that allow you to format your text in some say. For example [b][/b] used to mean "make this text bold". In Markdown, it happens the exact same thing, but with other characters like *text* or **text**.
This happens so that you only allow your users to use a specific formatting, otherwise if you'd allow to write pure HTML, XSS (cross-site scripting) issues would arise and it's not really a good idea.
You should then save the HTML on the database. You can use, for example, markdown-js which is a Markdown parser that parses Markdown to HTML.
I have seen TinyMCE does not make use of Markdown by default, since it's simple a WYSIWYG editor, however it seems like it also supports a markdown-like formatting.
Laravel-Markdown is a server-side markdown render helper, you can use this on Laravel Blade views. markdown-js is instead client-side, it can be used, for example, to show a preview of what you're writing in real-time.
So iv been reading about peoples problems with tiny MCE "messing up" code. I understand it isn't, but I have a very minor problem that is become a major problem.
Im trying to add a simple object tag to one of my CMS pages. I need the object type to be "text/html" but whenever I save the page it converts this to "application/x-shockwave-flash"
I don't want to turn off the tinyMCE cleanup option as by the sounds of things this is a really bad thing to do.
So is there a way to stop it changing just the type attribute?
I have tried adding the code to a CMS widget and adding the widget to the page but this get the same altered result.
This thread (Object tag is not working) seems similar, but simply changing the type isn't working for me as it is automatically changing back to flash upon save.
The url i am trying to load looks like this...
(http://www.domain.com/animations/embed/one/o-t-t-d?player_width=100%&player_height=100%) I have been told that this will return flash if it is available or html if not.
Im assuming that because i'm saving the page on a PC with flash available its recognising and changing the type.
Any help appreciated.
You can edit the file js/mage/adminhtml/wysiwyg/tiny_mce/setup.js to make this happen.
Look for the settings array (around line 100). Add 'extended_valid_elements' there, like this;
var settings = {
...
extended_valid_elements: 'object[type]',
...
};
This way, TinyMCE will know the type attribute is valid and won't change it.
I am understanding this better but still not there yet.
I have a notes document with a rich text field. I want to edit it in Xpages, so that the user can enter text for an email that an agent will generate. The idea is that the user should be able to enter styled text, hopefully including pasted graphics, and this is saved to the rich text field in such a way that a later agent can copy that field to the body of an email.
On the form I have checked the field "Store contents as HTML and MIME.
In the Xpage I have bound the CKEditor directly to the field (can bind it to a scope variable if necessary).
The code in my agent is as follows:
Set rtItmFrm = emlDoc.getFirstItem("Body")
Set rtItmTo = New NotesRichTextItem(mail,"Body")
Set rtItmTo = rtItmFrm.Copyitemtodocument(mail,"Body")
Any further suggestions on reading up on MIME/CKEditor etc would also be much appreciated.
Bryan
=========================================================================
I just discovered how to modify the CKEditor in Xpages (the Rich Text Control). I have the full menu and one or two more things turned out. However, I am really puzzled by how it treats HTML. I would like to put a template for a nice HTML email (like a newsletter). Anything even a little complicated it munges and the output is messed up.
I read enough online to understand that it is not supposed to be a HTML editor, but I am really having trouble getting the results I want. I would love to put some basic skeleton HTML in there, but everything but the simplest code doesn't work.
Is there anyway to import HTML and it not get messed up using this editor?
as Per and Stephan said, Have a look at ACF filtering that is 'server side' (This is not related to CKEditor itself, but it is related to XPages).
If you have a look at the inputRichText control you will see 2 properties.
htmlFilter
htmlFilterIn
These properties determine how to filter Html on the way in to your data, and also on the way out.
This can be used to strip styling out, and also to prevent dangerous tags like some bad code here etc.
By Default the htmlFilter is set ACF (Active Content Filtering) if you look at the default rules, you will see it strips things like 'margin' out.
see /properties/acf-config.xml-sample
There is a filter called 'identity' which means don't filter anything, however beware if you use this you are not protected from and maliciously entered html.
You should look into defining your own set of rules for your ACF filter, this way you can choose which elements to remove. There is a section in Mastering XPages book about this.
If you still have any trouble, then there are some settings in CKEditor config which also control ACF (totally separate to XPages server side)
I don't think CKE changes the HTML, it is the writing back to a RT field.
Try and bind your RichText Editor to a scoped variable instead of a RichText field. This way you have access to the raw HTML and can use that to generate a MIME email. You might want to have a look at Mustache for mail merge.
Use this article series as starter how to prepare CK editor to make this possible.
And as Per mentioned: check the filtering.
The newer versions of Firefox have a new 'feature' that remembers the stuff that was filled out in a form and repopulates the form with these values on refresh (maybe in other situations as well?).
The problem is we have a quite complicated web application which uses a fair bit of ajax and hidden form fields which are never filled out by the user, but by javascript.
Because of this new 'Feature' we get a lot of errors when refreshing form because these fields are suddenly populated with invalid values.
So i'm looking for a way to turn this 'feature' off without disabling auto-completion. (because that IS useful on the fields our customers fill in)
if i put
autocomplete='off'
in my html, the effect is disabled, but this loses auto-completion (obviously).
the problem is in fields getting filled in after a refresh without any user action.
While the password manager will populate a username and password if there is exactly one match, autocomplete itself doesn't automatically populate fields. But I'm guessing you're thinking about the sort of refresh you get, say, if you reload the page. In this case the field values are restored by session history, but you might be able to turn that off by marking your page as uncacheable.
Well you should set the value of these fields to nothing or or whatever default value they have using javascript right before you start your other javascript/ajax tasks.
It is a browser feature - without going into the settings of each client browser you can't disable this.
I suggest more robust validation - client and server side.
After the page is loaded, but before you do any other logic, you should force the value to be empty:
inputElem.value = '';
Here is a jQuery solution I put together.
It doesn't disable the autofill, rather it overrides the fields after the browser has done it's thing.
I was trying to fight Chromes autofill when I made this. Just using .val('') on it's own didn't work since it triggered before chromes autofill functionality kicked it.
var noFiller = $('input[type="text"]');
noFiller.val(' ');
var t=setTimeout(function(){
noFiller.val('');
},60);//keep increasing this number until it works
The Javascript solution (setting field values to empty when the page loads or updates via Ajax) has already been mentioned.
Another option might be to generate the ids of your fields with random numbers attached to them so that the browser can't match them to cached values, but this may screw up other things.
Autocomplete isn't a new thing. Every browser has it. See this http://www.w3.org/Submission/web-forms2/#the-autocomplete
Autofill? Are you sure? Check your input's value attribute with Firebug (Firefox addon). Check you post and response in your ajax. Maybe your ajax is filling it behind scenes.
BTW: remenber to disable any external toolbar. There are some toolbars for Firefox/IE/Chrome/etc that autofill data for the user. Warning with this.
the problem I have is that I have two sets of values in a drop down list. If type 'A' is selected I want a text box to be populated with a value from the database and be read only. If Type 'B' is selected the box is to be empty and editable.
My original code is written in jsp/struts and I have sort of achieved this by using
onchange="javascript:submit()" to reload the page, but this has the obvious drawback of saving any changes you have made which means you can't really cancel.
I also have other problems with the serverside validation due to this method.
Is there a way of making a jsp page reload on change, that way I could write javascript to change the way the page looks according to the values held in the session. That way the save/submit function will only be called when the page has properly been filled out and the server side validation will work as designed.
I know that this is something that AJAX is good at doing but I am trying to avoid it if possible.
AJAX is your only other option my friend, unless on the original page load you load all the other possible values of the Text Box so you don't need to go back to the database. Well, you could try putting the text box in an IFRAME, but you will probably run into more problems with that approach than just going with AJAX.
Without AJAX what you are asking is going to be difficult. Another option (which is ugly) is to write out all possible values for the second list box into a data structure like an array or dictionary.
Then write some javascript to get the values from the data structure when the user selects from the first list box. The amount of javascript you will have to write to get this done and to do it correctly in a cross browser way will be much more difficult than simply using AJAX.
Not sure why you'd try to avoid AJAX in today's world, the JS libraries out there today make it so simple it's crazy not to try it out.
I just had to replace a page that was written as Vincent pointed out. I assume at the time it made sense for the app, given the relative size of the data 4 years ago. Now that the app has scaled though, the page was taking upwards of 30 seconds to parse the data structures repeatedly (poorly written JS? maybe).
I replaced all the logic with a very simple AJAX call to a servlet that simply returns a JSON response of values for the 2nd drop down based on what was passed to it and the response is basically instant.
Good luck to ya.
One way is to change the form's action so that you submit the form to a different url than the "save" url. This lets you reload certain aspects of the form and return to the form itself, instead of committing the data.
<script>
function reload() {
document.forms[0].action="reloadFormData.jsp";
document.forms[0].submit();
}
</script>
<form action="saveData.jsp" method="post">
<select id="A" name="B" onchange="reload()"><!-- blah --></select>
<select id="B" name="B"><!-- blah B --></select>
<input type="submit">
</form>
If I understand you correctly, that you want either a dropdown (<select>) or a textfield (<input type="text">) depending on a choice (typically a checkbox or radiobuttons) somewhere above in a form?
I that case you may need to handle the two types of input differently on the server anyway, so why not have both the selectbox and textfield in the area of the form with different names and id and one of them hidden (display = none). Then toggle visibility when the choice changes. On the server you pick eiter the selectbox or textarea input (wich will both be present unless you disable (disabled="disabled") them too, wich I think is uneccesary) depending on the choice input.
Of course if you expect that the user usually just need the text-input, and a few times only, needing a massive list; it would be better to use ajax to retrieve the list. But if it's the other way around (you need the text-field only occationally), as I assumed above, it will be faster to have both present in the initial form.
If the drop down only contain easily generateable data, like years from now to houndreds of years back it could even be much faster (requiring less bandwidth on the server) to generate the data client side using a for loop in Javascript.
I know a taglib that can fit to your problem:
AjaxTags.
I use this taglib in my J2EE projects and it is very simple to integrate it into web applications.
This taglib give you several tags designed to execute AJAX request in your jsp files.
Here is the description of each tags: http://ajaxtags.sourceforge.net/usage.html
The tag which will help you is the ajax:select tag. It allows you to populate a select tag which depends on an other field without reloading the entire jsp page.
If you more informations about it, ask me and i'll try to answer quicky.
Along the lines of what Strindhaug said, but if you need dynamic data:
Could you have the backend write JS into the page, and then the JS would change the form as required? The backend could propagate some variables for descriptions and such, and then the JS could change/update the form accordingly. If you aren't familiar with this, libs like jQuery make things like this easier and more cross-browser than rolling-your-own (at least in my experience).
Aside:
If you're not using AJAX because it was hard to code (as I didn't for a while because my first experience was from scratch and wasn't pretty), as others have said, libs like MooTools and such make it really easy now. Also, there is not shame in using AJAX properly. It has a bad rap because people do stupid things with it, but if you can't simply write premade values into the form or you have to do live look ups, this is one of AJAX's proper uses.