By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,679 Members | 2,763 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,679 IT Pros & Developers. It's quick & easy.

Vocabulary Practice Application - Forms, Arrays, Cookies?

P: n/a
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.
Jul 20 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
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.html?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 "application" - 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
http://www.unitedscripters.com/
"Citoyen du Monde" <br************@hotmail.com>
persistence so that the words won't
disappear on me each time the page is closed (which is what happened when

I
Jul 20 '05 #2

P: n/a
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":

http://msdn.microsoft.com/library/de...thor/persisten
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="snapshot">
<STYLE>
.saveSnapshot {behavior:url(#default#savesnapshot);}
</STYLE>The CLASS Attribute
The CLASS attribute identifies the type of persistence the element is using.

<ELEMENT CLASS=saveSnapshot ID=oPersistElement.. >The STYLE Attribute Set
Inline
The style can also be set inline with the element.

<ELEMENT
CLASS="saveSnapshot"
STYLE="behavior:url(#default#savesnapshot)"
ID="oPersistElement"
Defining a Form to Persist

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=saveSnapshot>
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=oPersistInput1 CLASS=saveSnapshot>
Last Name: <INPUT TYPE=text ID=oPersistInput2 CLASS=saveSnapshot>
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="snapshot">
<STYLE>
.saveSnapshot {behavior:url(#default#savesnapshot);}
</STYLE>
</HEAD>
<BODY>
<FORM ID=oPersistForm CLASS=saveSnapshot>
First Name: <INPUT TYPE=text>
Last Name: <INPUT TYPE=text>
Exemptions: <INPUT TYPE=text>
</FORM>
</BODY>
</HTML>


Jul 20 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.