> ($ <selector> (css <attribute> <atom>))> > could wire an atom to a css (or
> other) dom attribute, by placing a> watcher on the atom and automatically
> updating the dom on change.Interesting idea!
On 1月7日, 午前5:02, kovas boguta <kovas.bog...@gmail.com> wrote:
> Great, looking forward to see what Chris has come up with. I'm not
> enough of a JS pro to be the one doing this.
>
> I think what matters is the design. Jquery is an accessible
> implementation target, but if someone wants to retarget the design to
> gclosure, thats fine too (just more work than is need to get started)
>
> On the design front, there is a fundamental difference between a DSL
> and the "standalone generic function" style. So I want to point this
> out and advocate for other design decisions I made, to stir the pot
> here.
>
> Generic function style treats dom manipulations as stand-alone functions, like
> dom/append, events/on, etc
>
> The theoretical benefit is 1) you can use generic clojure functions to
> manipulate these datastructures, and 2) you can insert your own
> functions into the call tree at any point, like
>
> (dom/append (events/on (your-function (dom/query X)) Y) Z)
>
> However the set of useful dom manipulations is a well-understood, and
> is closed set (dom in, dom out). So there is not much benefit in this.
>
> And in fact it tends of obfuscate the code, due to the namespace
> prefixing, and also because the dom manipulation sequence is not
> clearly set apart from other code. You have to remember how
> clojure-like a given return value is.
>
> Better to have a clear sequence like
>
> ($ X (click Y) (append Z))
>
> This also has the additional advantage that $ can do a variety of
> important tasks, including taking care that "this" is properly
> handled. In my library ($ :this) is its javascript equivalent at the
> current evaluation context, so handling events is easy.
>
> There are other extensions worth considering. Things like
>
> ($ <selector> (css <attribute> <atom>))
>
> could wire an atom to a css (or other) dom attribute, by placing a
> watcher on the atom and automatically updating the dom on change.
>
> In general, a high-level cljs dom manipulation framework can consume
> atoms (in addition to values) in a variety of places, thus creating
> auto-updating views.
>
> We can also leverage clojure maps to aggregate attribute-value pairs, like
>
> ($ <selector> (css {<a1> <v1> <a2> <v2}))
>
> Finally, I'm just gonna reiterate that I am a major fan of allowing
> <selector> to be an arbitrary hiccup structure, with the extension
> that dom/jquery objects are allowed as entries in the hiccup vector.
> This makes composing things easy.
>
>
>
>
>
>
>
> On Fri, Jan 6, 2012 at 1:37 PM, Chris Granger <ibdk...@gmail.com> wrote:
> > So there's pinot, but I've come to a relatively similar conclusion to
> > Kovas that wrapping the goog libs aren't really the way to go. For
> > one, I was basically replicating aspects of jQuery (like event
> > delegation).
>
> > Recently I started on doing some thing that makes jQuery play in the
> > Clojure world really nicely. I'll get this onto github soon.
>
> > Cheers,
> > Chris.
>
> > On Jan 6, 5:18 pm, kovas boguta <kovas.bog...@gmail.com> wrote:
> >> Yes.
>
> >> I've created a jquery wrapper conveniently called cljs-jquery ,
> >> however there is no documentation, tests, or general housekeeping yet
> >> so haven't announced it. If you are
> >> brave,https://github.com/kovasb/cljs-jquery
>
> >> Previous libraries have followed the lead of the initial Clojurescript
> >> examples, and tried to wrap gclosure to make it more
> >> clojure-idiomatic.
>
> >> I think this whole approach is a mistake.
>
> >> This is not a generic data processing problem, so we shouldn't be
> >> converting the dom into verbose generic clojure structures with
> >> namespace prefixes everywhere.
>
> >> DOM manipulation is ideally suited to a DSL. JQuery already defines
> >> the primitives, and provides the implementation. Lets just wrap it.
>
> >> The idea of my library is trivial. Just have a macro that expands into
> >> a jquery call chain:
>
> >> $(selector).f(a,b).g(c,d)
> >> is represented by
> >> ($ selector (f a b) (g c d))
>
> >> (note that f and g don't need buzz-killing namespace prefixes)
>
> >> For bonus points, selector can be a hiccup structure (or a hiccup
> >> structure with embedded dom objects) which ends up saving a huge
> >> amount of code when creating new elements.
>
> >> In general this is far more concise and easier to code than any other
> >> approach I've seen thus far.
>
> >> On Fri, Jan 6, 2012 at 3:16 AM, Shantanu Kumar <kumar.shant...@gmail.com>
> >> wrote:
> >> > Is anybody working on a DOM-manipulation library for ClojureScript?
>
> >> > There are several JavaScript libraries that can probably be wrapped,
> >> > but a ClojureScript library should be great. I noticed a short
> >> > comparative list of jQuery basic operations vs JavaScript equivalent
> >> > that looks interesting:http://sharedfil.es/js-48hIfQE4XK.html
>
> >> > Shantanu
>
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> > Groups "Clojure" group.
> >> > To post to this group, send email to clojure@googlegroups.com
> >> > Note that posts from new members are moderated - please be patient with
> >> > your first post.
> >> > To unsubscribe from this group, send email to
> >> > clojure+unsubscr...@googlegroups.com
> >> > For more options, visit this group at
> >> >http://groups.google.com/group/clojure?hl=en
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
