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.nis...@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.
