You are viewing a plain text version of this content. The canonical link for it is here.
Posted to zeta-dev@incubator.apache.org by Henri Bergius <he...@iki.fi> on 2010/11/23 15:43:18 UTC
[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.bergius@gmail.com
Microblog: http://www.qaiku.com/home/bergie/
Re: [zeta-dev] Introducing myself
Posted by Henri Bergius <he...@iki.fi>.
Hi,
On Tue, Nov 23, 2010 at 11:57 PM, Jerome Renard <je...@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.bergius@gmail.com
Microblog: http://www.qaiku.com/home/bergie/
Re: [zeta-dev] Introducing myself
Posted by Jerome Renard <je...@gmail.com>.
Hi Henri,
On Tue, Nov 23, 2010 at 4:43 PM, Henri Bergius <he...@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
Posted by Tobias Schlitt <to...@schlitt.info>.
Hi Henri,
On 11/25/2010 07:03 PM, Henri Bergius wrote:
> On Thu, Nov 25, 2010 at 7:45 PM, Tobias Schlitt <to...@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 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
Re: [zeta-dev] Introducing myself
Posted by Henri Bergius <be...@apache.org>.
Hi,
On Thu, Nov 25, 2010 at 7:45 PM, Tobias Schlitt <to...@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.
> 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
Re: [zeta-dev] Introducing myself
Posted by Henri Bergius <be...@apache.org>.
Hi,
On Thu, Nov 25, 2010 at 7:45 PM, Tobias Schlitt <to...@schlitt.info> wrote:
> 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, …).
That would be PHPCR then: https://github.com/jackalope/phpcr
This would be a good time to start the conversation with the Liip people:
http://blog.liip.ch/archive/2010/12/03/php-content-repository-full-implementation-in-sight.html
> Toby
/Henri
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Microblog: http://www.qaiku.com/home/bergie/
Re: [zeta-dev] Introducing myself
Posted by Tobias Schlitt <to...@schlitt.info>.
Hi Henri,
On 11/24/2010 11:46 AM, Henri Bergius wrote:
> On Wed, Nov 24, 2010 at 12:32 PM, Tobias Schlitt <to...@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 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
Re: [zeta-dev] Introducing myself
Posted by Henri Bergius <be...@apache.org>.
On Wed, Nov 24, 2010 at 12:32 PM, Tobias Schlitt <to...@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.bergius@gmail.com
Microblog: http://www.qaiku.com/home/bergie/
Re: [zeta-dev] Introducing myself
Posted by Tobias Schlitt <to...@schlitt.info>.
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 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