Hi, On Thu, Nov 25, 2010 at 7:45 PM, Tobias Schlitt <[email protected]> wrote: > we have some very strict guidelines here in order to ensure a consistent > feeling for all of our APIs to the developer. So, we would expect to you > change the classes to our naming and interface guidelines before they > can become a component.
Certainly. My current plan to ensure API compatibility to the Midgard end of things is to keep the old libraries there as "proxies" to the functionality moved over to Zeta components and naming conventions. > That sounds great, especially contributing routing algorithms back. Routing, configuration, templating. Lots of places where we could add our way of doing this as another MVCTools option. > You could also take a look at how Arbit [1] uses its own, more advanced, > implementation of the MvcTools interfaces. I like its implementation > quite much. Thanks! I certainly will. > Our database abstraction is fully based on PDO and our handler classes > actually extend PDO. So I doubt this would work, or am I wrong? In this case you'd have handlers that don't need PDO but provide compatible functionality. But this is probably not the first priority for us anyway... BTW, http://www.midgard-project.org/discussion/developer-forum/aligning_ourselves_with_zeta_components/ > What do you actually do in your DB abstraction? Maybe that Midgard could > benefit from using our query abstraction? Mainly the possibility to run PHP applications built on top of Zeta database functionality with Midgard as the storage layer. This would give you additional benefits like replication. Here's the Midgard query interface: http://www.midgard-project.org/documentation/midgardquerybuilder/ > So, the AppServer basically implements a HTTP server in PHP? Or is it > more like SRM? It is a persistent PHP application server, but one of the interface options it provides is HTTP. > I was more thinking of having a component which implements the > repository pattern [2] in some way and provides back end abstraction for > it, so you can seemlessly replace the implementation (e.g. a relational > database, a couch DB, JSR-170, Jackalope, …). Sounds interesting, yes. But indeed, JCR should provide some pointers on how to build such repository interface. Other option is CMIS, but that seems quite overcomplicated approach. You may want to look at this: http://dev.day.com/content/ddc/blog/2009/11/contentrepositories.html > Toby /Henri
