ನೈಜ-ಸಮಯದ ಫಾರ್ಮ್ ಮೌಲ್ಯಮಾಪನದೊಂದಿಗೆ ನಿಮ್ಮ ವೆಬ್ ಸಂದರ್ಶಕರನ್ನು ಆಕರ್ಷಿಸಿ

ಆನ್ಲೈನ್ ಫಾರ್ಮ್

The first impression you usually have as a user of a Web Application is when you fill out a web form. I'm amazed at the number of web forms out there that have zero validation or that wait for you to submit your form contents before telling you what problems that you might have.

My rule of thumb is that anything that is not validated is supported. Anything that can be validated prior to submitting the form must be. With the advent of Ajax, you can even validate data against your database prior to submission. Don't pick the lazy route – users appreciate the help!

ಇಲ್ಲಿ ಕೆಲವು ಉದಾಹರಣೆಗಳು:

  1. ಮಿಂಚಂಚೆ ವಿಳಾಸಗಳು – I don't mind forms that make you fill out your email address twice to validate them, but the fact that they don't tell you whether or not they match or are constructed appropriately is inexcusable.
  2. ಪಾಸ್ವರ್ಡ್ಗಳು – If you're going to make me type in a password twice, then please validate that the values are the same before posting the form.
  3. ಗುಪ್ತಪದದ ಸಾಮರ್ಥ್ಯ – If you require a certain password strength (combination of alphanumeric characters or cases), then provide some feedback for me while I'm typing my password in. Don't wait for me to submit before telling me it failed.
  4. ದಿನಾಂಕ – If you'd like the date in a m/d/yyyy format, then allow me to enter the information in a single field by typing those values and formatting them appropriately. If you want leading zeros, put them in after. It's okay to display one format and save another in your database.
  5. ಇಂದಿನ ದಿನಾಂಕ - ಅದನ್ನು ನನಗೆ ಭರ್ತಿ ಮಾಡಿ! ನೀವು ಈಗಾಗಲೇ ತಿಳಿದಿರುವಾಗ ದಿನಾಂಕವನ್ನು ಭರ್ತಿ ಮಾಡಲು ನೀವು ನನ್ನನ್ನು ಏಕೆ ಕೇಳುತ್ತಿದ್ದೀರಿ ?!
  6. ದಿನಾಂಕ ಸ್ವರೂಪ – If you have an international application, you can default a date format based on Internationalization of your application. Of course, it's good to have an option for users to override that option and select their own.
  7. ಸಾಮಾಜಿಕ ಭದ್ರತಾ ಸಂಖ್ಯೆಗಳು – it's pretty simple to add some javascript that automatically jumps from field to field or programmatically put a dash in between values.
  8. ದೂರವಾಣಿ ಸಂಖ್ಯೆಗಳು – taking Internationalization into consideration, these types of fields also can be simplified by formatting the telephone number in the interface, but saving it in another format that's efficient for your back-end. Don't make your users type in parenthesis, spaces, and dashes.
  9. ಗರಿಷ್ಠ ಪಠ್ಯ ಉದ್ದ – if you limit the number of characters stored in your database, then DON'T let me type that many characters in! It doesn't even require difficult validation… it's just a setting on the textbox.
  10. ಕನಿಷ್ಠ ಪಠ್ಯ ಉದ್ದ - ನಿಮಗೆ ಕನಿಷ್ಠ ಪಠ್ಯ ಉದ್ದದ ಅಗತ್ಯವಿದ್ದರೆ, ನಾನು ಸಾಕಷ್ಟು ಅಕ್ಷರಗಳನ್ನು ಹೊಂದುವವರೆಗೆ ಅಲಾರಂ ಅನ್ನು ಧ್ವನಿಸಿ.

Here's an example of a Password Strength function from ಗೀಕ್ ಬುದ್ಧಿವಂತಿಕೆ:

ಪಾಸ್ವರ್ಡ್ ಟೈಪ್ ಮಾಡಿ:

ಅಪಡೇಟ್: 10/26/2007 - ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಲೈಬ್ರರಿಯೊಂದಿಗೆ ಅಚ್ಚುಕಟ್ಟಾಗಿ ಸಂಪನ್ಮೂಲವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು ಲಭ್ಯವಿದೆ ಫಾರ್ಮ್ valid ರ್ಜಿತಗೊಳಿಸುವಿಕೆಯನ್ನು ಲೈವ್ವಾಲಿಡೇಶನ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.

16 ಪ್ರತಿಕ್ರಿಯೆಗಳು

  1. 1

    I agree those are great features for forms, but saying that it is “inexcusable” to not do perform front end javascript validation is a more of an personal opinion. I love working in javascript, and have written some pretty neat editmasks to do some of the things you talk about, but a lot of them are far from trivial, and many of the javascript form validation packages out there have a number of big holes. Not everyone will invest the time into duplicating their back end validation with (more often than not) more complex front end javascript validation.

    ಒಳ್ಳೆಯ ಅಂಕಗಳು, ಆದರೆ ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ ಪ್ರತಿ ಆನ್‌ಲೈನ್ ರೂಪ “ಅಗತ್ಯಗಳು” ಎಂದು ಖಚಿತವಾಗಿ ಹೇಳಲಾಗುವುದಿಲ್ಲ.

  2. 2

    ಪಾಸ್ವರ್ಡ್ ಪರೀಕ್ಷಕವು ತುಲನಾತ್ಮಕವಾಗಿ ಮುರಿದುಹೋಗಿದೆ. ಯಾವುದೇ ಪಾಸ್‌ವರ್ಡ್ ಉದ್ದವಾಗಿದ್ದರೆ ಸಾಕು.

    ಉದಾಹರಣೆ:

    ಇದು ನಿಜವಾಗಿಯೂ ಸಾಧಾರಣ ಪಾಸ್‌ವರ್ಡ್ ಆಗಿದೆಯೇ?

    f46dffe6ff4ffgdfgfjfgyu656hfdt74tyhdtu5674yfgh6uhhye45herdhrt64684hythdfth54y54348fgdcvzse8cn984v3p4m6vq98476m3wuw89ewfucsd8fg67s4v8tw76u340m6tver7nt+s89346vs+0em9u+s+09hrtuhss586ysvne4896vb4865tbv089rt++

  3. 4

    ಅಜಾಕ್ಸ್ / ಸರ್ವರ್ ಸೈಡ್ ation ರ್ಜಿತಗೊಳಿಸುವಿಕೆಯಾಗಿದ್ದಾಗ ನೀವು ಬಳಕೆದಾರರಿಗೆ ಕ್ಲೈಂಟ್ ಸೈಡ್ valid ರ್ಜಿತಗೊಳಿಸುವಿಕೆಯ ಅನಿಸಿಕೆ ನೀಡಿದಾಗ ನನಗೆ ಉತ್ತಮ ಫಾರ್ಮ್ ಮೌಲ್ಯಮಾಪನ.
    ಸಂಪೂರ್ಣ ಫಾರ್ಮ್ ಅನ್ನು ಅಜಾಕ್ಸ್ ಮೂಲಕ ಸರ್ವರ್‌ಗೆ ಪೋಸ್ಟ್ ಮಾಡುವ ಕೆಲವು ಈವೆಂಟ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ (ಕೀಅಪ್, ಮಸುಕು, ಕ್ಲಿಕ್, ಇತ್ಯಾದಿ…) ಅನ್ನು ನೀವು ಸರಳವಾಗಿ ಲಗತ್ತಿಸಬೇಕು, ಅನುಗುಣವಾದ ದೋಷ ಸಂದೇಶಗಳನ್ನು ಹಿಂದಿರುಗಿಸುವ “ಚೆಕ್” ಕಾರ್ಯವನ್ನು ಆಹ್ವಾನಿಸಿ (ಈ ಪಾಸ್‌ವರ್ಡ್ ತುಂಬಾ ಸರಳ, ಆ ದಿನಾಂಕವು ತಪ್ಪಾದ ಸ್ವರೂಪದಲ್ಲಿದೆ, ಇತ್ಯಾದಿ…)
    ಸಲ್ಲಿಕೆ ಬಟನ್ ಕ್ಲಿಕ್ ಮಾಡುವ ಮೂಲಕ ಬಳಕೆದಾರರು ಅಂತಿಮವಾಗಿ ಫಾರ್ಮ್ ಅನ್ನು ಪೋಸ್ಟ್ ಮಾಡಿದಾಗ, ಡೇಟಾಬೇಸ್ ಅಥವಾ ಇನ್ನಿತರ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಡೇಟಾವನ್ನು ಸೇರಿಸುವ ಮೊದಲು ಫಾರ್ಮ್ ಅನ್ನು ಕೊನೆಯ ಬಾರಿ ಮೌಲ್ಯೀಕರಿಸಲು ನೀವು “ಚೆಕ್” ಸರ್ವರ್ ಸೈಡ್ ಫಂಕ್ಷನ್ ಅನ್ನು ಬಳಸಬಹುದು.
    ಈ ರೀತಿಯಾಗಿ, ಬಳಕೆದಾರರು ಒಂಥೆಗೊ ation ರ್ಜಿತಗೊಳಿಸುವಿಕೆಯಿಂದ ಸಂತೋಷಪಡುತ್ತಾರೆ ಮತ್ತು ಡೆವಲಪರ್‌ಗಳು ಸರ್ವರ್ ಸೈಡ್ ಮಾತ್ರ valid ರ್ಜಿತಗೊಳಿಸುವಿಕೆಯ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಸಂತೋಷಪಡುತ್ತಾರೆ.

    • 5
      • 6

        ಅಷ್ಟು ವೇಗವಾಗಿ ಡೌಗ್ ಅಲ್ಲ - ಹಾರಾಟದಲ್ಲಿ ಎಸ್‌ಎಸ್‌ಎನ್ ಅನ್ನು ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡುವಂತಹ ಈ ಉಪಯುಕ್ತ ವೈಶಿಷ್ಟ್ಯಗಳು ಕ್ಷುಲ್ಲಕವೆಂದು ನಿಮ್ಮ ಮೂಲ ಪ್ರಮೇಯವನ್ನು ನಾನು ಒಪ್ಪುತ್ತೇನೆ. ಮತ್ತು ಸ್ವರೂಪದಲ್ಲಿ ess ಹಿಸದೆ ನೀವು ಅದನ್ನು ಸರಿಪಡಿಸಿದಾಗ ಅದು ತಪ್ಪು ಎಂಬ ಸಂದೇಶವನ್ನು ಪೋಸ್ಟ್ ಮಾಡಲು ಸೋಮಾರಿಯಾಗಿದೆ.

        ಆದಾಗ್ಯೂ, ಅಜಾಕ್ಸ್ ಜೊತೆಯಲ್ಲಿ ಸರ್ವರ್ ಸೈಡ್ ಲಾಜಿಕ್ ಅನ್ನು ಬಳಸುವ ಬಗ್ಗೆ ನಾನು ನಿಕೋಲಸ್ ಅವರೊಂದಿಗೆ ಒಪ್ಪುತ್ತೇನೆ.

  4. 7

    ನಿಮ್ಮ ಶೀರ್ಷಿಕೆ “ನಿಮ್ಮ ಸ್ನೇಹಿತರನ್ನು ಆಕರ್ಷಿಸಿ…” ಎಂದು ಹೇಳುತ್ತದೆ ಆದರೆ ಪೋಸ್ಟ್‌ನಲ್ಲಿ ಫೋನ್ ಮಾಡಿದ ಈ 2 ನಿಮಿಷದಿಂದ ನೀವು ನನ್ನನ್ನು ಮೆಚ್ಚಿಸಲು ವಿಫಲರಾಗಿದ್ದೀರಿ.

    ನಿಮ್ಮ ಶೀರ್ಷಿಕೆಯನ್ನು ಪುನಃ ಬರೆಯಿರಿ (ತುಂಬಾ ದಾರಿತಪ್ಪಿಸುವ, ಉದಾಹರಣೆಗಳು ಮತ್ತು ಅಭ್ಯಾಸಗಳನ್ನು ಚರ್ಚಿಸಲಾಗುತ್ತಿದೆ ಎಂದು ಒಬ್ಬರು ಯೋಚಿಸುವಂತೆ ಮಾಡುತ್ತದೆ).

    If people are not doing this already in their forms, then they are just learning or the form is not important enough to use validation.

    ನಿಜವಾದ ವೆಬ್ ಪ್ರೋಗ್ರಾಮರ್ಗಳು ಇದನ್ನು ಈಗಾಗಲೇ ತಿಳಿದಿದ್ದಾರೆ ಮತ್ತು ಅದನ್ನು ಮಾಡುತ್ತಾರೆ.

    • 8

      ಜೇ,

      Sorry about that! My point was definitely not to provide developer feedback – I really was coming from the point of view of a Product Manager. I agree with you – but it’s interesting that some other developers don’t! I think that’s unfortunate.

      ಸಮಯ ತೆಗೆದುಕೊಂಡಿದ್ದಕ್ಕಾಗಿ ಧನ್ಯವಾದಗಳು!
      ಡೌಗ್

  5. 9

    Application ರ್ಜಿತಗೊಳಿಸುವಿಕೆಯು ಯಾವುದೇ ಅಪ್ಲಿಕೇಶನ್‌ನ ಅಗತ್ಯ ಅಂಶವಾಗಿರುವುದನ್ನು ನಾನು ಸಂಪೂರ್ಣವಾಗಿ ಒಪ್ಪುತ್ತೇನೆ. ತಂಡದ ನಾಯಕನಾಗಿ, valid ರ್ಜಿತಗೊಳಿಸುವಿಕೆಗಳನ್ನು ಕಳೆದುಕೊಂಡಿರುವುದು ಅಥವಾ ಪಠ್ಯ ಇನ್ಪುಟ್ ಉದ್ದಗಳನ್ನು ನಿರ್ಬಂಧಿಸುವಂತಹ ಕಾರಣಗಳಿಗಾಗಿ ನಾನು ಸಾಮಾನ್ಯವಾಗಿ ಕೋಡ್ ಅನ್ನು "ಮುಗಿದಿದೆ" ಎಂದು ಕಳುಹಿಸುತ್ತಿದ್ದೇನೆ.

    ನಾನು ಕೆಲಸ ಮಾಡುವ ಹೆಚ್ಚಿನ ವಿಷಯಗಳಿಗೆ ಏನಾದರೂ ಕೆಲಸ ಮಾಡಲು, ಸಾಮಾನ್ಯ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಮತ್ತು ಬಳಕೆದಾರರು ನಾನು ಉದ್ದೇಶಿಸಿದ ರೀತಿಯಲ್ಲಿ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸಿದರೆ 50% ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ನಾನು ಕಂಡುಕೊಂಡಿದ್ದೇನೆ. ಅಭಿವೃದ್ಧಿಯ ಇತರ 50% ಸಮಯವು ಅವರ ಇನ್ಪುಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವುದು, ಡೇಟಾ ಸಮಗ್ರತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳುವುದನ್ನು ಖಾತ್ರಿಪಡಿಸುವುದು ಮತ್ತು ದುರುದ್ದೇಶಪೂರಿತ ಡೇಟಾವನ್ನು ನಮೂದಿಸಲು ಫಾರ್ಮ್ ಕ್ಷೇತ್ರಗಳನ್ನು ಅನುಮತಿಸದಂತೆ ಮಾಡುತ್ತದೆ.

    ನನ್ನ ಹವಾ ಸ್ವಿಂಗ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ನಾನು ಇನ್‌ಪುಟ್‌ವೆರಿಫೈಯರ್‌ಗಳನ್ನು ಹೇಗೆ ಬಳಸುತ್ತೇನೆ ಎಂಬುದರ ಕುರಿತು ನಾನು ಪೋಸ್ಟ್ ಬರೆದಿದ್ದೇನೆ ಮತ್ತು ಇಮೇಲ್ ಪಠ್ಯ ಕ್ಷೇತ್ರವನ್ನು ನಾನು ಹೇಗೆ ಪರಿಶೀಲಿಸುತ್ತೇನೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. ಫೋನ್ ಸಂಖ್ಯೆಗಳು, ಪಿನ್‌ಕೋಡ್‌ಗಳು, ಎಸ್‌ಎಸ್‌ಎನ್‌ಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ಮೌಲ್ಯೀಕರಿಸಲು ನಾನು ಬಳಸುವ ನಿಯಮಿತ ಅಭಿವ್ಯಕ್ತಿ ಸುಲಭವಾಗಿ ಮಾರ್ಪಡಿಸಬಹುದು.

    ನನ್ನ ಬ್ಲಾಗ್ ಪೋಸ್ಟ್ ಇದೆ http://timarcher.com/?q=node/36

    ಉತ್ತಮ ಬರಹ ಡೌಗ್!

  6. 10

    ನಾನು ಒಪ್ಪುತ್ತೇನೆ. ಪಾಸ್‌ವರ್ಡ್‌ಗಳು ನಿಜವಾಗಿಯೂ ಮುಖ್ಯ ಮತ್ತು ಅದನ್ನು ಗಂಭೀರವಾಗಿ ಪರಿಗಣಿಸಬೇಕು. ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಎರಡು ಬಾರಿ ಟೈಪ್ ಮಾಡುವುದು ಬಹುತೇಕ ಸಾಮಾನ್ಯವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಆದರೆ ಎರಡು ಪಾಸ್ವರ್ಡ್ಗಳ ಸಿಂಧುತ್ವವನ್ನು ತೋರಿಸದಿರುವುದು ಅದನ್ನು ಗಂಭೀರವಾಗಿ ಪರಿಗಣಿಸುತ್ತಿಲ್ಲ ಎಂದು ತೋರಿಸುತ್ತದೆ.

  7. 11

    ಕ್ಲೈಂಟ್ ation ರ್ಜಿತಗೊಳಿಸುವಿಕೆಯು ಬಹಳ ಬಳಕೆದಾರ ಸ್ನೇಹಿ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ ಎಂದು ನಾನು ಒಪ್ಪುತ್ತೇನೆ. ಆದಾಗ್ಯೂ, ations ರ್ಜಿತಗೊಳಿಸುವಿಕೆಗಳು ಸ್ವತಃ ಅರ್ಥಪೂರ್ಣವಾಗಿದೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿದೆ.

    Valid ರ್ಜಿತಗೊಳಿಸುವಿಕೆಯು ಬಳಕೆದಾರರನ್ನು ಹೇಗೆ ದಾರಿ ತಪ್ಪಿಸುತ್ತದೆ ಮತ್ತು ಕೆಟ್ಟದಾಗಿ, ಅವರನ್ನು ನಮ್ಮ ಸೈಟ್‌ನಿಂದ ಓಡಿಸಬಹುದು ಎಂಬುದಕ್ಕೆ ನೀವು ಅದ್ಭುತ ಉದಾಹರಣೆಯನ್ನು ನೀಡಿದ್ದೀರಿ:

    ಗೀಕ್ ವಿಸ್ಡಮ್ನ ಪಾಸ್ವರ್ಡ್ ಸಾಮರ್ಥ್ಯದ ಮೌಲ್ಯಮಾಪನವು ಪರಿಗಣಿಸುತ್ತದೆ tZhKwnUmIss ದುರ್ಬಲ ಪಾಸ್ವರ್ಡ್ ಎಂದು. ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಬಲವಾದ ಪಾಸ್‌ವರ್ಡ್ ಮಾತ್ರವಲ್ಲದೆ ಇದು ಬಳಕೆದಾರರನ್ನು ದೂರವಿರಿಸುತ್ತದೆ ಏಕೆಂದರೆ ಈ ಪಾಸ್‌ವರ್ಡ್ ಬಳಸಿ ನಿಮ್ಮ ಸೈಟ್‌ಗೆ ಲಾಗಿನ್ ಆಗುವುದು ಹೇಗಾದರೂ ಅಸುರಕ್ಷಿತವಾಗಿದೆ ಎಂಬ ತಪ್ಪು ಅಭಿಪ್ರಾಯವನ್ನು ನೀಡುತ್ತದೆ.

    ಉತ್ತಮ ಪಾಸ್‌ವರ್ಡ್ ಕನಿಷ್ಠ ಆರು ಅಕ್ಷರಗಳಷ್ಟು ಉದ್ದವಾಗಿದೆ ಮತ್ತು ಸಂಖ್ಯೆಗಳು ಮತ್ತು ಅಕ್ಷರಗಳನ್ನು ಹೊಂದಿರಬೇಕು ಎಂದು ಬಳಕೆದಾರರಿಗೆ ಸುಳಿವು ನೀಡುವುದು ಉತ್ತಮ (ಮತ್ತು ಸುಲಭ).

    ಪ್ರಶ್ನಾರ್ಹ ಇತರ ations ರ್ಜಿತಗೊಳಿಸುವಿಕೆಗಳು ಬಳಕೆದಾರರ ಹೆಸರುಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ, ಅದು ನಿರ್ದಿಷ್ಟ ಕನಿಷ್ಠ ಉದ್ದದ ಅಗತ್ಯವಿರುತ್ತದೆ ಅಥವಾ ಸ್ಥಳಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. ಬಳಕೆದಾರಹೆಸರುಗಳಲ್ಲಿ ಏನು ತಪ್ಪಾಗಿದೆ X, ಜಾನ್ ಡೋ, ಅಥವಾ # *! §? ನಾನು ಅದನ್ನು ನಿಭಾಯಿಸುತ್ತೇನೆ.

  8. 12

    ನಾನು ಒಪ್ಪುತ್ತೇನೆ. ಕೆಲವು ರೂಪಗಳು ಉತ್ತಮವಾಗಿ ಕಾಣುತ್ತವೆ, ಆದರೆ ಇದು ಉತ್ತಮ ಮೌಲ್ಯಮಾಪನವನ್ನು ನೀಡುವುದಿಲ್ಲ. ವೈಯಕ್ತಿಕ ಮಾಹಿತಿಯನ್ನು ನೀಡಲಾಗಿದೆ ಮತ್ತು ಹಾರ್ಡ್ ನಕಲಿನಲ್ಲಿರುವ ಯಾವುದೇ ವ್ಯವಹಾರ ರೂಪಗಳಂತೆ ಅದನ್ನು ಗಂಭೀರವಾಗಿ ಪರಿಗಣಿಸುವುದು ಸೂಕ್ತವಾಗಿದೆ.

  9. 13
  10. 14

    ನಿಮ್ಮಲ್ಲಿರುವವರು ಈ ಪೋಸ್ಟ್‌ಗೆ ಚಂದಾದಾರರಾಗಿದ್ದಾರೆ, ನಾನು ಅಚ್ಚುಕಟ್ಟಾಗಿ ಕಂಡುಕೊಂಡಿದ್ದೇನೆ ಫಾರ್ಮ್ ಮೌಲ್ಯಮಾಪನಕ್ಕಾಗಿ ಆನ್‌ಲೈನ್ ಲೈಬ್ರರಿ ಲೈವ್ ವ್ಯಾಲಿಡೇಶನ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.

  11. 15

    ನೈಜ ಸಮಯದ ಫಾರ್ಮ್ ation ರ್ಜಿತಗೊಳಿಸುವಿಕೆಯ ಬಗ್ಗೆ ನೀವು ಪೋಸ್ಟ್ ಮಾಡುವುದು ಸ್ವಲ್ಪ ಮನೋರಂಜನೆಯಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ ಮತ್ತು ಇನ್ನೂ, ಪೋಸ್ಟ್‌ನ ಕೆಳಭಾಗದಲ್ಲಿರುವ ನಿಮ್ಮ ಕಾಮೆಂಟ್ ಫಾರ್ಮ್ ಇವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ಒದಗಿಸುವುದಿಲ್ಲ…

    ನಿಮ್ಮ ಆಲೋಚನೆಗಳನ್ನು ಅಂತರ್ಜಾಲದಲ್ಲಿ ಬ್ಲಾಗ್ ಮಾಡಲು ನೀವು ವರ್ಡ್ಪ್ರೆಸ್ ಅನ್ನು ಬಳಸುತ್ತಿರುವಿರಿ ಎಂದು ನಾನು ತಿಳಿದುಕೊಂಡಿದ್ದೇನೆ, ಆದರೆ ನೀವು ಬೋಧಿಸುವದನ್ನು ನೀವು ಅಭ್ಯಾಸ ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಅಂತಹ ಕೆಟ್ಟ ಆಲೋಚನೆಯಲ್ಲ. 🙂

    ಒಳ್ಳೆಯ ಪೋಸ್ಟ್, ಮೂಲಕ, ನೀವು ಬರೆದ ಎಲ್ಲವನ್ನು ನಾನು ಒಪ್ಪಿಕೊಳ್ಳದಿದ್ದರೂ ಸಹ.

ನೀವು ಏನು ಆಲೋಚಿಸುತ್ತೀರಿ ಏನು?

ಸ್ಪ್ಯಾಮ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಈ ಸೈಟ್ ಅಕಿಸ್ಸೆಟ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ನಿಮ್ಮ ಕಾಮೆಂಟ್ ಡೇಟಾವನ್ನು ಹೇಗೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ತಿಳಿಯಿರಿ.