Changed the datasource.properties file to include specification for the SPARQL Endpoint.
SPARQL_EP_url = http://biomoby.elmonline.ca/sparql
SPARQL_EP_query_param_name = query
SPARQL_EP_misc_params = { \
"default-graph-uri": "sandbox", \
"should-sponge": "", \
"format": "text/html", \
"debug": "on" \
}
SPARQL_EP_url specifies the SPARQL Endpoint URL
SPARQL_EP_query_param_name specifies the name of the query parameter used by the SPARQL Endpoint.
ie. the name in the name/value pairs used when submitting a SPARQL query as a URL parameter
SPARQL_EP_misc_params is a JSON object with all the name/value pairs that the SPARQL Endpoint needs for URL Parameters
These specifications are used to set the same parameters kept in a SPARQL_EP_params JSON object in the ed_connotea_patched.js
Monday, August 18, 2008
Friday, August 15, 2008
Finished the basics for the ED Widget.
It's in two JS files:
-EDwidget (which needs to be included in the html page and handles the adding of all necessary css and javascripts on the fly)
-EDlet (this creates the actual EDlet inside the div with id="EDlet")
To use it: (Haven't deployed it yet, so don't expect to use it right away)
include the:
a script tag in the html head with
type = "text/javascript"
src = "http://arch.uwindsor.ca:8080/ED/JS/EDwidget.js"
include a div somewhere with id="EDlet"
I'm leaving up the stylizing of the EDlet div to the web developer using it in their page, but I have include some basic EDlet API functions to make it easier.
Note: You need to be logged into ED for this to work since it requires a cookie
It's in two JS files:
-EDwidget (which needs to be included in the html page and handles the adding of all necessary css and javascripts on the fly)
-EDlet (this creates the actual EDlet inside the div with id="EDlet")
To use it: (Haven't deployed it yet, so don't expect to use it right away)
include the:
a script tag in the html head with
type = "text/javascript"
src = "http://arch.uwindsor.ca:8080/ED/JS/EDwidget.js"
include a div somewhere with id="EDlet"
I'm leaving up the stylizing of the EDlet div to the web developer using it in their page, but I have include some basic EDlet API functions to make it easier.
Note: You need to be logged into ED for this to work since it requires a cookie
Wednesday, August 6, 2008
Connotea Seperation
Went through the new ed_connotea.js.template javascript and finished modifying it like I did the previous ed_connotea js so that it works with the Connotea free ED that I'm working on.
Labels:
Connotea,
Connotea seperated,
ED,
ed_connotea.js.template,
js
Tuesday, August 5, 2008
URL Limit Solution
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....
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....
Tuesday, July 29, 2008
Internet Explorer 7 URL limit
Here's the catch....
After much testing, it comes down to this. The tags aren't inserting into IE7 because the URL size limit in IE 7 is 2048 which is weird because I'm getting stuck around 1600. This is for Get methods in IE.
After much testing, it comes down to this. The tags aren't inserting into IE7 because the URL size limit in IE 7 is 2048 which is weird because I'm getting stuck around 1600. This is for Get methods in IE.
Monday, July 21, 2008
Accessing your webapps on your Mac OS X from your Parallels
If you're using a mac and running Parallels and want to test your web apps in IE without having to package it in a war and move it over to your Parallels side...
You will find this INCREDIBLY useful:
Andy Peatling's HOWTO access your webapps on Mac OS X from Parallels Windows XP
And if you're easily confused like I am...
DocumentRoot refers to your CATALINA_HOME/webapps/
and
ServerName is whatever you want it to be
With ED, I set it up locally as (for example) www.entitydescriber.local
so as opposed to using localhost
I can now do http://www.entitydescriber.local:8080/ED/manualURI
Of couse, all this configuration with IPs is only really useful if your IP doesn't change. If it does like with me. then you need to reconfigure when you get to work for your work IP and home for your home IP
You will find this INCREDIBLY useful:
Andy Peatling's HOWTO access your webapps on Mac OS X from Parallels Windows XP
And if you're easily confused like I am...
DocumentRoot refers to your CATALINA_HOME/webapps/
and
ServerName is whatever you want it to be
With ED, I set it up locally as (for example) www.entitydescriber.local
so as opposed to using localhost
I can now do http://www.entitydescriber.local:8080/ED/manualURI
Of couse, all this configuration with IPs is only really useful if your IP doesn't change. If it does like with me. then you need to reconfigure when you get to work for your work IP and home for your home IP
Labels:
file sharing,
localhost,
localhost:8080,
Mac OS X,
Parallels,
Windows XP
Friday, July 18, 2008
Error Handling
Getting 504 Errors from our Virtuoso OpenLink SPARQL Endpoint at biomoby.elmonline.ca/sparql
And the Tomcat Manager's down.
So I've taken this opportunity to test out some error-handling in ED. Mostly just refining the E-mail function I have set up to e-mail to ed.developers@gmail.com any errors that may popup in the SPARQLTaggingServlet. Usually it comes down to an error in trying connect to the SPARQL Endpoint in which case I fire off an E-mail to the developers gmail with
-the Response Code
-tagging XML
-Time of Error
-Extra Information (Insert statement, HTML returned from the connection (usually contains some clue as to what happenned) and some information about where the error occurred
Put in a variable and some if statements to activate and deactivate the use of the SPARQL Endpoint in case it goes down, but we still want ED to work with just ED Database on arch. In addition to this, I've decided that any errors codes returned from the SPARQLTaggingServlets or Timeouts while submitting - I'll just let it go through to connotea anyways and hide the fact that there was an error from the user.
Reasoning:
1) The tags were submitted to ED Database via Jena already
2) If there was an error in the SPARQLTaggingServlet - it has been e-mailed to the developer's email, recorded and I will know about it
3) People can still keep using ED even if the SPARQL Endpoint goes down
which seems to be happenning a lot lately
And the Tomcat Manager's down.
So I've taken this opportunity to test out some error-handling in ED. Mostly just refining the E-mail function I have set up to e-mail to ed.developers@gmail.com any errors that may popup in the SPARQLTaggingServlet. Usually it comes down to an error in trying connect to the SPARQL Endpoint in which case I fire off an E-mail to the developers gmail with
-the Response Code
-tagging XML
-Time of Error
-Extra Information (Insert statement, HTML returned from the connection (usually contains some clue as to what happenned) and some information about where the error occurred
Put in a variable and some if statements to activate and deactivate the use of the SPARQL Endpoint in case it goes down, but we still want ED to work with just ED Database on arch. In addition to this, I've decided that any errors codes returned from the SPARQLTaggingServlets or Timeouts while submitting - I'll just let it go through to connotea anyways and hide the fact that there was an error from the user.
Reasoning:
1) The tags were submitted to ED Database via Jena already
2) If there was an error in the SPARQLTaggingServlet - it has been e-mailed to the developer's email, recorded and I will know about it
3) People can still keep using ED even if the SPARQL Endpoint goes down
which seems to be happenning a lot lately
Labels:
email,
error,
Error handling,
SPARQL,
SPARQL Endpoint,
SPARQLTaggingServlet
Subscribe to:
Posts (Atom)