> "Stop!". When I read this, my mind cries "Alert! potential java-in-clojure > code here !".
Sorry I didn't want to frighten you with the words "MVC" and "Clojure" in the same sentence :-). However, I think it's just the right approach to separate the presentation from the logic. I may be wrong and then would be interested to hear of different designs which preserve this separation. > clojure promotes a generic approach to data management. Writing a protocol > for each piece of data to exchange between parts of the app should warn you > something is wrong ... (or will quickly become "as" painful as writing > idiomatic java) Not a protocol for each piece of data but a protocol for all data. Like: (defprotocol View (display-banana [this banana]) (display-melon [this melon])) etc. Is it worse than having the equivalent functions? It allows me to switch the particular implementation without changing the listeners' code. > Is it too late to challenge the architecture ? No. It's never too late ;) > To help you, we would have to know more about your problem ... Ok then just see the application like a specialized editor: you can create and open documents, make modifications to them, get help from the application to build and parts to your document. Documents are represented and edited graphically with Swing. What design would you suggest? -- 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
