Vocabulary Practice Application - Forms, Arrays, Cookies?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Citoyen du Monde

    Vocabulary Practice Application - Forms, Arrays, Cookies?

    Trying to get some ideas on a simple javascript project (to teach myself the
    language).

    I want to develop a client-side vocabulary practice application that would
    allow users to
    enter their own words, their own definitions plus an example of how the word
    is
    used in practice. It'll be all client side with - cookies? to get
    persistence so that the words won't
    disappear on me each time the page is closed (which is what happened when I
    used
    just arrays with no cookies. .So, you can imagine (maybe) setting up 3
    arrays as follows:

    var word = new Array( );
    var definition = new Array( );
    var example = new Array( );

    Then, using functions like:

    addWord(); (or, newWord( ) )
    addDefinition( );
    addExample( );
    nextWord( );
    previousWord( );

    In the HTML I want 3 input fields of some kind plus 3 buttons: "Previous
    Word", "Next Word",
    "New Word".

    I was able to do this using arrays and hard-coding each new word, definition
    and word-usage-example,into the
    source, but then I thought of allowing the user to enter his/her own words,
    definitions, examples.
    This is where I started thinking of state maintenance and cookies. I'm
    thinking of allowing input of,
    say, 1,000 words at most.

    Just wondering if cookies are the right way to go.


  • Vicomte De Valmont

    #2
    Re: Vocabulary Practice Application - Forms, Arrays, Cookies?

    hi
    by closed did you mean _unloaded_ (going to another page, that is) or
    downright the window which gets closed? if your concern is to make a data
    persistent troughout more pages unloaded, arrange your internal links so
    that they carry a query: the subsequent page can via js analyze it and make
    deductions:
    <a href="www.foo.h tml?myword=cool ">
    of course, you can give an id or a name to that anchor and append the query
    accordingly to other actions occurred in the current page scripts.

    yet, if what you meant is to store on the user's machine (client) a cookie
    which keeps within a whole dictionary, no way: cookies are meant to store
    limited amount of data. I could check a manual to be more precise, I can't
    remember the amount here, but you can store at most, probably, 10 words -
    and you do NOT have unlimited capabilities to store cookies on a machine
    (you can imagine what a hacker could do if that would be possible, he could
    saturate your disk by simply storing cookies whose text is the whole page
    and making repeatedly copies of it by a loop. This I hope makes you
    understand _why_ cookis have to be limited in their scopes).

    of course, you could ask an user to donwload a js file - but here you're
    already well beyond the ability of the average user: he/she could download
    the js and save it in a path he/she prefers. Then, upon loading your page
    he/she should type the path of the js on his/her machine in a form: you
    append such path to a query so you save it throughout the session (or you
    could save such typed path to a cookies, this yes would be possible) and
    then you can dynamically write a script src=that path into every subsequent
    file he/she visitis within the "applicatio n" - this if you want to keep it
    _client_ side, which is hihgly unadvisable for this type of applications.
    Yet, maybe you just like the challenge who knows (I'm a guy who likes
    javascript challenges just beacuse, for instance lol), and yet you have to
    concur: the average user can be unable to save a js and then remember where
    it is and then type the path to it.

    Last but not least, this would work if I do it on my machine, but I never
    tried it online so I don't know if any security trick would prevent an
    online machine from retreiving local files EVEN if they are js and their
    paths typed in by the user.

    Anyway, I hope you can find hints or ideas - my suggestion doesn't mean more
    and, as I said, that should actually be made server side, that's the correct
    approach. Unless, as I said, you just relish the challenge :-)
    ciao
    Alberto vallini



    "Citoyen du Monde" <bruce_v_conway @hotmail.com>[color=blue]
    > persistence so that the words won't
    > disappear on me each time the page is closed (which is what happened when[/color]
    I


    Comment

    • Citoyen du Monde

      #3
      Persisting Form Data (Vocabulary Application) - Alberto, Bruce

      Thanks for responding to this Alberto. You've got some good ideas in here
      which
      I will definitely look into.

      I'm now looking at the following link entitled "Persisting Form Data":


      ce/overview.asp

      By 'closed' I meant shutting down IE6 completely, or even shutting down the
      computer and
      rebooting, then coming back, say, five years later, to find all my
      vocabulary words/definitions/examples still intact.

      I think you're right about cookies - probably not the most elegant solution.

      I've recklessly cut and paste a bit of the above link (page) below.

      Persisting Form Data Internet Development Index

      ----------------------------------------------------------------------------
      ----

      Using HTML to design forms comes with some drawbacks, namely the need for a
      server or client-side script to process the form data. The saveSnapshot
      behavior can be used to save a Web page and persist the form data directly
      within the page itself. This allows a larger audience to use Web forms for
      day-to-day activities without needing a special script to process and
      deliver the information.

      An expense report can be created with HTML, persisted with the saveSnapshot
      behavior, and then sent in e-mail to an employee or employer with no
      specialized scripting.

      Essential Persistence Preparations
      The saveSnapshot behavior requires certain elements in order to function: a
      meta element, a style block, an ID attribute, and a CLASS attribute on the
      object to persist.

      Security Alert Using this behavior incorrectly can compromise the security
      of your application. This behavior persists data as plain text in a saved
      Web page. Text is not encrypted and therefore not secure. Any application
      that has access to the drive where the page is saved also has access to the
      data and can tamper with it. Therefore, it is recommended that you not
      persist sensitive data like credit card numbers. For more information, see
      Security Considerations: DHTML and Default Behaviors.
      The META Tag and STYLE Block
      The meta and style elements are used to inform the browser that the Web page
      is persistent.

      <META NAME="save" CONTENT="snapsh ot">
      <STYLE>
      .saveSnapshot {behavior:url(# default#savesna pshot);}
      </STYLE>The CLASS Attribute
      The CLASS attribute identifies the type of persistence the element is using.

      <ELEMENT CLASS=saveSnaps hot ID=oPersistElem ent.. >The STYLE Attribute Set
      Inline
      The style can also be set inline with the element.

      <ELEMENT
      CLASS="saveSnap shot"
      STYLE="behavior :url(#default#s avesnapshot)"
      ID="oPersistEle ment"[color=blue]
      >Defining a Form to Persist[/color]
      Persisting form data using the saveSnapshot behavior does not require
      additional scripting. Therefore, the entire form will appear almost like any
      other form except for the required CLASS and ID attributes. These attributes
      may either be placed on the form object, or on the individual form elements.

      Persisting the Entire Form
      The following form only needs a defined CLASS in order to persist.

      <FORM ID=oPersistForm CLASS=saveSnaps hot>
      First Name: <INPUT TYPE=text>
      Last Name: <INPUT TYPE=text>
      Exemptions: <INPUT TYPE=text>
      </FORM>By giving the form object an ID and a CLASS of saveSnapshot, the
      entire form will persist. If persisting only selected elements is desired,
      then the ID and CLASS attributes can be moved from the form object onto
      those elements.

      In the following example, the First Name and Last Name text fields are
      persisted, but the Exemptions field is not. The entire Web page for this
      form would include the HTML form, the essential persistence information, and
      html, head and body elements.

      <FORM>
      First Name: <INPUT TYPE=text ID=oPersistInpu t1 CLASS=saveSnaps hot>
      Last Name: <INPUT TYPE=text ID=oPersistInpu t2 CLASS=saveSnaps hot>
      Exemptions: <INPUT TYPE=text>
      </FORM>In the next example, a complete HTML file is shown where all text
      fields are persisted.

      Show Example

      <HTML>
      <HEAD>
      <META NAME="save" CONTENT="snapsh ot">
      <STYLE>
      .saveSnapshot {behavior:url(# default#savesna pshot);}
      </STYLE>
      </HEAD>
      <BODY>
      <FORM ID=oPersistForm CLASS=saveSnaps hot>
      First Name: <INPUT TYPE=text>
      Last Name: <INPUT TYPE=text>
      Exemptions: <INPUT TYPE=text>
      </FORM>
      </BODY>
      </HTML>




      Comment

      Working...