My "ideal" framework - wishlist

[R. Rajesh Jeba Anbiah]

I just thought of sharing this.. FWIW....

1. More RoRish framework (APIwise)
   
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!)
3. More RoRish in terms of convention over configuration
   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.
4. With default routing
   So that no one has to handcode all routes
5. 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.
6. 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
7. Throttled REST
   For API rate limits through hooks
8. 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.
9. Toolkit instead of just a framework
   Something like Yii framework that bundles with Auth, ACL and Admin system.
10. Prefix routing for lazy ACL
    Something like http://book.cakephp.org/2.0/en/development/routing.html
11. 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)
12. 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.
13. Code generators
    That builds skeleton from database mapping (without XML) using RoR convention
14. 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
15. 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.
16. Pseudo SSI
    Currently this is possible with Japid's invoke and Rhythm.
17. High performance by default
    http://static.raibledesigns.com/repository/presentations/Play_vs_Grails_Smackdown_UberConf2012/
    
18. HTML & Form Helpers (?)
19. Installable theming and plugin architecture
    Think about WordPress:-)
20. Database or cache driven settings (application.conf), messages
    For users to change them easily
21. Easy installable mods ecosystem
    Think about http://activemerchant.org/
22. i18n, timezone, etc support
23. Message Queues, Jobs, Async,... anything useful

[R. Rajesh Jeba Anbiah]

Some goodies are already available as modules:

1. https://github.com/lmcalpin/Play--Scaffold
2. https://github.com/greenlaw110/play-config
3. http://www.playframework.com/modules/messages
4. https://github.com/greenlaw110/greenscript
5. http://www.playframework.com/modules/jqvalidation-head/home
6. https://github.com/pepite/play--pdf
7. https://github.com/feliperazeek/playframework-elasticsearch
8. https://github.com/mericano1/play-auditlog
9. https://github.com/greenlaw110/play-app-base

[Sergey Palyanov]

Hi, Rajesh.

Items #4, #5, #6 are already available in the original Play Framework 1.2.x.

Play Framework already has default route binding, so you don't need to bind all the actions.

And content negotiation covers the rest.

Hope you find it useful.

понедельник, 4 марта 2013 г., 20:13:24 UTC+4 пользователь R. Rajesh Jeba Anbiah написал:

[R. Rajesh Jeba Anbiah]

On Tuesday, 5 March 2013 15:10:49 UTC+5:30, Sergey Palyanov wrote:

Items #4, #5, #6 are already available in the original Play Framework 1.2.x.

Play Framework already has default route binding, so you don't need to bind all the actions.

And content negotiation covers the rest.

Hope you find it useful.

Thanks Sergey, I may have missed something. For default routing, since, the RoR conventions for file names, etc are not enforced, it's  difficult to get that working by default now, IMHO. I think, I get your point about content negotiation and how it restricts extra controller actions; but I actually meant, better control on REST friendly URL scheme and easier response type hooking mechanism; for example, adding another .ics response type. Thanks again.

[Dieison Antonello Deprá]

My two cents...

I think the framework should not render view , it's a client responsibility and we already have amazing JS frameworks for that, like AngularJS and KnockoutJS, so just response pure static text and combine with JSON or XML into client.

So the framework have focus their efforts in tasks like stateless, scalability, distributed processing, distributed cache memory,  clustered architecture, hit workflow, robust active record orm mapping and easy extensions with plugins. 

[R. Rajesh Jeba Anbiah]

On Monday, 11 March 2013 00:24:17 UTC+5:30, Dieison Antonello Deprá wrote:

My two cents...

I think the framework should not render view , it's a client responsibility and we already have amazing JS frameworks for that, like AngularJS and KnockoutJS, so just response pure static text and combine with JSON or XML into client.

So the framework have focus their efforts in tasks like stateless, scalability, distributed processing, distributed cache memory,  clustered architecture, hit workflow, robust active record orm mapping and easy extensions with plugins. 

When it comes to frameworks, we have big 2 cults: 1. RoR, 2. Sinatra. You seem to prefer Sinatra; if I understand right, this is the direction of Express/Node.js and Play2. But, I think, for "better" SOA  approach, it's good to host JavaScript client app in static in Nginx and making it to contact DB directly (MongoDB with ACL?). 

For real websites, I prefer RoR as you can even make it to server JSON, CSV or HTML. Even big guys are complaining that there's no good client side frameworks available http://unicornfree.com/2013/why-we-shut-down-charm-on-the-eve-of-public-launch-at-48kyear-and-growing#comment-1248 But, I prefer a framework that can be stretched to either side. (You won't be locked down to particular direction).

[green]

Agreed, the framework should support different paradigms, the point is the support should be native to those paradigm practitioners.

--
You received this message because you are subscribed to the Google Groups "playone" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playone+u...@googlegroups.com.
To post to this group, send email to pla...@googlegroups.com.
Visit this group at http://groups.google.com/group/playone?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[green]

Hey Rajesh,

I've just published this blog about ActFramework. Now let's have a review of your "ideal“ framework and see how close Act is:

1. More RoRish framework (APIwise)

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

1. 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!)

1. 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.

1. More RoRish in terms of convention over configuration

1. 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 inresources/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.

1. 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.

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

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

1. 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

2. 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

3. 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.jsonwill be automatically routed to action handler at /custmer/{id} and have the request Accept header set toapplication/json

4. Throttled REST. For API rate limits through hooks

   Nice feature. Not yet in Act though.

5. 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

6. 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.

7. 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 {
       ...
   }

8. 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

9. 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

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

    Not there yet.

11. Multiple database. With option to switch (master -> slave). Something like thishttp://bakery.cakephp.org/articles/gman.php/2009/01/20/master-slave-support-also-with-multiple-slave-supportrenderPartial() 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

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

    Not there yet

13. 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.

1. HTML & Form Helpers (?)

1. Not there yet

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

   Not there yet

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

   Not sure what this point is exactly

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

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

5. i18n, timezone, etc support

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

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

1. 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