A few suggestions

User 3d3f3767a2

14-01-2013 13:22:34

Hi, just a few quick suggestions from having tried out Marvin JS.


First, the triangle.gif link in the JS source is currently a relative path. Is it possible to turn the use of this image into a style class instead of referencing it directly in the JS? I had to go through the source and replace all instances of it with "/images/triangle.gif".


On that topic, perhaps all of the marvin assets should be kept in a "marvinjs" directory or something. That way all assets can be referenced from "/marvinjs/images/blah.gif" or "/marvin/javascripts/gui.nocache.js". If you did do it this way, I would love to write a Rails gem for it that loads all the assets into the asset pipeline so that all a Rails developer has to do is include a single line in their code (see https://github.com/bokmann/font-awesome-rails for example) to add Marvin to their app.


Another issue I have is conflicts with CSS frameworks. For example, using YUI, which adds defaults on tables, margins, etc., the Marvin is pretty much unusable. It would be good to maybe reset all the elements you use to sane default values (removing borders from td, th, etc.). This way Marvin JS would look consistent. In that vein, I am currently struggling to set reasonable width on the editor. If I wrap the code in a div and set a width on it, it doesn't work.


Anyways, it has a ways to go as I'm sure you know, but it's an excellent start! I'm looking forward to the tie in with JChem web services. I understand you are making a lot of changes to the web services? Is the current API changing?


Keep up the wonderful work!


Craig

ChemAxon 7c2d26e5cf

17-01-2013 15:04:08

Hi Crag,


I admit that trinangle.gif is the achiles heel of the current Marvin4JS. That's why we elliminate it in the next version. In the new version, the button decoratation is solved with pure CSS code without any GIF.


We recommend our users to embed the editor into iframe not in div. The editor.html is promoted to insert Marvin4JS editor into web pages (with iframe). It includes the proper references.


We do not recommend the usage of the div since the CSS of the editor can be conflict with the other CSS definitions on the hosted page. As I see, you have run into this issue.


We can not predict the hosted page design: there is no guaranty that the editor looks fine if you merge its style with the style of the hosted page. 


The references to external resources can be broken if the CSS of the editor is referred from other place than editor.html (since URL are relative to the HTML file, not the CSS). That's why we do not recommend to paste editor.html content into the hosted page directly.


Anyway, we have solved the resizing issue (component should follow the dimension of iframe as the iframe size is modified). Next release will include this feature.


The current JS code is splitted into several files to be able to load required resources on-demand. So we prefer asynchronous loading of resources. But we consider to also deploy the code as a single asset in the future.


Currently, we do not plan to provide custom design for the editor. We focus on creating a neutral design for the editor that is acceptable in most environment.


About the API: I do not think that significant changing can be expected in the usage of the API till the first release.


But we will provide ability to define the locations of webservices for remote calculations. 


Regards,


Tamas

User 3d3f3767a2

06-02-2013 21:00:28

Thanks for getting back to me, I totally missed the iframe part of the documentation!


Looking forward to seeing the integration with the web services. Would love to see SMILES/InChI import at some point too.


Thanks,


Craig