[dev] Horde as a framework

Thu Nov 3 22:32:15 UTC 2011

Em 03/11/11 16:37, Gunnar Wrobel escreveu:
> Quoting Luis Felipe Marzagao <lfbm.andamentos at gmail.com>:
>
>> Em 02/11/11 11:27, Jan Schneider escreveu:
>>>
>>> Zitat von Gunnar Wrobel <wrobel at horde.org>:
>>>
>>>> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>>>>
>>>>> Quoting Chuck Hagenbuch <chuck at horde.org>:
>>>>>
>>>>>> http://fabien.potencier.org/article/49/what-is-symfony2
>>>>>>
>>>>>> Good post and impressive list. This is where I think we lag 
>>>>>> behind as a framework, and where we have an opportunity to either 
>>>>>> leverage our own components - which are great, but which I 
>>>>>> personally have less time to work on these days - or to start 
>>>>>> using some of the symfony/zend/whatever components to replace our 
>>>>>> own and move faster. Obviously we used to leverage more PEAR libs 
>>>>>> and there were challenges to that, but maybe things have changed?
>>>>>>
>>>>>> Or maybe not. Mostly throwing this out for discussion.
>>>>>
>>>>> Personally, I would rather not start using another framework's 
>>>>> components unless there was a *really* good reason.
>>>>
>>>> I feel there are often many good reasons for borrowing from others :)
>>>>
>>>>> At least not for any type of major functionality. It's not so much 
>>>>> about NIH for me, but more about control. I like the fact that we 
>>>>> are using less and less PEAR libs.
>>>>
>>>> PEAR is a different thing. Most PEAR libraries are coded for PHP4 
>>>> and remained on that level. It is quite hard to integrate stuff 
>>>> like that into a modern component based PHP framework. Using stuff 
>>>> from another component based PHP framework is a different matter. 
>>>> Both Symfony 2 and Zend improved significantly in that area during 
>>>> this year. As did Horde with Horde 4.
>>>>
>>>>> While it *does* increase our workload a bit (more libraries to 
>>>>> maintain for one thing),
>>>>
>>>> This is not only about workload on our side but also about the 
>>>> progress on the other side. If we fork we are cut off from any 
>>>> advances the other side integrates into the code base. This may 
>>>> easily turn out to be the major problem of forking.
>>>>
>>>>> it gives us *way* more flexibility and control. ... and while it 
>>>>> might not always turn out this way, it should translate into less 
>>>>> time to work a bug/issue (no headaches with getting upstream to 
>>>>> even ack your question/bug report/patch etc...)
>>>>
>>>> I agree that working with upstream can be painful. Forking is the 
>>>> better alternative if working with upstream is a real problem. But 
>>>> I assume we only worked with PEAR so far. We never tried Zend or 
>>>> Symfony. Both communities are quite active.
>>>>
>>>>>
>>>>> Also, IMO, if we are going to continue to try to push Horde as not 
>>>>> just a groupware stack, but also a PHP framework, I'm not sure 
>>>>> borrowing another framework's libraries for any major 
>>>>> functionality would send the right signal.
>>>>
>>>> Quite the contrary. By showing we can *integrate* with other 
>>>> frameworks I believe it demonstrates that we are indeed a component 
>>>> based framework - not some monolithic blob. The integration of 
>>>> different component frameworks has been a hot topic during the 
>>>> second half of this year. People are interested in using the best 
>>>> there is - without looking at whether it is labelled "Zend", 
>>>> "Symnfony", or "Horde".
>>>>
>>>>> We may not have the same number of libraries, but those that we 
>>>>> *do* have are both extremely well thought out and designed to our 
>>>>> own high standards ... at least that's the hope ;)
>>>>
>>>> Every framework has its strength and weaknesses - and only limited 
>>>> manpower. Why not accept that fact and make the best of it? We have 
>>>> some very good components, yes - lets publish how to use those and 
>>>> how to integrate them with Symfony 2 or Zend.
>>>>
>> Let me hijack this discussion to give some input from the viewpoint 
>> of a completely beginner PHP developer and also a Horde code 
>> consumer. I think whatever the solution is (maintain its own 
>> components or borrow some of them elsewhere), the key element for 
>> growing and increasing the community is 'documentation' (at least for 
>> newcomers). When I looked up for frameworks as yii or symfony, what 
>> has caught my attention was the documentation (and even screencasts) 
>> available (for example: http://www.yiiframework.com/doc/guide/) and, 
>> thus, how easy it was to begin working with them, even if you know 
>> little about PHP, patterns or frameworks. The same thing is not true 
>> for Horde. Of course you can see it´s an awesome framework and once 
>> you catch the grasp of it, it´s really great and helpful, but if 
>> you´re a newcomer, you have to spend hours looking at code and trying 
>> to figure out what does what, sometimes without success. So the 
>> feeling is 'Horde is for pros'. The documentation on installing the 
>> groupware modules is great, but it would be greater if there was 
>> abundant documentation on developing with Horde. I think that is the 
>> main reason why, regardless of whether Horde has its own components 
>> or not, the horde community isn´t bigger. In fact, it looks like a 
>> miracle the entire project being maintained by few developers and I 
>> can imagine the massive work and amount of personal time each one of 
>> you has to endure in order to keep things working. Which may be the 
>> reason why there´s no time to spend on documentation. One thing leads 
>> to another. All of this to say publishing, creating examples and 
>> teaching how to work (develop) with Horde is, maybe, imho, the 
>> greatest way to improve Horde, make it popular, and get more help 
>> from the community, which could, in turn, ease your work.
>
> I would say that this is definitely the direction we are trying to 
> head into. We are aware that our framework does not have the 
> documentation base it would need to make it accessible in the same way 
> as Symfony or Zend.
>
> But you need to take our specific angle into account: For the Horde 
> project the framework aspect was never the main target. The driving 
> factor always were - and I would say they still are - the 
> applications. Yes, we now offer a component based application-driven 
> framework - but this is more like a surprising by-product :) I 
> consider it amazing that our application development gave rise to such 
> a decent set of components.
>
No doubt. And in fact the groupware is, imo, the best around. I´ve been 
using it in my company for almost 4 years with great success and I do 
not intend to change it. I just stumbled upon the documentation issue 
when I started to try to develop an in-house module.

> There are still a few things in the pipe: The horde-components helper 
> is now able to grab documentation we write on http://wiki.horde.org 
> into the "doc/" directory of our framework components. These can in 
> turn be written to our http://www.horde.org/libraries pages. The 
> necessary commits have not yet been made but that is one of the next 
> things on my list.
>
> Of course we still have to catch up on a lot of undocumented packages. 
> But I'm certain the situation will improve.
>
Very good to hear it!
> Cheers,
>
> Gunnar
>
>>
>> Luis Felipe
>> -- 
>> Horde developers mailing list
>> Frequently Asked Questions: http://horde.org/faq/
>> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
>