Fork me on GitHub

How do I prevent to make a namespace for xmlns here?

(prn (-> (xml/sexp-as-element [:feed {:xmlns ""}
                               [:title "REPL adventures"]
                               [:link {:href "" :rel "self"}]
                               [:link {:href ""}]])


"<?xml version=\"1.0\" encoding=\"UTF-8\"?><feed xmlns:a=\"\"><title>REPL adventures</title><link href=\"\" rel=\"self\"/><link href=\"\"/></feed>"


I guess it's just not supported


(xml/alias-uri 'atom "")

(prn (-> (xml/sexp-as-element [::atom/feed
                               [::atom/title "REPL adventures"]
                               [::atom/link {:href "" :rel "self"}]
                               [::atom/link {:href ""}]])


XML validator online: > In addition, interoperability with the widest range of feed readers could be improved by implementing the following recommendations. •, column 38: Avoid Namespace Prefix: a [] • <?xml version="1.0" encoding="UTF-8"?><a:feed xmlns:a=" ... >

Alex Miller (Clojure team)12:10:51

You can set a default namespace at the root


That worked, thanks!


I watched last night and he mentioned how the system he was presenting (component) was an updated version of a talk he did the year before (clojure in the large). This video was 7 years ago and I'm wondering if the methodology for constructing apps has evolved or changed since. Is component as he described in the talk still current and viable? Have any other methods come out since?


This was discussed in some depth in #off-topic recently. Let me see if I can find a link...


Somewhere around here, is a discussion about how well Component has held up, but also trade-offs when compared to alternatives:


Thank you, I just read through all that-a lot to take in. I apologize if this should’ve been posted in that channel. So it seems like the discussion is mainly between Component, Integrant, Mount, and emccue’s “just hand write it all”. I’ll need to do a bit more research thanks for pointing me to that link.

👍 1

A key takeaway for me from that discussion was that people (with much larger code bases) continue to have a lot of success with "plain ol'" Component.


Gotchya, yeah that was a little hard to decipher.


It may be on a next/previous page from there

🙌 1

@U01JYKT6ENL glad to be a contender


lol @U3JH98J4R for my small personal app, your way wins until it grows and I understand the context of the problems that those libraries solve


What are people doing in terms of communication between components, especially bidirectionally? Any nice codebases with core.async or manifold as an event bus?


Not the same Component 🙂


@U01JYKT6ENL At work, we have about 120K lines of Clojure and we rely heavily on Component so it's definitely current and useful in large projects.


That's good to hear, thank you Sean.


same in our similarly-sized monorepo. I honestly don't think component's design is especially elegant, and have thought of many ways i'd like to do it "better," but on the other hand I barely think about component when i'm solving problems in our codebase.


it's very much something you only touch a lot when initially setting up a project IME, after that it disappears. and that's the kind of lib I like

🙌 1

Not sure if @U04V70XH6 was replying to me but I did mean Component/Integrant. We have apps with somewhat stateful Components that need to raise events back and forth asynchronously. The way the component graphs are constructed is always a bit bottom up, so you end up with components wrapping channels or callbacks just to meditate between other components and sometimes it can feel inelegant. Was just wondering if others have faced the same (probably less of a concern in web apps where your UI is less stateful).

Ben Sless15:10:09

@UTF99QP7V that sounds like you might need a shared event bus with pub/sub semantics on your application

Ben Sless15:10:26

Which is an interesting use case I haven't seen yet


Not sure if it helps @UTF99QP7V but quick plug for a quite different approach that might work better for gnarly graphs mostly just keeps track of what is running and how to shut it down rather than any kind architectural pattern or init system, quite flexible and dynamic. I built it to deal with REPL experience when working on app that was spinning up lots of stateful things at runtime rather than init only (for better or worse)


Oh interesting, will definitely look into this, thanks.


@UTF99QP7V We have a pub/sub Component which is based around Redis that other components depend on if they need that sort of thing -- I guess I misunderstood your question because having an "event bus" of some sort is just another Component with a start / stop lifecycle that other Components depend on as needed so I don't tend to think of it specifically as "Components communicating with each other".


Hey does anyone use clj-time with next.jdbc? I was wondering how to get auto coerce for datetime fields. I tried requiring but it still produces java.sql.Timestamp (postgresql)


@US9EF3BGU No one should be using clj-time at this point.


Unless you're still stuck on Java 7 🙂


whats the alternative? I mean still java.sql.Timestamp is more of problem than any particular datetime implementation


As the clj-time README says: use Java Time which is built into Java and it also recommends some wrappers if you really need them.


But I think you're misunderstanding what does.


It provides automated conversions from Java Time to SQL date/time types and it provides a way to enable automated conversions from SQL date/time types to Java Time types -- but you have to explicitly choose which conversions you want.


Because there are several options.


The default is to use the SQL date/time types (as you experienced) but you can call read-as-instant (which will produce java.time.Instant) or read-as-local (which will produce java.time.LocalDateTime). Which is what the docstrings say.


Does that help? (advice from the maintainer of both clj-time and next.jdbc 🙂 ).


thanks, will explore 🙂