Respond to Rajesh 's post "My ideal framework" to playone group

resp_my_idea_framework.md

1. More RoRish framework (APIwise)

   If you are talking about expressiveness and developer friendly, I think ActFramework is really hitting this point!

2. So that on scalability issue or JVM migration, people can easily switch to this framework. This will be a big selling point. (Migration script will be a bigggg selling point!)

   Comparing to Play, Act is using standard maven project layout, using maven to manage the dependencies, using google guice to manage the depedency injection. It's more easier for developer to move from place like SpringFramework. Actually I specifically designed Act so that it get the greatest part from Play but without those very special requirements on project layout/static method in controller etc in play.

3. More RoRish in terms of convention over configuration

   Yes, Convention over configuration is every where in Act. E.g. giving the following action handler method:

   @GetAction("/customer/{id}")
   public Customer show(String id) {
       return customerDao.findById(id);
   }

   It will return a JSON encoded customer entity if the request is "application/json", or XML encoded one if request is asking "text/xml". More than that, if you have your own template defined in resources/rythm/pkg/to/CustomerController/show.json then for JSON request, it will use that template to render instead of system built-in JSON serializer, and if xml template is defined then when request is asking for xml, then the template will be loaded.

   Every configuration item has default value and the default values are designed to make sense to understand and be agreed.

4. Especially for table naming and field naming conventions. Also, created & modified automagic handling. In play!, AFAIK, most people stuff all codes inside Application Controller. But, it would be better if the framework enforces different controller as per tables; say, users, products, etc.

   Act does not hit this point. To my understanding no real project can really map table/field structure directly to http service API.

5. With default routing So that no one has to handcode all routes

   Sorry again, Act does not favor this design choice. The same reason, in real project http service API SHOULD be mapped to controller methods instead of following certain naming conventions. However Act makes the mapping be very easy through Annotion

6. Single controller action and multiple view for different content types. Something like CakePHP's parseExtensions() http://book.cakephp.org/1.3/en/The-Manual/Common-Tasks-With-CakePHP/REST.html With this approach, you'll have only an index() with single render() call and the dispatcher will route the view to different view file, say /xml/index.html or so.

   Absolutly, Act render different view based on the content type

7. No content negotiation, but REST URL. Instead of play!'s automatic content negotiation, it could support transparent REST URL something like /products/index.xml or /xml/products/index

   Yes! If you have content_suffix.aware set to true, then request sent to '/customer/123/json' or /customer/123.json will be automatically routed to action handler at /custmer/{id} and have the request Accept header set to application/json

8. Throttled REST. For API rate limits through hooks

   Nice feature. Not yet in Act though.

9. Easier response handler hooking mechanism. So that instead of having /xml/products/index.xml view, the XML renderer will automagically display XML by hooking renderer API. Saves lots of view files when we have to handle more response types like CSV, PDF, etc.

   csv, json, xml are supported already in Act. pdf yet to come

10. Toolkit instead of just a framework. Something like Yii framework that bundles with Auth, ACL and Admin system.

    By putting itself in the ecosystem of maven, Act makes it easy to integrate any Java tools. For Auth/ACL act-aaa-plug is the thing which provides authenticating/role based authorization/accouting facilities.

11. Prefix routing for lazy ACL. Something like http://book.cakephp.org/2.0/en/development/routing.html

    Act does not provide this feature. However Act provides a feature called "named port" which allows you to bind to port that is different from default port. E.g. by default you listen to 5460, which will be called by your nginx upstream proxy. If you have some admin tasks which is very restricted, you can create a named port "admin = 7777", and that port will only be available to your intranet. Then in your XxxAdmin controller you declare the controller listen to the admin port as:

    @Controller(port = "admin") 
    pubic class AdminController {
        ...
    }

12. ActiveRecord/ORM that supports vast databases. Plugin option is one thing; but if such wrapper is added by default, it may make developers' life easier when switching to other database (say, MySQL to MongoDB)

    Act defines a uniform DAO interface for database access. Model could be any POJO, however it needs to be annotated with proper annotation. E.g. Morphia model needs a morphia @org.mongodb.morphia.annotations.Entity while SQL model needs a @javax.persistence.Entity, and the same thing must happen for @Id annotation. Other than the SQL model and MongoDB model are very similar. And it is even able to annotate model class with @act.db.DB annotation to specify which data source you want this model class to talk to. The database source could be either mongodb or sql. Have a look at the doc-sample project in act-demo-apps

13. Generic Application Controller and Generic Model for to be extended. So that beforeAction, afterAction, beforeSave callbacks can easily be hooked. Low priority as we can live with Hibernate's events API if Hibernate is chosen.

    Act use Morphia for MongoDB access and Ebean for SQL database access. Both support annotated lifecycle callback method

14. Code generators. That builds skeleton from database mapping (without XML) using RoR convention

    Not there yet.

15. Multiple database. With option to switch (master -> slave). Something like this http://bakery.cakephp.org/articles/gman.php/2009/01/20/master-slave-support-also-with-multiple-slave-support renderPartial() support by default and automatic ajax layout switch So that headerless pjaxed version is rendered from server. That is, layout is automatically switched from main to ajax when requested from Ajax. Currently possible, but would be better to have it by default.

    For mongodb, I think you just configure the proper URI and you get everything done. For SQL I am not sure how this could be implemented in a generic way.

    The other means of multliple-database is actually multiple datasource which could be completely different database solution. Act support that in a very expressive way. Just configure your datasource and use @DB annotation on Model class to specify which datasource this model needs to talk to. Check out the detail at multi-db support

16. Pseudo SSI. Currently this is possible with Japid's invoke and Rhythm.

    Not there yet

17. High performance by default. http://static.raibledesigns.com/repository/presentations/Play_vs_Grails_Smackdown_UberConf2012/

    Act is designed to provide rich featured and expressive framework for web app creation. It's also designed to pay attention to performance. E.g. the routing mechansim shows 10x times better than PlayFramewokr v1.x. Calling to action method use reflectasm when possible before going back to Java reflection.

18. HTML & Form Helpers (?)

    Not there yet

19. Installable theming and plugin architecture. Think about WordPress:-)

    Not there yet

20. Database or cache driven settings (application.conf), messages. For users to change them easily

    Not sure what this point is exactly

21. Easy installable mods ecosystem. Think about http://activemerchant.org/

    Act is using maven, so ... Plus the plugin repository is planned

22. i18n, timezone, etc support

    No special facilities. However all is doable through message files and rythm template's i18n() extension

23. Message Queues, Jobs, Async,... anything useful

    There are much easier way to play with Jobs in Act in comparing to Play one. Plus there is a very nice event dispatching/binding mechanism. Message Queue is not there yet but will come up with it definitly