Hi Henri, On 11/25/2010 07:03 PM, Henri Bergius wrote: > 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. Of course it is important to keep BC for Midgard. I think a proxy solutions is very reasonable there, to allow for a smooth migration. However, from our library point of view we need to take care for all current and future users and therefore ensure a common approach to API design. Midgard users will of course benefit from this in future too, when they once start using Zeta. :) >> 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. Yeah, definitely. Just to be said: It won't always be easy, due to the facts mentioned above, but there is definitely much space for adding features. >> 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... That could be a plan. Not sure if one can emulate all of PDOs behavior. > BTW, > http://www.midgard-project.org/discussion/developer-forum/aligning_ourselves_with_zeta_components/ Yes, already saw this. Great stuff! :) I really love to see more people jump on the bandwagon of 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/ That looks more like a repository approach to me, so it would be an ideal first back end handler for a potential repository component. >> 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. Such a component, built in a generic way, sounds pretty cool to me. >> 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 Will take a look, yes. Very valuable input, thanks! Toby -- Tobias Schlitt http://schlitt.info GPG Key: 0xC462BC14 Want to hire me? Need quality assurance? http://qafoo.com eZ Components are Zeta Components now! http://bit.ly/9S7zbn
