[zeta-dev] Autoloads and autoload file
Hi there, I've got a small reflexion about the base mechanism of ezcBase that allows us to add an outside repository of classes [1]. Actually, I manage manually my autoload file and as we discussed before with James Pic [2], it could be a good point to have an extend to this mechanism and get a real script that will get the whole mapping class/file for you. I've checked in ez how is done the ezpautoloads script that does the job and the strategy is the following : list all php files, tokenize it, extract class names and make the file. Is it the optimal solution ? Can we find a better way to link classes and files ? Max [1] http://ezcomponents.org/docs/tutorials/Base#adding-class-repositories-located-outside-ez-components-to-autoload-system [2] James Pic shared autoload script : #!/bin/sh scanPath="." if [[ $1 != "" ]]; then scanPath=$1; fi; echo " '\1',\ @"`; echo `find -L $scanPath -name "*php" | xargs grep "^abstract class " | sed -e "s...@\([^:]*\):abstract class \([^ ]*\).*@'\2' => '\1',\ @"`; echo `find -L $scanPath -name "*php" | xargs grep "^interface " | sed -e "s...@\([^:]*\):interface \([^ ]*\).*@'\2' => '\1',\ @"`; echo ");"; echo "?>";
Re: [zeta-dev] Autoloads and autoload file
Hi, On Wed, Nov 24, 2010 at 10:44 AM, Maxime Thomas wrote: > I've got a small reflexion about the base mechanism of ezcBase that allows > us to add an outside repository of classes [1]. Sounds like a good idea. A common complaint about PEAR packaging from for example Debian Policy is that you get PHP classes coming from native packages and PHP classes coming from PEAR packages jumbled together in /usr/share. If we want to be compliant with their policy then a normal deployment would have multiple roots, for example like: /usr/share/php/ZetaComponents /usr/share/php/MidgardMVC /usr/local/share/php/MyCoolApp > Max /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/
Re: [zeta-dev] Autoloads and autoload file
On 24. nov. 2010, at 09.44, Maxime Thomas wrote: […] > I've checked in ez how is done the ezpautoloads script that does the job and > the strategy is the following : list all php files, tokenize it, extract > class names and make the file. For production environments it makes sense, and we have been toying with the idea of adopting the scripts to also create a similar list, which could work with components. -- Regards, Ole Marius
Re: [zeta-dev] Autoloads and autoload file
On Wed, Nov 24, 2010 at 11:43 AM, Ole Marius Smestad wrote: > For production environments it makes sense, and we have been toying with the > idea of adopting the scripts to also create a similar list, > which could work with components. In regular situations you probably need two setups: * Production: Zeta Components and other classes coming from PEAR or native packages (I'd love to see Zeta in Debian as soon as there is an official Apache release) * Development: Zeta Components and other classes coming from various Git/SVN checkouts The paths are likely to be quite different in these two scenarios. For production setups the relevant Debian policies are quite interesting. I recently packaged OpenPSA (a Midgard-based business management suite) to Debian and the policies made things quite clear: http://webapps-common.alioth.debian.org/draft-php/html/ http://webapps-common.alioth.debian.org/draft/html/ > Ole Marius /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/
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 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] Proposal: Location component
Hi, As discussed in my introduction thread[1], I'd like to propose for the Midgard MVC location library[2] to be contributed to the Zeta Components stack as a new components. As a first step, here are the initial requirements for a location library. Introduction The purpose of this library is to make it easier for PHP developers to work with geolocation. Geolocation is one of the emerging trends in web development, with new possibilities rising from browser geolocation support. This library focuses on dealing with actual real-world locations and relations between them, not with map visualization. Requirements In the initial version the location library should only deal with geolocated points. To build full geoinformation systems there will be need for lines, connections and areas, but these can be added in later iterations of the library. The library should provide the following services: Spot A spot is an actual location on a map. This consists of WGS-84 latitude and longitude. Optionally spots may have an altitude, timestamp, accuracy and a human-readable description. Spot should also be able to calculate distance and direction to other spots, and to provide a bounding box around them at a given radius. For display purposes spots also need to provide a way to convert them to pretty-printed human-readable coordinates. Geocoding - Geocoding is a service for converting human-readable locations to actual coordinates (spots). There should be an interface for geocoding utilizing various online geocoding services like GeoNames and OpenStreetMap Nominatim. Users of the component should be able to create their own geocoding service implementations. Reverse geocoding - Reverse geocoding is a service for converting actual coordinates (spots) into human-readable locations. There should be an interface for reverse geocoding utilizing various online geocoding services like GeoNames and OpenStreetMap Nominatim. Users of the component should be able to create their own reverse geocoding service implementations. IP geocoding IP geocoding is a service for converting an IP address to an approximate geographical location of the network. This can be used to locate users of a website for instance, in cases where browser geolocationing is not possible. The IP geocoding interface should be able to talk to at least HostIP web service to perform geocoding. 1: http://mail-archives.apache.org/mod_mbox/incubator-zeta-dev/201011.mbox/%3caanlkti=2j_vhbrmc3x55ekkjojwtuq-=9ddms0zvn...@mail.gmail.com%3e 2: https://github.com/bergie/midgardmvc_helper_location
Re: [zeta-dev] Autoloads and autoload file
Actually, I was thinking about this autoloads script for an app as it's done with eZP. It could be part of the ezcBase as an independent script. My point was to challenge the ezpublish strategy and see how to integrate it into ezcBase. By the way, I understand the point to normalize that for a whole environment (if I correctly get it) and to follow a policy such as Debian's. I guess PHP is still the best option for this, but I cannot find a link between the files and the classes (as packages in Java) that can easily do the trick. If we can do that, and that's my next idea, we can purpose some easy extension mechanism using PHP's Reflection or replacing it, following our needs. Max 2010/11/24 Henri Bergius > On Wed, Nov 24, 2010 at 11:43 AM, Ole Marius Smestad wrote: > > For production environments it makes sense, and we have been toying with > the idea of adopting the scripts to also create a similar list, > > which could work with components. > > In regular situations you probably need two setups: > > * Production: Zeta Components and other classes coming from PEAR or > native packages (I'd love to see Zeta in Debian as soon as there is an > official Apache release) > * Development: Zeta Components and other classes coming from various > Git/SVN checkouts > > The paths are likely to be quite different in these two scenarios. > > For production setups the relevant Debian policies are quite > interesting. I recently packaged OpenPSA (a Midgard-based business > management suite) to Debian and the policies made things quite clear: > http://webapps-common.alioth.debian.org/draft-php/html/ > http://webapps-common.alioth.debian.org/draft/html/ > > > Ole Marius > > /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/ >
