Hi Leif - thanks for the suggestion. You're not the only person that's questioned the auto-namespaced keywords, btw!
The original reasoning behind them was to keep Phoenix-related configuration separate from the user's own configuration, but without enforcing typing :phoenix/ in front of all of the keywords. I'm not sure if this is the best/only way to do it, or even whether people would mind writing out :phoenix/component or :phoenix/dep every time they were required? Do you have any ideas/thoughts about how to do this? I'm happy to make breaking changes at the moment if necessary - Phoenix is still very much in 0.0.x territory! Also, I didn't realise the EDN spec prohibited it, although now you mention it it makes sense that it should. I think, on balance, I'd prefer to resolve the problem rather than just accepting it and renaming the configuration file - if we can find the right way to solve it! Thanks, James On Sunday, 25 January 2015 13:15:00 UTC, Leif wrote: > > Hi, James. > > I'll let people with more experience with components critique your > solution, but one thing that I thought was weird was that you had > auto-namespaced keywords in the config file. I'm referring to: > https://github.com/james-henderson/phoenix#adding-dependencies-between-components > > That means only code in your blessed ns can read the file, or things > break. Also, the edn spec disallows keywords beginning with "::". So, I'd > suggest either following the edn spec or using the ".clj" ending for the > config files. > > --Leif > > On Saturday, January 24, 2015 at 10:20:10 AM UTC-5, James Henderson wrote: >> >> Hi all, >> >> I've just released Phoenix - a library for declarative configuration and >> wiring of Component-based systems. Phoenix came out of a number of >> discussions at ClojureX, thank you to all involved for their suggestions >> and feedback :) >> >> https://github.com/james-henderson/phoenix >> >> If you’ve written a traditional Component-based system, you’ve probably >> experienced having to create and maintain a plethora of ‘system.clj’, >> ‘dev.clj’, ‘user.clj’ etc type namespaces in order to wire-up the system, >> set up configuration-based switches, and duplicate the code to >> start/stop/reload the system. Phoenix removes the need for all of this, >> replacing it with one (or more, if you choose) EDN declaration of how your >> system should be wired up. It should also compose well with any other >> Components you (or anyone else) may have already written. >> >> For a sample project, you can run 'lein new phoenix-webapp <your-project>', >> then 'cd <your-project>' and 'lein dev'. Once the nREPL is up, running ' >> (phoenix/reload!)' will stop the system, reload any namespaces, and >> restart the system. >> >> Phoenix is just one possible way of wiring up such a system - I >> understand that there are a fair few ideas floating around out there at the >> moment! I'd be really interested to hear your thoughts - whether it be >> 'this is mostly right, but I wouldn't do that part like that', or 'you've >> gone about this completely the wrong way, because ...' - let me know! >> >> Cheers, >> >> James >> > -- 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.
