Open jto888 opened 8 years ago
My opinion, and I stress the "my" in "my opinion" :), is that it depends on how often and in what context you expect your users to utilize the html
visualization, but in general I would say please don't do what you suggest. If you believe FaultTree
users will use in rmarkdown
, shiny
, or with any other htmlwidgets
, I would say the minimal dependencies from htmlwidgets
(see lines) are absolute musts that your users will want installed whenever working with html/js/css
. While inserting a multi-kb string of d3
seems like a good thing to do, doing this would mean that you only think your users will use FaultTree
completely independently and as its own separate html
page. The output is close to unworkable in any other situation. Say your user just wants to add a title or some explanatory text to a FaultTree
, doing so without the htmlwidgets
dependencies or other dependencies like XML
or xml2
is dang near impossible. I would say do your users a favor and show them how to use the dependencies to customize your beautiful FaultTree
output so that it can be used and shared the in useful ways.
In my experience, R newbies have no idea how DESCRIPTION
and dependencies work, and just do the install
and away they go. I have not run into many that will inspect the contents and dependencies of a package and shy away from using it.
If you would like help converting your FaultTree
, it is relatively easy, and I'll be glad to help.
Well, ok, after some more study I can see that localization of the D3 library is accomplished by copying the file from a known location in the R library to a position accessible to the html so that it can be sourced to the browser from the file system. Not quite as tidy as embedding entirely within the html, but it works. Maybe the CDN solution wasn't all that bad.
My seemingly obstinate position on dependencies is that they only work simply after a package has been released to CRAN. From other development repositories a prospective user has to worry about getting these dependencies themselves. There is a beauty in being able to pass a single windows binary .zip of a package and instructing a new user how to install it into either a fresh or old R installation from the local file system.
I haven't ruled out the multiple context advantages of htmlwidgets, I just may not want my developing packages to be there yet. I am further thinking of helping fill the great void between mywidget and reference to rather complex demonstrations. I think this can be done by exploring much simpler examples in a progressive fashion.
On 5/16/2016 9:26 AM, timelyportfolio wrote:
My opinion, and I stress the "my" in "my opinion" :), is that it depends on how often and in what context you expect your users to utilize the |html| visualization, but in general I would say please don't do what you suggest. If you believe |FaultTree| users will use in |rmarkdown|, |shiny|, or with any other |htmlwidgets|, I would say the minimal dependencies from |htmlwidgets| (see lines https://github.com/ramnathv/htmlwidgets/blob/master/DESCRIPTION#L20-L22) are absolute musts that your users will want installed whenever working with |html/js/css|. While inserting a multi-kb string of |d3| seems like a good thing to do, doing this would mean that you only think your users will use |FaultTree| completely independently and as its own separate |html| page. The output is close to unworkable in any other situation. Say your user jus t wants to add a title or some explanatory text to a |FaultTree|, doing so without the |htmlwidgets| dependencies or other dependencies like |XML| or |xml2| is dang near impossible. I would say do your users a favor and show them how to use the dependencies to customize your beautiful |FaultTree| output so that it can be used and shared the in useful ways.
In my experience, R newbies have no idea how |DESCRIPTION| and dependencies work, and just do the |install| and away they go. I have not run into many that will inspect the contents and dependencies of a package and shy away from using it.
— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/ramnathv/htmlwidgets/issues/205#issuecomment-219424192
It seems like R itself would rather quickly fall out of use if users actually had an objection to installing things from CRAN. You typically can't get to second base in R without installing dozens of packages from CRAN. I think if you try to create solutions that don't require dependencies then: (a) You are doomed to re-invent a bunch of things; and (b) You are solving a problem that AFIAK doesn't exist.
On Thu, May 19, 2016 at 11:02 AM, Jacob Ormerod notifications@github.com wrote:
Well, ok, after some more study I can see that localization of the D3 library is accomplished by copying the file from a known location in the R library to a position accessible to the html so that it can be sourced to the browser from the file system. Not quite as tidy as embedding entirely within the html, but it works. Maybe the CDN solution wasn't all that bad.
My seemingly obstinate position on dependencies is that they only work simply after a package has been released to CRAN. From other development repositories a prospective user has to worry about getting these dependencies themselves. There is a beauty in being able to pass a single windows binary .zip of a package and instructing a new user how to install it into either a fresh or old R installation from the local file system.
I haven't ruled out the multiple context advantages of htmlwidgets, I just may not want my developing packages to be there yet. I am further thinking of helping fill the great void between mywidget and reference to rather complex demonstrations. I think this can be done by exploring much simpler examples in a progressive fashion.
On 5/16/2016 9:26 AM, timelyportfolio wrote:
My opinion, and I stress the "my" in "my opinion" :), is that it depends on how often and in what context you expect your users to utilize the |html| visualization, but in general I would say please don't do what you suggest. If you believe |FaultTree| users will use in |rmarkdown|, |shiny|, or with any other |htmlwidgets|, I would say the minimal dependencies from |htmlwidgets| (see lines https://github.com/ramnathv/htmlwidgets/blob/master/DESCRIPTION#L20-L22)
are absolute musts that your users will want installed whenever working with |html/js/css|. While inserting a multi-kb string of |d3| seems like a good thing to do, doing this would mean that you only think your users will use |FaultTree| completely independently and as its own separate |html| page. The output is close to unworkable in any other situation. Say your user jus t wants to add a title or some explanatory text to a |FaultTree|, doing so without the |htmlwidgets| dependencies or other dependencies like |XML| or |xml2| is dang near impossible. I would say do your users a favor and show them how to use the dependencies to customize your beautiful |FaultTree| output so that it can be used and shared the in useful ways.
In my experience, R newbies have no idea how |DESCRIPTION| and dependencies work, and just do the |install| and away they go. I have not run into many that will inspect the contents and dependencies of a package and shy away from using it.
— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub < https://github.com/ramnathv/htmlwidgets/issues/205#issuecomment-219424192>
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/ramnathv/htmlwidgets/issues/205#issuecomment-220351944
Just so we're clear, this would be the experience for a new user if you took dependencies but didn't publish your package on CRAN:
install.packages("devtools")
devtools::install_github("jto888/FaultTree")
This is easier and more secure than emailing around zip files IMHO.
Devtools does have a lot of dependencies that need to be installed from CRAN but the user need not think about anything, just wait a few seconds.
I have elected to produce an add-on package (as a temporary development measure, only) to utilize htmlwidgets on my otherwise complete html solution. https://github.com/jto888/FaultTree.widget/
I may be slower than the average bear, but this was not a simple effort. I scanned sources of quite a few packages to learn the basics and at times became overwhelmed by some complexities used by others. Now that I am here, I would like to give back some assistance to others passing this way.
Here are some takeaways:
1) mywidget uses el.innerText = x.message; but this was not the kind of use I was expecting. It took me a while to recognize that x had to be a list object so that it could be converted to json for entry into the javascript. I noted the jQuery-like implementation in the htmlwidgets.js code, but i could not figure out if there might be other objects to be selectable on el. Could I have added my three lines of page styling as a string similarly? (rather than yaml out a .css stylesheet dependency for this)
2) In my original project I developed a custom json builder - because it was easier than trying to figure out how someone might have done something like this in another package like jsonlite. I think there may yet be a way for me to have used the json string directly into the x list without converting using jsonlite::fromJSON (so it can be converted back later). I found the jsonlite::fromJSON reference in the networkD3 webpage.
3) I may have sprained something in my brain learning enough to get the original D3 code to work, but I realize that there is much more study I have to do on the javascript side of things. The mywidget.js code uses a factory function item, that I did not see in any other package example. It took some exploration to realize that renderValue is the only mandatory js function. (With javascript you always want to work off of functioning code, staring at no output without a fallback position is nuts, so putting known functioning script inside of renderValue is a good starting point). I still need to explore splitting out an initialize function, and possibly whether some of the visualization functions should be separated out from being within renderValue. I suppose this becomes much more important when implementing reactive code with shiny.
Well, now I've had a chance to see the visualization in the RStudio viewer, and I am committed to learning to use RMarkdown. I need to get back to the technical side of FaultTree as there are several issues to resolve yet before a CRAN release. My goal from the start was to conform to R community expectations. The html solution I came up with seemed novel, but I needed to check on how others were implementing.
On 5/19/2016 11:06 AM, JJ Allaire wrote:
It seems like R itself would rather quickly fall out of use if users actually had an objection to installing things from CRAN. You typically can't get to second base in R without installing dozens of packages from CRAN. I think if you try to create solutions that don't require dependencies then: (a) You are doomed to re-invent a bunch of things; and (b) You are solving a problem that AFIAK doesn't exist.
On Thu, May 19, 2016 at 11:02 AM, Jacob Ormerod notifications@github.com wrote:
Well, ok, after some more study I can see that localization of the D3 library is accomplished by copying the file from a known location in the R library to a position accessible to the html so that it can be sourced to the browser from the file system. Not quite as tidy as embedding entirely within the html, but it works. Maybe the CDN solution wasn't all that bad.
My seemingly obstinate position on dependencies is that they only work simply after a package has been released to CRAN. From other development repositories a prospective user has to worry about getting these dependencies themselves. There is a beauty in being able to pass a single windows binary .zip of a package and instructing a new user how to install it into either a fresh or old R installation from the local file system.
I haven't ruled out the multiple context advantages of htmlwidgets, I just may not want my developing packages to be there yet. I am further thinking of helping fill the great void between mywidget and reference to rather complex demonstrations. I think this can be done by exploring much simpler examples in a progressive fashion.
On 5/16/2016 9:26 AM, timelyportfolio wrote:
My opinion, and I stress the "my" in "my opinion" :), is that it depends on how often and in what context you expect your users to utilize the |html| visualization, but in general I would say please don't do what you suggest. If you believe |FaultTree| users will use in |rmarkdown|, |shiny|, or with any other |htmlwidgets|, I would say the minimal dependencies from |htmlwidgets| (see lines
https://github.com/ramnathv/htmlwidgets/blob/master/DESCRIPTION#L20-L22)
are absolute musts that your users will want installed whenever working with |html/js/css|. While inserting a multi-kb string of |d3| seems like a good thing to do, doing this would mean that you only think your users will use |FaultTree| completely independently and as its own separate |html| page. The output is close to unworkable in any other situation. Say your user jus t wants to add a title or some explanatory text to a |FaultTree|, doing so without the |htmlwidgets| dependencies or other dependencies like |XML| or |xml2| is dang near impossible. I would say do your users a favor and show them how to use the dependencies to customize your beautiful |FaultTree| output so that it can be used and shared the in useful ways.
In my experience, R newbies have no idea how |DESCRIPTION| and dependencies work, and just do the |install| and away they go. I have not run into many that will inspect the contents and dependencies of a package and shy away from using it.
— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub <
https://github.com/ramnathv/htmlwidgets/issues/205#issuecomment-219424192>
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub
https://github.com/ramnathv/htmlwidgets/issues/205#issuecomment-220351944
— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/ramnathv/htmlwidgets/issues/205#issuecomment-220353276
I have a package under development at https://github.com/jto888/FaultTree. Here I have a custom json string builder function (ftree2json) so that that I can embed the required data into a d3 dependent script all as an R string that writes out the html for browser display. I have (temporarily?) resolved the problem of loading the d3 dependency by calling the cdn in my html (see ftree2html.R). I have looked over htmlwidgets, but hoping not to offend here, I was not inclined to add so many package dependencies to my R package. Currently I have none, which simplifies use for users new to R. I abandoned attempts to place the d3.v3.min.js in a string embedded in my package, but I wonder if you kind folks have some sort of mastery for this.