Re: [zeta-dev] Introducing myself
Hi Henri, On 11/24/2010 11:46 AM, Henri Bergius wrote: On Wed, Nov 24, 2010 at 12:32 PM, Tobias Schlitt tob...@schlitt.info 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 Schlitthttp://schlitt.infoGPG Key: 0xC462BC14 Want to hire me? Need quality assurance?http://qafoo.com eZ Components are Zeta Components now! http://bit.ly/9S7zbn
Re: [zeta-dev] Introducing myself
Hi Henri, On 11/25/2010 07:03 PM, Henri Bergius wrote: On Thu, Nov 25, 2010 at 7:45 PM, Tobias Schlitt tob...@schlitt.info 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 Schlitthttp://schlitt.infoGPG Key: 0xC462BC14 Want to hire me? Need quality assurance?http://qafoo.com eZ Components are Zeta Components now! http://bit.ly/9S7zbn
Re: [zeta-dev] Introducing myself
Hi Henri, On 11/23/2010 04:43 PM, Henri Bergius wrote: Just to introduce myself, I'm Henri Bergius, one of the core developers of the Midgard framework. Midgard is one of the oldest open source web frameworks / CMSs for PHP. Midgard is a bit unique that in addition to the actual web layer written in PHP we have a content repository[1] that our system uses for all persistent data storage written in C (well, Vala in the next iteration, but C is what Vala anyway generates), with PHP-level access coming from a specific extension. Midgard has always focused on clean URLs, flexible templating, valid mark-up, integration with third party web services and high level of security. Personally I've been frustrated for a long time with the lack of a generic PHP ecosystem. As PEAR has largely stagnated, almost all interesting library and tool work happens either in complete isolation or within more specific ecosystems like Drupal, ZF, Midgard etc. I see the introduction of Zeta Components into Apache as a promising development that might be the beginning of a generic PHP code-sharing ecosystem[2]. As such, this is an area that both myself, and the Midgard Project in general should be interested in. cool stuff and thanks a lot for your blog article. :) I'm pretty much looking forward to having you on board. So, how to get started? I guess the main thing is to get familiar with the existing Zeta Components, and then to start thinking of what of those we could use within our framework, and what parts of our framework could be contributed back to Zeta. Some low-hanging fruit could include: * Geolocation library: https://github.com/bergie/midgardmvc_helper_location This looks very interesting, indeed. To get into contributing, you will first have to provide two documents to the list for discussion: 1. Requirements 2. Design 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. The second document is created after the first has been finalized here on the list. It should contain an overview of the components design and code examples on how a user is expected to use the component later. As the code already exists, this will mainly be a matter of noting down the key ideas. 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. After that, the component is ready to be added. :) I saw Jerome already provided you with links to our developer docs. You will find loads of information there. * Our MVC framework: https://github.com/midgardproject/midgardmvc_core 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? * 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? * 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. :) If collaboration on some of these would sound good, I'll be happy to start the discussion in the Midgard end of things. 1: http://bergie.iki.fi/blog/what_is_a_content_repository/ 2: http://bergie.iki.fi/blog/php-finally_getting_an_ecosystem/ 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. Your blog article looks quite extensive, so I need to allocate some time to read it. Please feel free to discuss any potential addition to Zeta on the list. We are happy to see some people moving into the project. :) Please make sure to use a dedicated thread for each potential component. Best regards, Toby -- Tobias Schlitthttp://schlitt.infoGPG Key: 0xC462BC14 Want to hire me? Need quality assurance?http://qafoo.com eZ Components are Zeta Components now! http://bit.ly/9S7zbn
Re: [zeta-dev] Introducing myself
On Wed, Nov 24, 2010 at 12:32 PM, Tobias Schlitt tob...@schlitt.info 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: henri.berg...@gmail.com Microblog: http://www.qaiku.com/home/bergie/
[zeta-dev] Introducing myself
Hi, Just to introduce myself, I'm Henri Bergius, one of the core developers of the Midgard framework. Midgard is one of the oldest open source web frameworks / CMSs for PHP. Midgard is a bit unique that in addition to the actual web layer written in PHP we have a content repository[1] that our system uses for all persistent data storage written in C (well, Vala in the next iteration, but C is what Vala anyway generates), with PHP-level access coming from a specific extension. Midgard has always focused on clean URLs, flexible templating, valid mark-up, integration with third party web services and high level of security. Personally I've been frustrated for a long time with the lack of a generic PHP ecosystem. As PEAR has largely stagnated, almost all interesting library and tool work happens either in complete isolation or within more specific ecosystems like Drupal, ZF, Midgard etc. I see the introduction of Zeta Components into Apache as a promising development that might be the beginning of a generic PHP code-sharing ecosystem[2]. As such, this is an area that both myself, and the Midgard Project in general should be interested in. So, how to get started? I guess the main thing is to get familiar with the existing Zeta Components, and then to start thinking of what of those we could use within our framework, and what parts of our framework could be contributed back to Zeta. Some low-hanging fruit could include: * Geolocation library: https://github.com/bergie/midgardmvc_helper_location * Our MVC framework: https://github.com/midgardproject/midgardmvc_core * Midgard provider for the Zeta Database layer * Midgard provider for the Zeta authentication layer * Maybe Alexey's PHP Application Server: https://github.com/indeyets/appserver-in-php If collaboration on some of these would sound good, I'll be happy to start the discussion in the Midgard end of things. 1: http://bergie.iki.fi/blog/what_is_a_content_repository/ 2: http://bergie.iki.fi/blog/php-finally_getting_an_ecosystem/ -- Henri Bergius Motorcycle Adventures and Free Software http://bergie.iki.fi/ Skype: henribergius Jabber: henri.berg...@gmail.com Microblog: http://www.qaiku.com/home/bergie/
Re: [zeta-dev] Introducing myself
Hi Henri, On Tue, Nov 23, 2010 at 4:43 PM, Henri Bergius henri.berg...@iki.fi wrote: Hi, [...] So, how to get started? I guess the main thing is to get familiar with the existing Zeta Components, and then to start thinking of what of those we could use within our framework, and what parts of our framework could be contributed back to Zeta. Some low-hanging fruit could include: As you said, the very first thing to do is to get familiar with Zeta Components. But with regards to what you have already done with Midgard, I believe it will be a piece of cake. You have to start with ezcBase [1] for two reasons : 1. to get the whole idea of the autoload mechanism because can be quite confusing when it comes to add your own classes. 2. because this is the only dependency for any other component. If you need to get a helicopter view in order to understand how ZC are organized you can have a look at at talk Derick gave a while ago [2]. Maybe Tobias and Kore have more recent slides. * Geolocation library: https://github.com/bergie/midgardmvc_helper_location This one is really interesting. * Our MVC framework: https://github.com/midgardproject/midgardmvc_core If possible I would prefer getting only one MVC component in order to avoid confusion for users if they want to do MVC. This does not meant yours is bad at all, it just means that being able to compare differences with MVCTools [3] and your MVC framework would be ideal first. And then we could see how to manage with this, maybe we could integrate some parts of your system in MVCTools. This needs to be debated actually. Anyway welcome to the Zeta Components community :) 1. http://incubator.apache.org/zetacomponents/documentation/trunk/Base/tutorial.html 2. http://derickrethans.nl/talks/ezc-ezconf9.pdf 3. http://incubator.apache.org/zetacomponents/documentation/trunk/MvcTools/tutorial.html -- Jérôme Renard http://39web.fr | http://jrenard.info | http://twitter.com/jeromerenard
Re: [zeta-dev] Introducing myself
Hi,
On Tue, Nov 23, 2010 at 11:57 PM, Jerome Renard jerome.ren...@gmail.com wrote:
As you said, the very first thing to do is to get familiar with Zeta
Components.
But with regards to what you have already done with Midgard, I believe
it will be a piece of cake.
Yep. I'll do some experiments today, and start pitching the idea to
the rest of our community.
* Geolocation library: https://github.com/bergie/midgardmvc_helper_location
This one is really interesting.
Another that might fit into Zeta quite easily is the Forms library.
This also is a completely standalone package, though it has a helper
for autogenerating forms from Midgard2 schemas (which could be adapted
to Zeta database schemas too).
https://github.com/midgardproject/midgardmvc_helper_forms
http://www.qaiku.com/go/6nbc/
As these two have quite minimal external dependencies I guess they
would be the first potential contributions from us to Zeta. The other
pieces are a bit more interconnected, and some overlap with existing
Zeta stuff so probably it is best to work together first on the
simpler stuff and tackle those later.
If possible I would prefer getting only one MVC component in order to
avoid confusion
for users if they want to do MVC. This does not meant yours is bad at
all, it just means
that being able to compare differences with MVCTools [3] and your MVC
framework would
be ideal first. And then we could see how to manage with this, maybe
we could integrate
some parts of your system in MVCTools. This needs to be debated actually.
Agreed that multiple MVC implementations in Zeta doesn't sound like a
good idea. Actually, probably having any full MVC implementation there
doesn't make sense. Therefore the term MVCTools is a good choice, as
the project can provide common building blocks for different MVC/CMS
projects to implement :-)
On a quick look at MVCTools, Midgard MVC is conceptually, and in some
places also API-wise quite similar.
Here's the basic description of how our MVC works:
https://github.com/midgardproject/midgardmvc_core/blob/master/documentation/index.markdown
Some quick points:
* Routes work very similarly, though we use different URL mapping
syntax based on URI templates[1]. So this could be just another
MvcRoute implementation
* We also rely on a Request object, and use it for request isolation
(everything related to a request is kept in that object as we have to
support multiple requests within one PHP run)
* In Midgard MVC we have full subrequest support, so in your template
you can for example make a subrequest to display five latest news
items
* In our case Routing Information would also contain the matched
variables from the URL (so URL /news/meego/2 matched to a route
/news/{$category}/{$number} would provide array('category' = 'meego',
'number' = 2)
* Our routes are also used for generating URLs when applications want
to redirect or display links
* We do not require controllers to extend any baseclass as the
component interface is quite trivial
* In our case controller actions are named with pattern HTTP
verb_action name, so you can define separate action methods for
handling GET and POST (for example) for a route
* Controller's results in our case are just stored to a data array
in the controller, so actions don't return anything. In cases of
errors they're supposed to throw exceptions
* We have a concept similar to MvcTools Filters called Injectors. At
the moment you have only two of these: ones called after request has
been parsed but before controller is called, and ones after controller
has been run but before we go to templating
* Views is probably the area where our approaches diverge the most. In
Midgard the whole thing is run by template composition, where route
only provides aliasing information on how to handle element inclusion
in the template. We use TAL as the default templating system
Anyway welcome to the Zeta Components community :)
Thanks! The Midgard project has always been quite isolated from the
rest of the PHP world (though I guess many other similar projects are
also quite insular). Hopefully this collaboration can change things
:-)
Jérôme Renard
/Henri
1: http://tools.ietf.org/html/draft-gregorio-uritemplate-04
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.berg...@gmail.com
Microblog: http://www.qaiku.com/home/bergie/
