Hi Murtaza, thanks for your interest! Responses below. Alan 1. Why not use hiccup data structure for representing DOM, instead of the > custom fns and macros. This provides several advantages where your DOM is > just data and you can manipulate it like data. > The hlisp part of Hoplon - the compiler bit that converts HTML to ClojureScript - was designed and implemented specifically to avoid having to do this. It's our opinion (and experience) that admission of the DOM as a data structure instead of a piece of the program introduces tremendous complexity. This data structure must be explicitly interpreted, evaluated, and updated in complicated ways that tend to couple tightly to both overall state logic and DOM quirks. That said, Hoplon markup can be manipulated as data the way any other Lisp program sanely can - via hygienic macros. Also, the semantics we apply to HTML to compile it to ClojureScript extend to other representations. For instance, I'm currently finishing up boot tasks for compiling HAML and Slim markup to ClojureScript programs. A hiccup task would be just as straightforward, but IMO pointless.
2. The destructing and looping used within the DOM forms is custom. Why > cant we have regular clojure all the way ? Introduction of a another syntax > for templating is not very appealing. So a regular 'map' or 'for' could be > used instead of 'loop-tpl' > I'm sympathetic to your concern here, but loop-tpl is an entirely different animal than map or for and unfortunately they don't line up. The main difference between loop-tpl and map/for is that loop-tpl is a macro that statically allocates DOM elements to deposit the elements it loops over into - it is not a runtime construct. For more on loop-tpl please see the end of "Task 6" on http://hoplon.io/#/getting-started/. Plus, hey, you're already ClojureScripting - how bad can just a little more weirdness be? ;-) 3. String interpolation for the bindings - '~{x}' . Cant we use something > more idiomatic, either the var itself or atleast a symbol :x ? > If interpolation just used var symbols, we'd need to analyze the global environment and look for a possible var match for every word we found in the string - a complicated process. If we used :keywords, we'd have to escape them in order to write the string \:keyword - highly unintuitive IMO. ~{} is odd enough to probably not occur in a string, and follows how interpolation works in e.g. Ruby (which uses #{}). Also, ClojureScript's js* compiler macro uses ~{} to achieve kinda the same thing. > 4. It will also be helpful to have a leiningen example for the project. > Nothing against boot, however it will be easy to get started, and also > IDE's are already configured to work with project.clj > A Leiningen plugin is unlikely, but we're open to improving the documentation, friendliness of, and tool support around boot. For more on Why Boot, please see http://www.reddit.com/r/Clojure/comments/1t6wgs/hoplon_a_simpler_way_to_program_the_web/ce5zntf > > > On Friday, December 20, 2013 3:40:41 AM UTC+5:30, James Reeves wrote: >> >> Thank you for taking the time to write such a detailed explanation. That >> clears up my understanding of the library considerably. >> >> - James >> >> >> On 19 December 2013 03:45, Micha Niskin <micha....@gmail.com> wrote: >> >>> Ah, yes. There are some gaps in the docs that need to be fixed. To >>> answer your questions: >>> >>> >>> 1. The main thing that Hoplon does is unify the DOM and the dynamic >>> environment (the JS environment). This makes it possible to refer to >>> things >>> from the dynamic environment in your markup. Normally you can reference >>> things in the DOM from JavaScript, but not the other way around. So in a >>> unified environment that includes both JavaScript and the DOM there >>> needs >>> to be a way to develop both of them in the same page. A Hoplon page has >>> 3 >>> parts: the page declaration, a number of optional top-level forms, and >>> finally the DOM markup. So yes, the Hoplon compiler selects the last >>> expression in the file as the DOM markup. >>> 2. The primitive HTML5 elements (div, span, etc.) are, in fact >>> ClojureScript functions in the tailrecursion.hoplon namespace. These >>> functions return new DOM elements of the appropriate type. However, the >>> Element type is extended to implement the IFn protocol such that they >>> maintain the HTML semantic. That is, function application means append >>> child / set attribute. So yes, div and span etc. are functions, but they >>> return DOM elements that implement IFn, so they return functions, in a >>> way, >>> too. >>> 3. Everything is generated on the fly, pretty much. The entire >>> document is replaced with the result of evaluating the DOM markup when >>> the >>> page loads. In other words, when the page loads the last expression in >>> the >>> source file is evaluated in the browser, and document is replaced with >>> the >>> result. Since the DOM markup is just a ClojureScript expression that is >>> evaluated as ClojureScript, you can create your own custom tags. All you >>> have to do is define functions that abide by the HTML semantic. There >>> are >>> examples of this in the "Getting Started" page, especially the "Creating >>> a >>> tabs abstraction" section. >>> 4. Sorry, I should have put a link in the docs there to >>> Javelin<http://github.com/tailrecursion/javelin>, >>> the dataflow library we use for the cells. That page explains in detail, >>> but the basic premise is that there are two kinds of cells in >>> spreadsheets, >>> input cells that you update manually, and formula cells that update >>> themselves reactively according to a formula that might refer to other >>> cells. So defc is equivalent to def and cell, and that defines an input >>> cell. Likewise, defc= is equivalent to def and cell=, and that defines a >>> formula cell. >>> 5. All cells, both input cells and formula cells, contain values. >>> The difference is in how those values are updated. In order to obtain >>> the >>> value contained in any cell you may dereference the cell. So both types >>> of >>> cell can be dereferenced like atoms. However, only input cells can be >>> updated using swap! or reset!. Formula cells will update themselves >>> automatically, and it's an error to try to do it directly using those >>> functions. >>> 6. The difference between a cell and an atom with watchers attached >>> is that cells guarantee consistency. That is to say that the evaluation >>> mechanism ensures that a formula cell is never updated until all of the >>> cells it depends on have been updated, that the formula is evaluated at >>> most one time, and that the cell's formula is evaluated only when the >>> value >>> of a cell it depends on has changed. A cool property here is that the >>> entire graph of cells updates atomically and consistently, even though >>> the >>> individual cells are updating themselves one at a time. The consistency >>> guarantee ensures that each cell sees the world as if it updates >>> atomically; no cell can ever see other cells in a half-evaluated state; >>> each cell acts as if it were the last cell to update. You can think of >>> the >>> entire graph as a single value. >>> >>> >>> >>> On Wednesday, December 18, 2013 7:50:58 PM UTC-5, James Reeves wrote: >>> >>>> I wasn't expecting an overview of the syntax to be under "Getting >>>> Started". The documentation there makes things clearer, but I still have a >>>> few questions: >>>> >>>> 1. What differentiates the top-level page definition from DOM objects >>>> returned from functions? Is the compiler just looking for the last >>>> expression in the source file? >>>> 2. Do the HTML forms (div, span, etc.) act like functions, or more like >>>> macros? >>>> 3. Are the HTML forms generated on the fly, or is there a fixed list of >>>> tags available? >>>> 4. Is defc equivalent to def and cell? And defc= equivalent to def and >>>> cell=? >>>> 5. What's the difference between cell and cell=? Is one like an atom, >>>> and the other like a reactive function? >>>> 6. What's the difference between a cell an an atom? >>>> >>>> - James >>>> >>>> >>>> On 18 December 2013 21:02, Micha Niskin <micha....@gmail.com> wrote: >>>> >>>>> There is a section in the "Getting Started" page, titled "Sexp Markup >>>>> Syntax" that attempts to explain the syntax. What needs to be improved >>>>> there? >>>>> >>>>> >>>>> On Wednesday, December 18, 2013 3:56:02 PM UTC-5, James Reeves wrote: >>>>> >>>>>> It looks interesting, but it really needs an overview of the syntax. >>>>>> The purpose of the examples is clear, but the mechanism is a mystery. >>>>>> >>>>>> - James >>>>>> >>>>>> >>>>>> On 18 December 2013 20:05, Micha Niskin <micha....@gmail.com> wrote: >>>>>> >>>>>>> Documentation is here: http://hoplon.io >>>>>>> >>>>>>> We continue to add documentation all the time. Serverside stuff not >>>>>>> yet documented yet. Feedback welcomed! >>>>>>> >>>>>>> -- Micha Niskin and Alan Dipert >>>>>>> >>>>>>> -- >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Clojure" group. >>>>>>> To post to this group, send email to clo...@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+u...@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 unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to clojure+u...@googlegroups.com. >>>>>>> >>>>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>>>> >>>>>> >>>>>> >>>> >> -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
