-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enquiry: Separate out hiccup rendering from helper functions ?? #75
Comments
I wholeheartedly agree. I envision the hiccup ecosystem to look something like this:
For purposes of legacy support and convenience, hiccup would continue to exist but would merely pull in hiccup-gen and hiccup-compiler, and define hiccup.middleware. @weavejester, what do you think? I could take a stab at refactoring the current repo into two sub-projects (using lein-sub) and wire in ClojureScript compilation, with crossover support or cljx. |
This seems a reasonable suggestion. Somehow the original issue got lost in my inbox, or never arrived. Not sure I'm a fan of the name "hiccup-gen" though! |
How about hiccup-tags or hiccup-elems? Aside from that though, any concerns or comments on the implementation suggestion above? If not, I'll get to work refctoring the repo on a feature branch and will submit a pull request later. |
@weavejester, could you take a peek at this branch I'm working on to see if this is going in a direction you like? I pulled out all the tag generation into a sub-project. I had to shuffle around some fns and rewrite some of the test, but the original functionality is essentially intact, with all tests both in the sub-project and the main project (after Let me know what you think. |
I think I'd be inclined to have two sub-projects, |
Yup, thinking the same thing. So far I've separated out Also, I'm tempted to give |
@weavejester, I've now separated Before I proceed, would you like to take a look at the code so far? The two areas that could definitely use some feedback are |
Okay, the cljs port of |
You might want to look at the new ClojureScript syntax for including macros: (:require [hiccup.def :refer :all :include-macros true]) This would allow you to remove the I also wonder whether it wouldn't be better to restrict the the hiccup-compiler to be just the compiler. |
Oh, thanks. I wasn't aware of In this particular case, however, I have to write two different implementations of the As for |
Can't the Regarding the hiccup-compiler, why not have a dynamic var that contains the compiler? For example: (set! hiccup.core/*compiler* hiccup.clojure/compiler) Then the |
I've been trying to get this to work and I have to admit my macro-fu is failing me. I could theoretically use Edit: |
Let's divide this up into two problems. The first is how to add the There's a function called (defmacro defelem [name & fdecl]
(let [[name fdecl] (name-with-attributes name fdecl)]
`(def ~name (wrap-attrs (fn ~@fdecl))))) Next, we want a mechanism to alter the arglist metadata. We could do that by parsing (defn ^:no-doc update-elem-arglists! [var-name]
#+clj (alter-meta! (ns-resolve *ns* var-name) update-in [:arglists] update-arglists)) In Clojure, we update the argument list, but in ClojureScript, the function does nothing. Putting it all together: (defmacro defelem [name & fdecl]
(let [[name fdecl] (name-with-attributes name fdecl)]
`(do (def ~name (wrap-attrs (fn ~@fdecl)))
(update-elem-arglists! ~name)))) |
Thanks, I'll give that a go later this week. |
Hmm, this approach still won't work since |
Oh, that's pretty annoying. I can't think of a clean solution, barring using a variant on your def/gensym idea, which seems a little problematic in Clojure, or copying the private Let's shelve this for now. It's not something important enough to stop a merge, just something that needs to be sorted out eventually. |
Yeah… I'll mark it with a "TODO" for someone smarter than myself to figure out. Do you see any objections to the current codebase or should I go about doing some clean-up, merging in a master, and sending a pull request? |
Aside from factoring out the hiccup.core/html macro from the compiler project? |
Oh, right, meant to comment on that. Is there a reason why you'd like to have the HTML string generation macros (currently in |
That's a reasonable point. My reasoning was that they don't add much additional code, but provide a common function for transforming Hiccup syntax into something else. I don't know of any Hiccup-inspired library that doesn't have some equivalent to That said, we don't need to do it all in one pull request. The current work can be merged in, or at least merged into a branch. |
I like the idea of separating the default compiler from some of the shared compiler functionality like tag normalization. Let me play with that a bit and see what makes sense. Regarding the |
I didn't mean separate out any of the internals of the compiler, just the public interface. The (html & hiccup-forms)
(html option-map & hiccup-forms) To my mind that's more than generic enough to factor out as a common interface. |
Fair enough. The macros don't do much, though. They only wrap the fns defined under |
Oh, I think I misunderstood what you meant by the macro refactoring. Did you mean to rewrite the |
Right, that's pretty much exactly what I meant. |
I've been playing with the compiler-fn redefinition and it feels rather brittle, since For the sake of simplicity, I would opt for letting each compiler lib define their own |
I managed to solve the |
That works, then? Interesting; I had assumed the Apologies for the delayed response. I've have a lot on my plate recently. |
Suggesting we close this thread in favor of pull request #99. |
Closing this since the upcoming 2.0 release will address the issue. |
This is not so much an issue as an enquiry.
I use both hiccup and crate and now dommy and it occured to me that hiccup is doing two distinct functions today. (and Crate replicates some this).
Do you think it might be worth considering splitting the two into two independent libraries?
The text was updated successfully, but these errors were encountered: