I'm using plugin ckeditor in grails 2.4.3, latest version.
However, I cannot find option to set max length in this editor.
Any helps would be appreciated.
No such option exists. Part of the problem is that it is too hard to measure what constitutes max length for different sites. You must build your own solution based on your requirements on what "max length" means for you.
Sometimes user want the text to not contain more than N chars, sometimes the source must not be longer than M characters and sometimes the content must not exceed a certain graphical boundary (height/width) - it all depends.
Related
The default states 5000 symbols. Is this dependent on the machine's performance or something else?
From VS Code settings:
JSON: Max Items Computed
The maximum number of outline symbols and folding regions computed (limited for performance reasons).
This relates to the GUI buttons in the editor, you can use to fold down the JSON tree.
If there are more items than the maximum, the routine that prepares those buttons will just give up, and the buttons won't be displayed. I've experienced it for a package-lock.json in a project with lots of dependencies.
A reasonable approach for this would be:
Leave it at the default
If you encounter a JSON file that doesn't show the folding controls,
consider whether you actually need them
if you don't need them - no problem
if you do need them - increase the limit (perhaps temporarily)
if you then experience performance problems editing JSON files, reduce the limit
To avoid performance issues with large JSON files, JSON language support now has an upper limit on the number of folding regions and document symbols it computes (for the Outline view and breadcrumbs). By the default, the limit is 5000 items, but you can change the limit with the setting json.maxItemsComputed.
I've been building a custom module for sugarCRM and i'm running into some issue's, when installing the module i'm met with 'Database failure. Please refer to sugarcrm.log for details.'
Upon checking the log file, i can find the error is this:
"MySQL error 1118: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs
01/03/14"
Whilst my module does have alot of fields, is there anyway i could get around this? Seems like sugar doesn't give me options for varchar/text etc when creating fields.
Thanks!
I ran in to this same problem when implementing SugarCRM as a multi-tenant solution. You have a couple of options.
1) Go in to studio and set the size of your fields to a smaller value. Each character in a varchar field is a few bytes in size on average. Therefore, if you reduce the amount of characters allowed for each of your fields in studio you will allow for more fields in your module. (see http://dev.mysql.com/doc/refman/5.0/en/column-count-limit.html).
2) Divide up those fields into a couple of modules that relate to a parent module. This will spread out your fields over more than 1 table preventing you from hitting the limit.
I would be happy to assist further if you need a more in-depth explanation of either solution.
I'm using rich text editors (tiny_mce) pretty widely in a web application I'm developing. An issue I can't seem to get my head around is how to limit user input so that the length of generated content fits in my database field. Character counters, which I would normally use for non rich-text content, are pretty useless because the user does not see (or know or care about) the HTML being generated behind the scenes. i.e. If I limit the input to 100 characters and the user types 99 characters they will still likely exceed the character limit because of the html tags used to structure their content behind the scenes.
The options I see are:
Do nothing and hope for the best. Obviously not really an option. There is a good chance that the insert will fail ungracefully when attempting to save to the db (mysql in this case).
Validate the length of the generated HTML and provide user with a message if it exceeds allowed length. This will be confusing to the user who, to the best of his knowledge has met the requirements for text entry. Telling him that he has exceeded the limit when, in fact, he has only entered 99 characters, would only server to confuse/enrage
Make the database field super large with the hope that it will never be exceeded. Seems like a bad idea...
This must be a commonly encountered issue. What is the best solution here?
When the form submit, do a Javascript check on the length of the field being submitted.
As for your options:
Q: Do nothing and hope for the best.
A: Won't work. Some will will try something
Q: Validate the length of the generated HTML and provide user with a message if it exceeds allowed length.
A: I recently had a similar situation. I put a static message on the page that said the limit was 10,000, but I actually checked for 50,000. This worked for several months until someone copied and pasted out of MS Word. The user saw 5,000 characters, but it was encoded in way over 100,000
Q: Make the database field super large with the hope that it will never be exceeded. Seems like a bad idea...
A: Depending on your database and vesion, this could tolerable, not ideal, but tolerable.
A user recently inquired (OK, complained) as to why a 19-digit account number on our web site was broken up into 4 individual text boxes of length [5,5,5,4]. Not being the original designer, I couldn't answer the question, but I'd always it assumed that it was done in order to preserve data quality and possibly to provide a better user experience also.
Other more generic examples include Phone with Area Code (10 consecutive digits versus [3,3,4]) and of course SSN (9 digits versus [3,2,4])
It got me wondering whether there are any known standards out there on the topic? When do you split up your ID#? Specifically with regards to user experience and minimizing data entry errors.
I know there was some research into this, the most I can find at the moment is the Wikipedia article on Short-term memory, specifically chunking. There's also The Magical Number Seven, Plus or Minus Two.
When I'm providing ID's to end users I, personally like to break it up into blocks of 5 which appears to be the same convention the original designer of your system used. I've got no logical reason that I can give you for having picked this number other than it "feels right". Short of being able to spend a lot of money on carrying out a study, "gut instinct" and following contentions from other systems is probably the way to go.
That said, if you can make the UI more usable to the user by:
Automatically moving from the end of one field to the start of another when it's complete
Automatically moving from the start of one field to the prior field and deleting the last character when the user presses delete in an empty field that isn't the first one
OR
Replacing it with one long field that has some form of "input mask" on it (not sure if this is doable in plain HTML, but it may be feasible using one of the UI frameworks) so it appears like "_____ - _____ - _____ - ____" and ends up looking like "1235 - 54321 - 12345 - 1234"
It would almost certainly make them happier!
Don't know about standards, but from a personal point of view:
If there are multiple fields, make sure the cursor moves to the next field once a field is full.
If there's only one field, allow spaces/dashes/whatever to be used in that field because you can filter them out. It's really annoying when sites/programs force you to enter dates in "dd/mm/yyyy" format, for example, meaning the day/month must be padded with zeroes. "23/8/2010" should be acceptable.
You need to consider the wider context of your particular application. There are always pros and cons of any design decision, but their impact changes depending on the situation, so you have to think every time.
Splitting the long number into several fields makes it easier to read, especially if you choose to divide the number the same way as most of your users. You can also often validate the input as soon as the user goes to the next field, so you indicate errors earlier.
On the other hand, users rarely type long numbers like that nowadays: most of the time they just copy-paste them from whatever note-keeping solution they have chosen, in whatever format they have it there. That means that a single field, without any limit on lenght or allowed characters suddenly makes a lot of sense -- you can filter the characters out anyways (just make sure you display the final form of the number to the user at some point). There are also issues with moving the focus between fields, with browsers remembering previous values (you just have to select one number, not 4 parts of the same number then), etc.
In general, I would say that as browsers slowly become more and more usable, you should take advantage of the mechanisms they provide by using the stock solutions, and not inventing complex solutions on your own. You may be a step before them today, but in two years the browsers will catch up and your site will suck.
I'm new to the whole RFID arena.
I need to store an RFID pr asset in the database. No decision has yet been made on what system will feed that particular field (or fields?) so I just want to set aside some space right now.
Oracle has this whole "Identity" package that handles, amongst other things, the different versions and types of RFID, but I havn't seen anything for SQL server.
Perhaps I'm overcomplicating things, but I've searched wide but found no reference to how big such a tag is, or even if it is suitable for being stored in one field, or if you need multiple.
So, what columns should I have, and what should their sizes be?
Would nvarchar(10) suffice? nvarchar(20)?
There is no fixed data size for RFID tags. In fact they can store from a few bytes to a few kilobytes. They can even be used to hack into an unprotected system by storing code within them. Thus you should treat any data that you receive from them with the same suspicion that you would do from elsewhere.
As for an identifier that is uniques then if you allocate on the basis of it being no larger than a UUID then you should be OK.
AFAIK the generation 1 RFID tags are generally 128 bits, where 96 bits are the unique ID and the rest is checksum. But I strongly suspect that newer generations are at least 256 bits and it will continue to grow. I'm by no means an expert, so you may want to wait for another answer:)
So I'd go with a char or varchar of sufficient size, which should be easy to scale later.
Unfortunately, the standards in the RFID world at the moment specify all sorts of useful things, but not the tag size (these standards tend to be industry-specific and the ability to track cows may not map that well to what you have planned).
My advice would be to allocate something to hold enough for test data (nvarchar(10) should be fine) and then size it properly when you choose an actual implementation, at which point the vendor will be able to give you that information.
There is no set size for RFID tags, but I believe as it currently stands (Jan 2011) 2KB is the maximum size in HF specification, this includes the tag ID, user data and data set by the manufacturer required for the tag to function.
In the UHF specification, instead of unique IDs you have an EPC which is editable by a reader if the tag is unlocked, unlike unique IDs in HF which are set and locked by the manufacturer.
End of the day, you need to read the data layout for the memory of the tag your using. Manufactures will provide the technical document you need that explains the memory addresses available, and thus the max size you need.