On Wed, Nov 24, 2010 at 12:32 PM, Tobias Schlitt <[email protected]> wrote: > The first doc should wrap up why such a library is needed and which use > cases it should satisfy. The idea here is that we first gather all > potential requirements before discussing a flexible design for the > component. As you already have working source code, noting down the > requirements you had in mind should be easy.
Ok, will do. Expect to see this mail today or tomorrow. > 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 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. >> * 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. >> * 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. > 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. > Toby /Henri -- Henri Bergius Motorcycle Adventures and Free Software http://bergie.iki.fi/ Skype: henribergius Jabber: [email protected] Microblog: http://www.qaiku.com/home/bergie/
