I want to fill <input type=”text” size=”20″ class=”username”/> with whatever I write in <input type=”text” size=”20″ class=”email”/> unless I write ‘@’. If I write ‘@’ in <input type=”text” size=”20″ class=”email”/> then <input type=”text” size=”20″ class=”username”/> will stop writing text.
<input type=”text” size=”20″ class=”email”/>
<input type=”text” size=”20″ class=”username”/>
with jQuery we can do it simply
jQuery('.email').keyup(function (e) {
var index = text.indexOf('@');
if (index == -1) {
jQuery('.username').val(text);
}else if (index) {
jQuery('.username').val(text.substring(0, index));
}
});
Remedy is
http://www.mail-archive.com/xalan-j-users@xml.apache.org/msg04890.html
copy and paste from the above link
[
Hello, Erik.
I was struggling with this problem back in November 2005, but after some
poking around I found a one-line change that has eliminated all "No more
DTM IDs" errors on my project.
I unpacked xalan_2_7_0.jar and in
src/org/apache/xml/dtm/DTMManager.java, line 362, I found, read, and (I
hope) understood this comment:
/** This value, set at compile time, controls how many bits of the
* DTM node identifier numbers are used to identify a node within a
* document, and thus sets the maximum number of nodes per
* document. The remaining bits are used to identify the DTM
* document which contains this node.
*
* If you change IDENT_DTM_NODE_BITS, be sure to rebuild _ALL_ the
* files which use it... including the IDKey testcases.
*
* (FuncGenerateKey currently uses the node identifier directly and
* thus is affected when this changes. The IDKEY results will still be
* _correct_ (presuming no other breakage), but simple equality
* comparison against the previous "golden" files will probably
* complain.)
* */
I then changed the following constant's value from 16 to 12.
public static final int IDENT_DTM_NODE_BITS = 12;
Then I added a little static initializer purely to convince myself that
my webserver actually found my copy of xalan.jar
static {
System.out.println(" IDENT_DTM_NODE_BITS: "+ IDENT_DTM_NODE_BITS );
}
My understanding of this change is that I gave up four (16-12) bits
worth of IDs for identifying documents, in exchange for four more bits
of node IDs within each document. I cannot imagine in my app needing
more than 2^12 (4096) document IDs, but I certainly need more than 2^16
(65536) worth of nodes within a document. Now I can have up to 2^20
(1,048,576) nodes per document.
Now, maybe some more knowledgable xalan developers can answer this: In
the above comment, it says: " If you change IDENT_DTM_NODE_BITS, be sure
to rebuild _ALL_ the files which use it... including the IDKey
testcases.". Now, I did rebuild the entire package, which I am sure
satisfies that requirement, but why does it have to be a compile-time
setting? Since other classes would have to refer to
DTMManager.IDENT_DTM_NODE_BITS (AFAIK, referring to a final variable
like this doesn't actually COPY the value into the other classes, or
does it?) Would it not also work to provide 16 as a default, but allow
it to be overridden, like this?
public static final int IDENT_DTM_NODE_BITS =
Integer.parseInt(System.getProperty("org.apache.xml.dtm.DTMManager.IDENT
_DTM_NODE_BITS"), "16");
Then people who need another value can simply start their app with
-Dorg.apache.xml.Dorg.apache.xml.dtm.DTMManager.IDENT_DTM_NODE_BITS=12
on the command line and be done with it.
If there is a downside to what I have done, PLEASE discuss! So far, I
do not see one!
tlj
Timothy Jones - Sr. Systems Engineer, Development
(813) 637-5366 - Syniverse Technologies
Learn a new language, grow a new soul, live a new life.
]