Hey Craig and Jeroen, Jeroen:
Can you elaborate on what kind of features you would like to support? Are you just deciding on DSL syntax or do you have already some kind of Clojure layer working? -My main goals are to create as "pretty" of a format for defining CF templates within Clojure syntax and support compiling/decompiling to/from JSON templates. I would definitely like to do some amount of validation, taking advantage of the schema<http://vstoolkit.amazonwebservices.com/CloudFormationSchema/CloudFormationV1.schema> and perhaps some of the logic from the eclipse plugin<https://github.com/aws/aws-toolkit-eclipse/blob/master/com.amazonaws.eclipse.cloudformation/src/com/amazonaws/eclipse/cloudformation/templates/schema/TemplateSchemaRules.java>, though I'm not sure yet how rigorous the validation should be. -I think some really nice additional features would be some kind of launcher, perhaps done as a leiningen plugin and using amazonica, and simplified creation of custom CF resources, which are incredibly powerful and I think fit well with the principles of Clojure, as they are meant to be small, idempotent modules of functionality that follow a certain protocol About the DSL, in the end I decided to stick closer to the CF syntax to avoid confusion and documentation mismatches. So for instance, all my parameters for a CF resource are CamelCase. One of the most important features for me is the validation on missing fields and Reference checking. -I was thinking about this too and started with camel case, but I've been using AngularJS a lot lately, and I actually love the fact that it converts to/from hyphen-case and CamelCase as convention dictates, so I think I want to implement that. It shouldn't be too hard to do using some autocorrection of case based on the schema (above) If you are interested in collaborating in this, please let me know. -I'd love too. Please feel free to contact me at kevin.a.bell (at) gmail Craig: Typical advice is to not use macros (implicitly used in the gists to build a CF DSL) when functions or data will suffice. Sometimes however the syntactic sugar is quite tasty and hard to overlook. I do not have enough knowledge of the domain to suggest what might be the correct approach in this case. -That makes sense, and I was thinking about using functions for things like the mappings, resources, etc. However, it seems nice to have variables that can be reused later in the template. Keywords could work for this, but I feel like that gets a bit awkward if you look at what I was trying to do in the keyword-heavy version. One thing that struck me about the version using macro-defined variables though is that, since the whole template syntax ultimately just produces a big map, defining/using variables within it is equivalent to doing (def mymap {:first-key (def mystring "a") :second-key mystring}), which works, but is that weird? Some additional comments: - your use of with-foo pattern is not idiomatic afaics; this pattern is typically used to scope run-time resource usage -This is something I've been struggling with a bit. The thing is that while CF templates are just JSON files, they actually have an explicit execution path and various scope considerations at runtime. So on the one hand, this is just a tool to produce JSON data, but on the other hand there would be a real meaning to the scoping implied by the with-foo syntax - in relation to parameters: the means by which defrecord introduces record attributes may be instructive (if you go the DSL route) -I like that idea of having the parameters simply being defined in square brackets "[]" at the top as in defrecord. However, each parameter does require a potentially large map of properties (type and validation information), which may be hard to fit into that syntax Thanks a lot for the feedback so far! -- -- 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/groups/opt_out.
