Open duplode opened 10 years ago
I have to admit that I don't quite understand the details of the issue. It seems to be about code in a <script>
which is required to be loaded before a <div class="autocomplete">
elements can be added?
For the moment, the recommended solution for including external JS libraries is to write a custom HTML file and use the tpCustomHTML
configuration option. (Unfortunately, issue #60 makes custom HTML less useful than it should be at the moment.)
However, I'm happy to add an addScriptElement
function similar to the existing addStyleSheet
at some point.
More generally, in every GUI framework, there is always the tension between creating elements programmatically or loading them from a configuration file (a custom HTML file). I'd like to support both, but the implementation is currently very sloppy.
I have to admit that I don't quite understand the details of the issue. It seems to be about code in a >
<script>
which is required to be loaded before a<div class="autocomplete">
elements can be > >added?
Yup, in essence that's it. A jQuery Autocomplete widget is initialized with $('#some-element').autocomplete()
, which is trivially translated to Threepenny FFI calls to something like element someElement # autocompleteInit
; however, that only works if the jQuery UI script was loaded by the time autocompleteInit
is called. Any addScriptElement
function would ideally be work around that issue, through either synchronous loading or Haskell-to-JS callbacks.
As for the tension you mention, it also appears in another level when we consider how to setup a JavaScript bindings library. On the one hand, it would be good to make life easier for the library user by avoiding the need to use tpCustomHTML
and the addition of a data dependency to client code - in particular, one that core Threepenny will rely on. On the other hand, bundling any sizable JavaScript library in a cabal package would likely be very inconvenient, to the point it would become easier for everyone involved to just let users package the JavaScript however they feel best and use tpCustomHTML
for configuration.
Hello again! It's been a while, but I finally got back to playing with Threepenny. My latest experiment involved bindings to a small subset of jQuery UI. While it works very well, the trickery involved was, ahem, interesting. Quoting one of my commit messages:
How sane do you think this approach is, and how long is it likely to survive given the evolution of the API? Also, I noticed that improvements to the FFI are being prepared for 0.5, including support for exporting Haskell callbacks. Will they be applicable to this scenario - for instance, by loading a library with jQuery's
getScript
while passing the rest of the Haskell initialization as a callback?