Re: Clojure(Script) web apps in 2018
I'm a massive fan of integrant on which duct is based. In my mind it takes Stuart Sierrra's component to its logical conclusion, which is essentially treating the system as EDN configuration. I think most moderate/large component projects tend to want to convert systems into config. Essentially integrant is what you get when you decide to create component but config first. Unlike mount, I think it is much more cleanly decomplected... i.e no problematic singletons. In many ways I wish duct wasn't a web project at all, and was just a generic module system; a thin layer on integrant, for configuring components, and that the web framework was a separate project of duct components altogether. When you look at it closely though, you realise it pretty much *is* this; it's essentially just a module system with a web framework as an exemplar. However, there are perhaps one or two places where this isn't entirely true. Duct modules can be a bit confusing, and are I think a litlte too powerful; but overall I'd recomend it. R. On Sun, 23 Sep 2018 at 22:07, Nathan Fisher wrote: > Duct looks interesting. > > I found luminous useful for when I first started with web dev in clojure > but started running against its project layout. > On Sun, Sep 23, 2018 at 15:17, Rick Moynihan > wrote: > >> I really quite like weavejester's duct, because it's essentially a >> familiar / standard ring app, but with integrant based configuration >> modules, and sensible defaults. It's not perfect though, e.g. ataraxy is >> somewhat under-developed, so I'd look at swapping it out for bidi or >> something more mature. >> >> https://github.com/duct-framework/duct >> >> I've built a fair few luminus apps over the years and find it hard to >> love because of mount; and I strongly feel the templates default layout is >> organised in the wrong way. It's hard to argue that it's not well >> documented, and quick to start with though, and it's pretty easy to use >> integrant or component and delete the src directory and pick a more >> sensible layout (I recomend structuring by feature/route, rather than by >> the incidental complexity of a webapp). >> >> Ultimately all the main options mentioned work quite well, so it depends >> on what you need and like etc. You might also consider backing it with >> lacinia as a graphql backend. lacinia is pretty neat. >> >> >> R. >> >> On Mon, 17 Sep 2018 at 10:27, Tom Locke wrote: >> >>> Hi all, >>> >>> I'm a reasonably experienced ClojureScript developer, finally starting >>> to think about the server side of a web app I've been working on for some >>> time. I was wondering if anyone could offer some pointers for libraries >>> worth looking at. What would you be building on top of if you were starting >>> a web app in 2018? >>> >>> It's a single page app. I've already committed to Reagent on the client. >>> Will very likely go with Dataomic as the DB. The rest is open for now. >>> >>> I realise there is no "right answer" to such a question. All I'm after >>> here is to take the pulse of the community - "take a look at so-and-so", >>> "such and such is becoming a de-facto standard", "a few people got burned >>> with thingumy"... >>> >>> I think there are two distinct sub-questions here. First off one is >>> going to need a general server-side library e.g. Luminus (more a collection >>> of libraries), and then there is the much bigger question of keeping data >>> in sync across multiple clients/servers. Here we get into the vast topic of >>> distributed systems, full of deep, open questions, but I'm hoping for >>> advice for the working programmer : ) >>> >>> Of particular interest would be whether people feel any of the more >>> ambitious libraries (e.g. Replikative) are worth relying on for a serious >>> project, or are people generally still rolling their own, RPC style. >>> >>> Thanks very much, in advance! >>> >>> Tom >>> >>> -- >>> 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/d/optout. >>> >> -- >> 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...@g
mu4e:view show email address after display name in message headers
I would like to configure mu4e:view to display the email address along with the display name in the To: From: Cc: Bcc: etc fields. Is this possible with current mu4e customization options? The information is already present in the buffer: if I hover over the name with the mouse cursor, email addresses are displayed in a tool tip. That's not ideal for hands on keyboard usage, however. Going a step farther, it would be great to use a function with access to this information to selectively show the email address or otherwise decorate the display name. i.e. Having the display name read: "John Smith (ACME)", or "Fred Factor (outside)" would be highly convenient. Thanks, Jeff -- 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/d/optout.
Re: Clojure(Script) web apps in 2018
I don't want to derail the conversation, but on the subject of Duct and Integrant, it's certainly possible to use regular Duct libraries in Integrant without buying into Duct's module system, should you want something more straightforward. The latest alpha version of Integrant also adds a 'prep-key' method, which allows default references to be added to an Integrant key without the need to resort to modules or external configuration modifier functions. The next version of Duct simplifies the module system somewhat, and my eventual intent is to make all of the web framework pieces optional, either this upcoming release or the one after. On Mon, 24 Sep 2018 at 14:40, Rick Moynihan wrote: > I'm a massive fan of integrant on which duct is based. In my mind it > takes Stuart Sierrra's component to its logical conclusion, which is > essentially treating the system as EDN configuration. I think most > moderate/large component projects tend to want to convert systems into > config. Essentially integrant is what you get when you decide to create > component but config first. Unlike mount, I think it is much more cleanly > decomplected... i.e no problematic singletons. > > In many ways I wish duct wasn't a web project at all, and was just a > generic module system; a thin layer on integrant, for configuring > components, and that the web framework was a separate project of duct > components altogether. When you look at it closely though, you realise it > pretty much *is* this; it's essentially just a module system with a web > framework as an exemplar. However, there are perhaps one or two places > where this isn't entirely true. > > Duct modules can be a bit confusing, and are I think a litlte too > powerful; but overall I'd recomend it. > > R. > > On Sun, 23 Sep 2018 at 22:07, Nathan Fisher > wrote: > >> Duct looks interesting. >> >> I found luminous useful for when I first started with web dev in clojure >> but started running against its project layout. >> On Sun, Sep 23, 2018 at 15:17, Rick Moynihan >> wrote: >> >>> I really quite like weavejester's duct, because it's essentially a >>> familiar / standard ring app, but with integrant based configuration >>> modules, and sensible defaults. It's not perfect though, e.g. ataraxy is >>> somewhat under-developed, so I'd look at swapping it out for bidi or >>> something more mature. >>> >>> https://github.com/duct-framework/duct >>> >>> I've built a fair few luminus apps over the years and find it hard to >>> love because of mount; and I strongly feel the templates default layout is >>> organised in the wrong way. It's hard to argue that it's not well >>> documented, and quick to start with though, and it's pretty easy to use >>> integrant or component and delete the src directory and pick a more >>> sensible layout (I recomend structuring by feature/route, rather than by >>> the incidental complexity of a webapp). >>> >>> Ultimately all the main options mentioned work quite well, so it depends >>> on what you need and like etc. You might also consider backing it with >>> lacinia as a graphql backend. lacinia is pretty neat. >>> >>> >>> R. >>> >>> On Mon, 17 Sep 2018 at 10:27, Tom Locke wrote: >>> Hi all, I'm a reasonably experienced ClojureScript developer, finally starting to think about the server side of a web app I've been working on for some time. I was wondering if anyone could offer some pointers for libraries worth looking at. What would you be building on top of if you were starting a web app in 2018? It's a single page app. I've already committed to Reagent on the client. Will very likely go with Dataomic as the DB. The rest is open for now. I realise there is no "right answer" to such a question. All I'm after here is to take the pulse of the community - "take a look at so-and-so", "such and such is becoming a de-facto standard", "a few people got burned with thingumy"... I think there are two distinct sub-questions here. First off one is going to need a general server-side library e.g. Luminus (more a collection of libraries), and then there is the much bigger question of keeping data in sync across multiple clients/servers. Here we get into the vast topic of distributed systems, full of deep, open questions, but I'm hoping for advice for the working programmer : ) Of particular interest would be whether people feel any of the more ambitious libraries (e.g. Replikative) are worth relying on for a serious project, or are people generally still rolling their own, RPC style. Thanks very much, in advance! Tom -- 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. >>>
Re: mu4e:view show email address after display name in message headers
I guess you could do this in clojure, but you might want to try elisp first ;-). (I expect the overlap of emacs, clojure and mu users to be significant, so maybe this wasn’t the wrong group after all!) Sent from my iPhone > On 24 Sep 2018, at 18:26, Jeff Kowalczyk wrote: > > I would like to configure mu4e:view to display the email address along with > the display name in the To: From: Cc: Bcc: etc fields. Is this possible with > current mu4e customization options? The information is already present in the > buffer: if I hover over the name with the mouse cursor, email addresses are > displayed in a tool tip. That's not ideal for hands on keyboard usage, > however. > > Going a step farther, it would be great to use a function with access to this > information to selectively show the email address or otherwise decorate the > display name. i.e. Having the display name read: "John Smith (ACME)", or > "Fred Factor (outside)" would be highly convenient. > > Thanks, > Jeff > -- > 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/d/optout. -- 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/d/optout.
Re: mu4e:view show email address after display name in message headers
Hey Jeff, On Tue, Sep 25 2018, Jeff Kowalczyk wrote: I would like to configure mu4e:view to display the email address along with the display name in the To: From: Cc: Bcc: etc fields. This is definitely the wrong list, but given how easy it is to do this, I thought I'd help you out. (setq mu4e-view-show-addresses t) Going a step farther, it would be great to use a function with access to this information ... Setting it to a function is harder, but you could advise mu4e~view-construct-contacts-header if you really wanted to. That's not a public function, though, so it might change in future. Carlo -- 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/d/optout.
