[ANN] Phoenix 0.1.0 - help with structuring & configuring Component-based systems

[James Henderson]

Hi all,

I've just released v0.1.0 of Phoenix - a 'batteries included, but removable' library to wire up and configure Component-based systems. If you've ever wondered whether you really have to copy and paste 'system.clj', 'dev.clj' and 'user.clj' from one Component project to the next, it's well worth having a look at!

Having used Phoenix in anger on a few projects for a couple of weeks, it's now had a fair bit of battle-testing, kinks ironed, and the like - so thought I'd make another post to the list :)

Features added since I last posted:

• Many re-usable Components - CLJS compiler, Aleph, http-kit, JDBC pool, CSS compiler (using Garden) - see https://github.com/james-henderson/phoenix/tree/master/modules/ for more details. These components can be used whether or not you choose to use Phoenix, and, likewise, non-Phoenix components can be used in Phoenix-configured systems - hooray for composability :)
• Support for managing passwords/credentials - you can store these, encrypted, in your configuration, and Phoenix will decrypt them for you.
• Pulling configuration variables from environment variables and JVM properties, in addition to the Phoenix config files
• 'Batteries removable' API - if you need a little more flexibility, or want to compose Phoenix with something else.
• A fair few bugfixes/API changes through usage

There's also a couple of Lein templates to get up and running quickly:

•  `lein new phoenix-webapp <my-project> -- :reagent` will get you a working webapp (other options are `:om`, `:om-sablono` or `:flow`). 
• If you don't want the CLJS side, `lein new phoenix-api <my-project>` just has an example server-side API.

Would be great to get your thoughts and feedback on this - is this a good way to wire up such systems?

Cheers,

James

[James Henderson]

A link would have been really helpful, I'm guessing! Here it is:

https://github.com/james-henderson/phoenix

James

[Jeroen van Dijk]

Thanks for sharing James! I'll have a look. 

As a side note, I see in the example code that you are dissoc-ing on the component. This can lead to unexpected behaviour as I have experienced (mostly in repl cases), as this will return a map instead of a record when the field is not part of the record. This is also mentioned in the readme of https://github.com/stuartsierra/component where `(assoc component ::field nil)` is recommended

Jeroen

--
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/d/optout.

[James Henderson]

Thanks Jeroen - I'd not spotted that! Yes, definitely a better idea - will update the examples.

James

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/EgfoZK0vV08/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

[Fluid Dynamics]

On Tuesday, March 31, 2015 at 7:49:52 AM UTC-4, Jeroen van Dijk wrote:

Thanks for sharing James! I'll have a look. 

As a side note, I see in the example code that you are dissoc-ing on the component. This can lead to unexpected behaviour as I have experienced (mostly in repl cases), as this will return a map instead of a record when the field is not part of the record. This is also mentioned in the readme of https://github.com/stuartsierra/component where `(assoc component ::field nil)` is recommended

Perhaps there should be an enablable warning for that, the way there already is for reflection. When enabled, it would go off if

a) Code was compiled for (dissoc x :foo) where x could be determined by static analysis to be an instance of a record type for which :foo is a base field, and also if
b) A dissoc on a record returned a plain map,

or at least b).

Enabling the warning could work partly by actually redefining clojure.core/dissoc, as with disabling it, so that the overhead of the warning code was completely avoided with it disabled. With it enabled, the code path in dissoc that produces a non-record from a record would also emit a message to stderr with general wording such as "warning: dissocing base field :foo from MyRecord, producing hash map, at line 666 of evil.clj". (The line and file being obtained by constructing a Throwable and then dismantling and examining its StackTraceElements.)

Turning this on and exercising a project (especially, running all the tests if it has good test coverage) would then find most potential-bugs of this sort.

[James Henderson]

Just released 0.1.1 - bug when using Schema in Phoenix apps due to Phoenix's overly-enthusiastic AOT'ing.

Thanks to @whodidthis for flagging the issue!

James