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
