Note that the shopping cart is just one specific example from my current itch that needs scratching - it's a very common one, but I'm sure there are plenty more reusable component types that people expect these days.
One problem I see with the composition approach (which I'm a huge fan of in general) is the multiplicative complexity. Something like a shopping cart needs access to the persistence layer. In Rails, this is very easy - you use ActiveRecord and you're done because everything else uses ActiveRecord too. However in the Clojure world we have N persistence libraries implementing M persistence strategies - I've never tried to make a reusable component that sits in the "middle" of the stack (i.e. not something that's relatively trivial to make dependency-free like logging), but I can imagine that it's very difficult. And of course, persistence is just one aspect, there must be many more like authentication and so on. A big part of the reason for Ring's success is that it's the only game in town - I'm sure we wouldn't have so much great functionality built on top of it if we had 4 incompatible options to choose from. Someone earlier in the thread wrote about how Ruby was the abstraction in contrast to PHP where libraries were tied to a framework. I've never worked with Rails seriously, but I find it hard to believe that libraries such as shopping carts intended for Rails will work out of the box with some other framework - is this the case? The ones I looked at (admittedly briefly and some time ago) were all Rails-specific. On 4 May 2015 at 20:41, Sven Richter <sver...@googlemail.com> wrote: > So, what I gather from this discussion are the following points. Clojure > "needs" a "webframework" that is > > - fully documented > - easy for beginners to use > - opinionated about the libraries > - structured > - composable > - has something nice like django's admin backend > - a vibrant community support > - a shopping card (whereas I would see that fit into an external library) > > I agree that we have almost everything we need in the form of single > libraries. And I think a mix of leiningen templates and plugins is the way > to go here. > The reason for the last statement is my experience with django. The admin > UI is awesome and it fullfills 95% of your needs, but for the rest of it to > make it work I had to start hacking my local django source, which is PITA > obv. > > I would refrain from doing some magic that only works in a specific > context, but instead just generate code that is put into a fixed structure > and works. The advantage is, one can change the code all the time if one > needs to. > > All in all this is basically the direction I want to go with closp and > closp-crud. The intention is not to have a webframework, but to automatize > steps that need to be done manually otherwise. > > I am open for everything in that area, as long as it stays in the limits I > stated above, so, if someone wants to join, he is welcome. > > I would also go the other way around and put efforts into someone elses > project, if that makes sense. > > Am Montag, 4. Mai 2015 07:43:43 UTC+2 schrieb puzzler: > >> On Sat, May 2, 2015 at 11:12 PM, Sven Richter <sve...@googlemail.com> >> wrote: >> >>> Reading through all the discussion I don't get which features you are >>> actually missing. I love luminus and did a lot with it, however, for me it >>> was missing some standard stuff, that's why I put together closp, which is >>> just another leiningen template providing some more features out of the box. >>> I'd consider adding even more features if you would become more specific >>> in terms of features. >>> >> >> For me, one of the killer features that keeps me coming back to >> Python/Django for web development is the auto-generated admin interface >> that lets non-programmers add new content to the database. >> >> Clojure's Caribou is the only Clojure system I've seen to offer something >> similar, but as I recall, Caribou is no longer being actively developed. >> > -- > 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.
