Hi Henri, On 11/24/2010 11:46 AM, Henri Bergius wrote: > On Wed, Nov 24, 2010 at 12:32 PM, Tobias Schlitt <[email protected]> wrote:
>> Finally, when the design has been discussed here on the list, you can >> start adjusting the code to the result of the discussion. It might be, >> that this requires some refactoring to keep the new component open for >> further extension (open-close-principle) and some class name changes. > > Certainly. The names are now all midgardmvc-prefixed, and we use the > classical Midgard underscores-instead-of-CamelCase policy there. > http://www.midgard-project.org/documentation/concepts-midcom-specs-components-styleguide/ 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. >> We already have MvcTools, which provides interfaces for implementing a >> clean MVC and a dummy implementation of these interfaces. So, adding a >> second MVC component does not sound reasonable to me. Otherwise we will >> end up like PEAR. But maybe our MVC component can profit from the >> Midgard MVC somehow? > Yes, looking a bit more at MVCTools I think it is better to look at > using some of the classes there in our MVC, and contributing some > alternative implementations (like our route system) back to MVCTools. > This needs a bit more thought. That sounds great, especially contributing routing algorithms back. 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. >>> * Midgard provider for the Zeta Database layer >>> * Midgard provider for the Zeta authentication layer >> I'm not sure how this would fit into Zeta Components themselves. What >> exactly do you imagine? > Just like you have Database implementations for MySQL and Postgres you > could have one that talks to database via the Midgard abstraction. 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? What do you actually do in your DB abstraction? Maybe that Midgard could benefit from using our query abstraction? >>> * Maybe Alexey's PHP Application Server: >>> https://github.com/indeyets/appserver-in-php >> I'll have a look at that. The title sounds interesting, though. :) > It is indeed quite cool. You have a persistent PHP process which can > help to make things quite fast (though it means you really need to > know request isolation), and you don't need to mess with setting up a > web server. I use it for all my development servers, though not yet in > production. > > Alexey will be visiting us next week, so I'll pitch the idea of Zeta to him. So, the AppServer basically implements a HTTP server in PHP? Or is it more like SRM? >> The discussion about having a Repository component already came up once >> in a while on the old eZ Components list. I'd love to see a generic and >> flexible repository component for Zeta, but this must be very well >> thought out and maybe splitted up into several tie-in components. > That would be great. You already have some repository-related > functionality in Zeta, like Document, Tree, etc. so the question would > be mostly tying those together, with some Midgard repository concept > added to fill the gaps. It would be interesting to get some input from > the Jackalope (https://fosswiki.liip.ch/display/jackalope/Home) guys > as well. 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, …). Regards, Toby [1] http://tracker.arbitracker.org/arbit/browse_source/view/src/classes/ -- 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
