florinpatrascu

updated the docs with a better message: http://micro-docs.simplegames.ca/internationalization.md, please note the Country role in naming the translation files. Thank you!

> How is this different from the recently released Play framework.

I believe a web Designer will be less intimidated by Micro.

I truly understand your point, and this is why Micro is offering a flexible scripting support. You can quickly prototype your business logic without needing to restart the app, which BTW, it only takes a few seconds. Using Beanshell, for example, allows you to develop and test the business logic and then transfer the code to Java if need be.

However, I am currently working on integrating the JCL (https://github.com/kamranzafar/JCL) library, recently released under a dual license by its author; it used to be LGPL only. This way I hope I can offer the class loading support at runtime, like Play is doing it, for example.

Thank you. I hope the uTorrent guys don't mind the resemblance of the two favicons. The Greek letter μ is universal. I'll change the colours if need be :)

Thank you for pointing it out.

Further more, to a comment I made earlier: http://news.ycombinator.com/item?id=5196565 and regarding the package managers.

As a Ruby developer, my first impulse was to use Rake but I started with Maven, trying to follow the bigger players, and I found myself struggling with managing various Maven dependencies and settings instead of focusing on getting the things done. Then I switched to Ant when I discovered the difference it makes when deploying to Heroku. Mu's compiled slug size deployed with Maven was 57Mb while the same core deployed with Ant today is 11.7Mb, give or take.

I'll commit the Maven configuration files soon, it is not my intention not too, but I will still search for a better solution. Any suggestions? Thank you for your feedback!

dropwizard looks very cool.

I believe more and more that Micro is talking to a specific audience, where the non-Java users have an important role too in the development of the site; Designers, Content managers, etc. With Micro they can prototype quickly before even calling for dev support. I am glad that when I compare Micro with similar frameworks, I realize how small Micro is:) And I truly like it this way. Sure Micro is lacking the persistence support for now (many other features too, probably) and it will be hard to compare it with other frameworks from this perspective. However, Micro is modular and can be expanded easily! (I am searching for a light ORM that I could add as an optional extension; activejdbc, maybe?)

Honestly, I see all the other similar frameworks as options, not as competitors. Let the users compare and choose based on what they want to accomplish. Maybe they'll use ... I don't know ... Play, to randomly pick one, for building an awesome e-comm web site, but would they use it for developing a .. blog, or a fast REST service front-end layer let's say?! The Ruby world is full with good examples where devs/designers are swinging between the fat Rails and the slimmer Sinatra/etc., shouldn't we be glad we can start doing the same in Java?

;)

I believe Play and SpringMVC are both great frameworks and it will be hard and probably too early to compare Micro with these two. I designed Micro's functionality from outside-in, and tweak it for performance from inside-out; small memory footprint, light and fast, .yml for config, extensions, routing and REST support without Java annotation, scripting support for fast prototyping, template engines for clean dynamic content manipulation. I am trying to bring in as much as I learned from my experience as a Sinatra/Merb developer.

Working with Designers for so many years, I was trying to build something that a Designer can use in minutes and use it for publishing his work with the littlest effort possible; all these without writing a single line of Java code. I am sure Play/SpringMVC can do that too?!

For Micro, the separation of roles and concerns is adamant. Micro (like jpublish.org) is about helping the publishers taking their dynamic content to the web as easy as possible, while allowing the Developers to bring in as much business logic power as possible but without interfering with the content publishing concern; the true separation of roles and concerns. Please have a look at Micro's documentation web site: http://micro-docs.simplegames.ca/ (source on Github too); hosted at Heroku, it is a Micro web app and its entire content is written in Markdown. This is an example of what most of the web Designers and the small publishers will like to have, I think/hope?! Speaking about the Heroku, the compiled slug size, for a standard web app using Micro, is 11.7Mb. Micro is micro :)

Lack of examples, sorry. Country and Language are both supported. You can create the following properties file: messages_en_GB.properties, and you have a language and country based translation!

I will clarify this aspect in the docs, many thanks for catching that!

I will add an example. My goal is to leave the framework as lean as possible and add functionality by using various extensions. I can see the security functionality added as a µ Extension enabling a set of filters and specific web pages; ala Devise. The Extensions allow you to create a completely independent "mini-site" and inject its functions into the main app. With extensions you can add your own filters, routes, controllers and specialized dynamic content/web-UI. Please have a look at: https://github.com/florinpatrascu/micro-extensions/tree/mast..., as an example implementation of the aspects mentioned above. I see something like Devise being built this way.

thank you for feedback. The µ docs site is trying to satisfy the Designer and the Developer, two very important roles in my framework design strategy. You are very right about Sinatra and I will definitely add more examples. Counting on the community to improve the docs as soon as µ gets more traction, this is why the docs site is open source too :)