Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Topic map upload form #154

Open
GoogleCodeExporter opened this issue Mar 16, 2015 · 11 comments
Open

Topic map upload form #154

GoogleCodeExporter opened this issue Mar 16, 2015 · 11 comments

Comments

@GoogleCodeExporter
Copy link

The manage page needs to be extended with a topic map upload form, so that 
users can upload their own topic maps. Of course, we'll simply store them 
as files in the WEB-INF/topicmaps directory, but this means users don't 
have to worry about where the files are physically located.

There should be links to this form from the Ontopoly and Omnigator topic 
map lists.

This feature is frequently requested by users, so this is something we 
really need to do.

Original issue reported on code.google.com by lar...@gmail.com on 17 Nov 2009 at 6:12

@GoogleCodeExporter
Copy link
Author

provided an import functionality in the manage plugin, see r657 for more 
details.

Original comment by thomas.n...@gmail.com on 23 Nov 2009 at 11:53

@GoogleCodeExporter
Copy link
Author

Currently the path where uploaded topic maps are stored is hard coded:

String dirName = getServletContext().getRealPath("/") +
"../omnigator/WEB-INF/topicmaps/";

This should be configurable, the best guess I have so far is to extend 
tm-sources.xml
to include an upload path.

Original comment by thomas.n...@spaceapplications.com on 25 Nov 2009 at 11:30

@GoogleCodeExporter
Copy link
Author

The proper way to do this is to add support for this through the 
TopicMapRepositoryIF system. 

Here's a recipe for how it could work:

1. Present the user with a list of TopicMapSourceIFs (retrieved from 
TopicMaps.getRepository().getSources()) that return true for supportsCreate().
2. When the user then selects a TopicMapSourceIF and uploads a file then call 
TopicMapSourceIF.createTopicMap(...) to create a new topic map. The method will 
return a new TopicMapReferenceIF.
3. Import the topic map input stream into the new TopicMapIF (retrieved by 
calling 
TopicMapReferenceIF.createStore(false).getTopicMap())
4. Commit the transaction (or call TopicMapReferenceIF.save() which is 
available of 
some of the non-rdbms topic map references. Ideally all TopicMapReferenceIFs 
should 
have this method implemented.)

This is how it could be implemented today. It is not particularly elegant, but 
it 
works. As you can see we may have to add support for the save() method on more 
TopicMapReferenceIFs (and possibly also add the save() method to the interface 
itself).

This approach has the downside that it will load the topic map into memory. 
Also, 
one may end up with partially loaded topic map if the import fails for some 
reason 
(non-rdbms topic maps only). The importer code will have to unregister the 
TopicMapReferenceIF if that happens.

I guess we also should support "replace" and "merge into" operations in 
addition to 
"create new" to be complete.

Original comment by indiapaleale@gmail.com on 25 Nov 2009 at 12:06

@GoogleCodeExporter
Copy link
Author

hmm, this sounds complicated, but actually makes sense.
I will look into it.

Original comment by thomas.n...@spaceapplications.com on 26 Nov 2009 at 11:23

@GoogleCodeExporter
Copy link
Author

I tried to use the TopicMapSourceIF, but could not get it to work yet:

LocatorIF base = new URILocator("file:///" + fileName);
TopicMapSourceIF source = repository.getSourceById(sourceID);
TopicMapReferenceIF ref = source.createTopicMap(fileName, 
base.getExternalForm());
TopicMapIF tm = ref.createStore(false).getTopicMap();
TopicMapImporterIF importer = null;

// get the right importer based on the            
if (fileName.endsWith(".xtm")) {
   importer = new XTMTopicMapReader(fileItem.getInputStream(), base);
} else if (fileName.endsWith(".ltm")) {
   importer = new LTMTopicMapReader(fileItem.getInputStream(), base);
} else if (fileName.endsWith(".ctm")) {
   importer = new CTMTopicMapReader(fileItem.getInputStream(), base);
}

importer.importInto(tm);
tm.getStore().commit();
ref.close();
repository.refresh();

The topic map gets imported, but it is not written to the file afterwards. 

It would also be preferable, if the different sources provide their own
Reader/Importer based on their configuration (e.g. an XTM Source should provide 
a XTM
Reader), and the appropriate source is chosen based on the extension and the 
ability
to create new maps.

Original comment by thomas.n...@spaceapplications.com on 2 Dec 2009 at 10:09

@GoogleCodeExporter
Copy link
Author

If the TopicReferenceIF is an instance of XTMTopicMapReference then you can 
call save
(). The other TopicMapReferenceIFs do not have this method, so you may want to 
add 
the save() method to them.

Original comment by indiapaleale@gmail.com on 2 Dec 2009 at 11:01

@GoogleCodeExporter
Copy link
Author

Also, I'm not really sure we want to let users store topic maps in any other 
format 
than XTM (1.0 or 2.0) on the server side. We should allow them to upload any 
format, 
but we may want to have it stored as XTM on the server. Any thoughts on this?

Original comment by indiapaleale@gmail.com on 2 Dec 2009 at 11:03

@GoogleCodeExporter
Copy link
Author

Actually, I can't really see why we would want to prevent people from storing 
topic 
maps in formats other than XTM. Personally, I don't think I would ever use 
anything 
else for Ontopoly-managed topic maps, but I can't think of any real reason to 
be 
restrictive.

Original comment by lar...@gmail.com on 2 Dec 2009 at 6:31

@GoogleCodeExporter
Copy link
Author

I can't really see much need for anything else than XTM myself, but others 
might 
think differently. At least we should verify (read: parse and validate) the 
document 
before we save it on disk on the server-side, to prevent someone from uploading 
executable binaries. The question then is whether we should save the uploaded 
document byte-by-byte as uploaded by the user, or if we should do an import and 
then 
an export to the file system? 

Original comment by indiapaleale@gmail.com on 3 Dec 2009 at 6:22

@GoogleCodeExporter
Copy link
Author

I like the idea, that the topic map is being validated, and then stored in a 
defined
format on the application server. Though there are some issues:

 - are we sure that the transformation from one format to another does not loose 
   information? Specifically I am thinking about ctm and its templates.

 - the upload in general heavily depends on the configuration, which makes it 
   error-prone, consider the following: one uploads a ltm file, and has 
   configured a LTMTopicMapSource, but the uploaded file is being converted to an 
   xtm, and is therefore not available, as the configured source only reads .ltm 
   files.

Original comment by thomas.n...@spaceapplications.com on 10 Dec 2009 at 10:46

@GoogleCodeExporter
Copy link
Author

Original comment by indiapaleale@gmail.com on 8 Oct 2010 at 9:18

  • Added labels: Type-Enhancement
  • Removed labels: Type-Defect

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant