search

Rovak / KJSencha

Ext-JS / Sencha Touch Integration Module for Zend Framework 2
Other
24 stars 15 forks source link

Feature/service manager for rpc api #12

Closed Ocramius closed 11 years ago

Ocramius commented 11 years ago

This PR introduces following new features:

  1. service names mapped as JS API via config (See #4)
  2. caching enabled by default (using the memory adapter/dummy)
  3. deprecation of previous "crawl" logic in favor of direct explicit mapping (functionality is kept for BC)
  4. simplification of the ModuleApi class, which now is a simple wrapper of available actions (may rename it shortly into ApiContainer or ActionContainer)
  5. removal of requirement to use the view model produced by KJSencha\Frontend\Bootstrap in favor of explicit view helpers
  6. documentation of the introduced features

Hope you like it :D

Rovak commented 11 years ago

The PR looks really good, lots of improvements made in the overall code.

I don't agree with the deprecation of the crawl logic, the functionality is provided by a lot of other Ext.Direct generators and personally i find it really useful to be able to use convention over configuration.

What is your intended use for the docs folder? I prefer to keep the documentation centralized in the wiki, i shall cleanup the current mess tomorrow so it can be added there.

Ocramius commented 11 years ago

@Rovak I prefer keeping docs with the repo itself since it forces users to clone it together... I can move it if you prefer so :)

On the crawl logic, the problem is that the only way to operate with (let's say) DB data on invokables are either service initializers (making invokables implement SomethingAwareInterface, which is kinda crappy) or using static methods, which is a "game over" for me (once you got the static method in, good luck getting it out of there!). You can see some of those patterns applied in the old view helpers, like Zend_View_Helper_Action, where you just asked for an "action" plugin and the framework did all the inflection/file matching/autoloading things for you. Direct mapping via services allows instead to avoid that by following the patterns introduced in ZF2.

It is mainly related to educating the end user about good and bad approaches. The technique of crawling directories for invokables is a niche and you meet its limitations too easily :(

Rovak commented 11 years ago

For now i prefer to keep things in the Wiki, i may setup a Jenkins job later which syncs the docs files to the Wiki because i have to agree that cloning the docs together is helpful.

About the crawling, in our internal version we use a AbstractDirectService which is a lightweight AbstractController with a pluginmanager that contains ExtJS specific helpers. I mainly use Direct for really small PHP methods which call service methods, so i may not face the same problems as you are having.

There is a lot of room for improvement and i will create a new PR in which we can discuss further changes in the crawling as soon as this one is merged.

Ocramius commented 11 years ago

@Rovak fine by me :) I'm not saying "let's remove it". If you know what you are doing, then it's already fine. As said, it's more a matter of educating the end user. Will move on addressing your comments tomorrow, and then adding a new commit to remove any unused files/methods (to be reviewed, since it may be BC on your side)