[dev] Horde as a framework

Thu Nov 3 18:37:27 UTC 2011

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.

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.

Cheers,

Gunnar

>
> Luis Felipe
> -- 
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de