> 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.
I made that comment earlier. I am curious what gem is specific to Rails? Maybe something specific to RailTies? I am imagine you can find a few if you try, but I think they are rare. Stuff like ActiveRecord is not specific to Rails -- you can use ActiveRecord with Sinatra, or any other Ruby web framework. The same goes for Device (authentication) CanCan (authorization) and any of the HTML template languages that you can think of (too many to list). Middleware is handled by Rack. So you've got an ORM and HTML templates and authentication and authorization and all of that is general to Ruby, not to Rails. That is in contrast to PHP where the plugins are specific to particular frameworks. To my way of thinking, Ruby is better than PHP exactly because it allows a higher level of composability and Clojure is better than Ruby because it allows a higher level of composability than Ruby. On Monday, May 4, 2015 at 5:47:35 AM UTC-4, Colin Fleming wrote: > > 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 <sve...@googlemail.com <javascript:>> > 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 clo...@googlegroups.com >> <javascript:> >> 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 <javascript:> >> 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 <javascript:>. >> 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.
