After having a talk and some code Review with Eddie on Friday, he offered an interesting solution to the URL Limit which doesn't require ajax or any modification to the servlets.
He suggested that I submit the tagging xml to the Tagging Servlets (TagManagerSaveTaggingServlet and SPARQLTaggingServlet) as a file. This would involve submitting the whole form to the TaggingServlets, which would then contain an input specifying file. Great! But... when you create an inputfileElement, it comes with the browse button which allows you to pull files from your computer. We don't want this though. We want to create a file on the fly and feed it into the input stream of which the inputfileElement uses.
I did not find out how to do that.
However, the following solution is still much like the file solution, but instead of making a file on the fly and putting it in a form (also made on the fly) and submitting said form to a url within a designated iframe....
We:
-create a form on the fly with action=TaggingServlet and target=iframe
-create an input of type hidden on the fly with the tagging xml as its value
-attach the hidden input to the form
-attach the form to the body
-submit the form
Surprisingly... this works! I've yet to find (through testing or research) a limit for the size of an input in any browser. Further testing may reveal otherwise, but IE isn't complaining, which is rare.
The other plus side is the tagging Servlets don't need modification since it works in the exact same way as before except the 'tagging' parameter is nolonger in the url, but as part of a form, which as far as the Servlet is concerned, is the same thing!
hooray.
...
for now....
Showing posts with label TagManagerSavTaggingServlet. Show all posts
Showing posts with label TagManagerSavTaggingServlet. Show all posts
Tuesday, August 5, 2008
Sunday, July 13, 2008
Why there was an unexpected limit on the number of tags you could add to ED
I didn't realize this until I started making a progress bar to ED as per Ben's suggestion. Originally, I suspected ED was slower with the submiting of Tags because I added in that extra step of adding tags to the Virtuoso Server with SPARQL. As it turns out, some of the tags were being repeated, so the SPARQLTagManager was adding a tag 2 or 3 times!
I traced this problem back to the xml the ed_connotea javascript was feeding it. What's worse, if you have too many tags with too many types associated with them, then the xml would get to be too big and it can't be passed as a parameter when we call the SPARQLTaggingServlet.
Firefox doesn't state that there is a limit on the size of the parameter.
But there is one for IE.
The trouble with the xml was that every time I called save_tag_action() to make it (I didn't realize it was appending the tags on to the existing one so I'd end up with duplicate tags. It's called once for the TagManagerSaveTaggingServlet and again for the SPARQLTaggingServlet. To alleviate this problem, I call the save_tag_action() once, save the xml and re use it for both servlets.
I wonder if it would be prudent to keep the xml in a cookie and destroy it once we're done.
I traced this problem back to the xml the ed_connotea javascript was feeding it. What's worse, if you have too many tags with too many types associated with them, then the xml would get to be too big and it can't be passed as a parameter when we call the SPARQLTaggingServlet.
Firefox doesn't state that there is a limit on the size of the parameter.
But there is one for IE.
The trouble with the xml was that every time I called save_tag_action() to make it (I didn't realize it was appending the tags on to the existing one so I'd end up with duplicate tags. It's called once for the TagManagerSaveTaggingServlet and again for the SPARQLTaggingServlet. To alleviate this problem, I call the save_tag_action() once, save the xml and re use it for both servlets.
I wonder if it would be prudent to keep the xml in a cookie and destroy it once we're done.
Subscribe to:
Posts (Atom)