Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Matthew Pocock
    @drdozer
    hum ... I'm not seeing a <script>widget in bindings.HTML -- where do I look?
    Matthew Pocock
    @drdozer
    I've tried wrapping it in raw but I think the scripts aren't being run
    Marius B. Kotsbak
    @mkotsbak
    What are you trying to do?
    Matthew Pocock
    @drdozer
    hook up the ace editor - it means registering callbacks and things
    I have an ugly hack where I load all the js libraries in the page template and then wire things in ready()
    but it means that the js libs for ace are now leaking into all my pages
    Marius B. Kotsbak
    @mkotsbak
    Load it from webjars and it will be in jsdeps js file
    Load that in main html file
    Marius B. Kotsbak
    @mkotsbak
    New Widok like framework with batteries included: http://udash.io
    Matthew Pocock
    @drdozer
    So say I have a Buffer[Foo] and I have a widok widget factory method Foo => Widget. How do I make a div which manages its children acording to the content of that buffer? Do I just map over it and se that as the content of the div?
    Marius B. Kotsbak
    @mkotsbak
    I think so. Have you looked at the todo example? I think it does something like that.
    Matthew Pocock
    @drdozer
    Cheers, that works just fine. So my next question is:
    I can do div(myBuffer map (foo => Widget)) and the content of the div tracks the widgets I make from the elements of the buffer
    can I do d3-like operations where I capture widget creation and destruction events and hook in an action?
    so for example, whenever the div is going to evict a child that no longer corresponds to an element of myBuffer, trigger a fade effect prior to it being actually removed
    Marius B. Kotsbak
    @mkotsbak
    No, I don't think there is anything like that yet: widok/widok#29
    What you could do is to find the dom elements and attach callbacks to them directly to trigger events.
    Marius B. Kotsbak
    @mkotsbak
    Patches would be nice btw :)
    Matthew Pocock
    @drdozer
    I'm thinking perhaps the low level api would be to transform a steam or deltas with a DSL for composing delayed actions.
    Marius B. Kotsbak
    @mkotsbak
    I don't know the details here. Maybe @tindzk could provide some input if you want to try to implement something.
    Matthew Pocock
    @drdozer
    I would like to have a go at an implementation but I could do with a bit of help.
    Tim Nieradzik
    @tindzk
    @drdozer We could add script to bindings.HTML. We probably hadn't added it in the first place because usually JavaScript dependencies are included in the HTML file.
    Would the jsdeps approach suggested by @mkotsbak work for you?
    I've responded to your other questions on the GitHub issue.
    keenz
    @kindlychung
    How does widok compare to udash? https://github.com/UdashFramework/udash-core
    Tim Nieradzik
    @tindzk
    Udash looks really nice. It's written in a modular way and relies on ScalaTags for rendering.
    Widok's DSL is slightly more succinct. Judging from Udash's TodoMVC example you may still need to use jQuery to manipulate nodes.
    keenz
    @kindlychung
    What would be the advantages/disadvantages for each of them?
    @tindzk
    Marius B. Kotsbak
    @mkotsbak
    Udash more batteries included (rpc etc)? While widok syntax maybe a bit cleaner?
    Tim Nieradzik
    @tindzk
    @kindlychung Widok is more lightweight in its design. For example, it has fewer external dependencies and there are some features in Udash that it is lacking (for example RPC or I18N)
    @kindlychung I would also recommend you to have a look at MetaWeb which is a complete redesign of Widok. The goal is to address some conceptual issues and have a smaller core.
    Matthew Pocock
    @drdozer
    so far I have a single page widok application -- how do I alter my code/build/html to convert to a site with mulptiple, independent widok pages?
    Marius B. Kotsbak
    @mkotsbak
    @drdozer still a SPA? Then like this?: http://widok.github.io/manual/widok-v0.2.2.html#multi-page-applications
    Matthew Pocock
    @drdozer
    OK, so this is in my fooJS sbt module?
    Marius B. Kotsbak
    @mkotsbak
    @tindzk time for a new release?
    Nothing new in sbt if you don't mind having all code available for all pages
    Matthew Pocock
    @drdozer
    is there a worked example of this? I'm running the server on akka-http, and I'm not quite seeing how the client-side routes marry up to the resources that I serve up.
    Marius B. Kotsbak
    @mkotsbak
    Else you probably need to make multiple submodules with different main classes
    Here is a routing example: https://github.com/widok/skeleton/blob/master/js/src/main/scala/io/widok/client/Application.scala This is a client side thing, nothing to do with server side routes
    Matthew Pocock
    @drdozer
    I want to have the URLs /sandpit.html and /tutorial.html work, along with some static content at /.
    Matthew Pocock
    @drdozer
    oh ... ok - I've fired up the skeleton application, and all the routing stuff is after the fragment in the URL
    Marius B. Kotsbak
    @mkotsbak
    Yes, I guess all is behind a #
    Why can't you do it like that?
    Matthew Pocock
    @drdozer
    that isn't going to make it through our group URL policy -- yes we do actually have such a thing
    Marius B. Kotsbak
    @mkotsbak
    Hehe ok, then it will be separate physical pages
    Maybe all could point to the same application, and get the widok router to read physical page urls too
    Matthew Pocock
    @drdozer
    yeah - but does that mean making separate widok client projects for each page? and then ending up with a whole bunch of large, nearly-identical javascript libraries? or would I end up with a per-application bla-launcher.js that is relatively small?
    Marius B. Kotsbak
    @mkotsbak
    If you want to optimize the size of the generated js for each page it has to be done like that. Each page might not use all of the code, so that the closure compiler could skip some part of it
    If size does not matter, I would say rather point to the exact same .js file (which could be cached by the client between each page)