It would be better if I don't forget to add the link to the gist

https://gist.github.com/896184

Goulwen
-----------------------------------------------------
Twitter : http://twitter.com/nautilebleu/
Skype : nautilebleu
Web : http://nautilebleu.tumblr.com/



2011/3/31 Nautile Bleu <[email protected]>:
>> We might keep the Request class workable but let it delegate the work to
>> a SF2:Request class, introduce a FronController class delegating to
>> several components of SF2 but still do its previous work and introduce a
>> Response class, delegating its work to a SF2:Response but still allowing
>> people to write echo in their ManagerComponent if they want : we will
>> just propose them a new (better) way of doing it.
>
> Just about the transition, I share the small method I wrote during the
> dev sprint that allows using a template without breaking the existing
> ? I just a small piece of code that allows to move the presentation in
> a template if wanted.
>
> So it can be a first step to introduce templates, and when everyone
> will have move its code in template, we can introduce a warning
> message about echoing directly from the ManagerComponent.
>
> It's a lot easier to add HTML (or even JS) if needed and also easier
> to understand than lots of <?php echo '<h1> Hi' . $name . '</h1><br/>'
> ; ?>
>
> Regards
>
> Goulwen
>
>
> -----------------------------------------------------
> Twitter : http://twitter.com/nautilebleu/
> Skype : nautilebleu
> Web : http://nautilebleu.tumblr.com/
>
>
>
> 2011/3/31  <[email protected]>:
>> Send Dev mailing list submissions to
>>        [email protected]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>        http://lists.chamilo.org/listinfo/dev
>> or, via email, send a message with subject or body 'help' to
>>        [email protected]
>>
>> You can reach the person managing the list at
>>        [email protected]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Dev digest..."
>>
>>
>> Today's Topics:
>>
>>   1. Re: A big dependency... Symfony2 (Nautile Bleu)
>>   2. Re: A big dependency... Symfony2 (Sven Vanpoucke)
>>   3. Re: A big dependency... Symfony2 (Systho)
>>   4. Re: A big dependency... Symfony2 (Laurent Opprecht)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 30 Mar 2011 22:55:48 +0200
>> From: Nautile Bleu <[email protected]>
>> Subject: Re: [chamilo-dev] A big dependency... Symfony2
>> To: [email protected]
>> Message-ID:
>>        <[email protected]>
>> Content-Type: text/plain; charset=UTF-8
>>
>>> Ok ... so this is a tough one. Please not that the following is a mildly
>>> sarcastic joke: while we're at it ... could we please just move to Java
>>> for Chamilo 2. That would solve most problems and frustrations and give
>>> us access to a complete set of widely supported libraries that have
>>> really proven themselves (Hibernate, anyone?)
>>
>> If leaves to change, I then preferred that we move to Python. Among
>> other advantages, it will give us lots of opportunities to revisit the
>> sketches of Monty Python :)
>>>
>>> Back to the serious world. I can see where this is coming from. Truth be
>>> told, if I had to restart today with Chamilo 2 ... or actually if I were
>>> the one starting ... then some other decisions might have been made.
>>> Sadly enough we've been around for a while now. I started working on
>>> Chamilo 2 back in February 2007. If my sources are correct that's about
>>> the time symfony 1.0 was released. Zend Framework 1.0 was released a few
>>> months later (somewhere in the summer of 2007 if memory serves me well?)
>>
>> Yes, we start working on our current LMS on june 2006 with symfony
>> 0.8. It's sad that at the time we don't know the Chamilo 2.0 project,
>> maybe we were able to merge our 2 projects.
>>
>>> So where does that leave us now: with a modest framework (and that's
>>> such a "heavy" word) which doesn't offer all the functionality giants
>>> like ZF or S offer, but doesn't really need it either IMO.
>>
>> My current perception is that new generation frameworks (SF2/ZF2)
>> doesn't do much, but try to do it well. The problem I see in current
>> Chamilo is that nearly all things that in SF/ZF are in Chamilo but in
>> a less polish and efficient way. So it's not really a question of
>> functionality scope, but rather having something easier to use, with
>> less code, more efficiently. Maybe it seems a huge project to change
>> so dramatically the project only to have something is more easy to
>> develop with, but in the other hand, pushing this logic to its end, we
>> would all use Moodle?
>>
>>> I'm not saying we should reinvent the wheel every single time, but at the 
>>> very
>>> least we should make sure the wheel fits our Cars (? Pixar / Disney). I
>>> welcome ideas like using the Doctrine DBAL for access to DBMS storage
>>> engines. But, and I could be wrong about this of course, to me there is
>>> big difference between actually using something for a specific piece of
>>> functionality and using it as the basis for your entire platform. I can
>>> live with (and like) the first, but the second, at this point in time
>>> ... well ... A (virtual) Bridge Too Far (even if it features Laurence
>>> Olivier and Michael Caine)
>>
>> It's clear that this have a Deep Impact (yes, I can also use movie
>> metaphor :p ) Moving to a SF2/ZF2 would take at least one year and
>> probably more (I would be happy if it would be available for june 2012
>> release)
>>
>>> You could simply use whatever you need from whichever framework as a
>>> library, but considering most of them are integrated solutions, that
>>> just seems like creating extra - unwanted - overhead.
>>
>> In fact, the way SF2 is built you can use just the Request component
>> without any other components (and so without other overhead) It's
>> really a bunch of components loosely coupled.
>> http://symfony.com/components
>>
>> It will also help a migration as parts of Chamilo can be replaced 
>> step-by-step.
>>
>>> Do we really want to have both the ZF classes for dealing with HTTP 
>>> Requests AND
>>> the  symfony classes for dealing with HTTP Requests included in our project?
>>> (in response too: why not have more then one in there)
>>
>> Personnally I would say no: just one. I don't see the interest to have
>> two libs to handle the same thing.
>>
>>>
>>> I know this all sounds quite negative, but sadly enough I have to work
>>> in the real world ... even though I'd much prefer to live in Utopia,
>>> where I can keep on breaking (a modest number of) things to move on to
>>> better architectures, ideas, concepts and whatnots.
>>
>> I'd say that you're wise and realistic. I want the best for chamilo2
>> but I also need something that works! It's good to have someone who
>> keep an eye on that as coordinator :)
>>
>>> Btw. what is the current status of (stable releases for) symfony 2
>>> and/or ZF 2?
>>
>> Don't know for ZF2 but SF2 is Preview Release 9. I know some people
>> currently use it in prod. But due to deadlines I consider to be
>> realistic (circa June 2012 for a full migration), it's not really a
>> problem.
>>
>> Regards,
>>
>> Goulwen
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 31 Mar 2011 08:17:12 +0200
>> From: Sven Vanpoucke <[email protected]>
>> Subject: Re: [chamilo-dev] A big dependency... Symfony2
>> To: [email protected]
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>
>> Hi All
>>
>> The last few days i took a big look at how symfony and doctrine work. I
>> must say that i'm impressed about the possibilities of the two frameworks.
>>
>> However... We are currently at the point where all the available
>> developers need to deliver something between july / september.  This
>> means that we do not have the resources to integrate an entire new
>> framework. I really really hope that after going in production and
>> solving the first production issues the core developers of the product
>> can spend some time again on these things.
>>
>> I do feel that using an entire framework at this stage of development is
>> as hans already stated just a bridge to far. This would mean that we
>> would need to change our entire architecture and i believe that if we
>> would do that we could really forget new releases in the following
>> years. I do agree that both SF2 / ZF2 have some very interesting
>> features but i propose that we try to learn as much as possible from
>> these frameworks so we can make our own chamilo framework even better.
>>
>> But if you can find me at least 20 developers who can maintain the
>> current product and fix all the remaining issues then i'm not opposed to
>> spend time on changing these things entirely ;)
>>
>> Best regards
>> Sven
>>
>> Op 30/03/11 22:55, Nautile Bleu schreef:
>>>> Ok ... so this is a tough one. Please not that the following is a mildly
>>>> sarcastic joke: while we're at it ... could we please just move to Java
>>>> for Chamilo 2. That would solve most problems and frustrations and give
>>>> us access to a complete set of widely supported libraries that have
>>>> really proven themselves (Hibernate, anyone?)
>>>>
>>> If leaves to change, I then preferred that we move to Python. Among
>>> other advantages, it will give us lots of opportunities to revisit the
>>> sketches of Monty Python :)
>>>
>>>> Back to the serious world. I can see where this is coming from. Truth be
>>>> told, if I had to restart today with Chamilo 2 ... or actually if I were
>>>> the one starting ... then some other decisions might have been made.
>>>> Sadly enough we've been around for a while now. I started working on
>>>> Chamilo 2 back in February 2007. If my sources are correct that's about
>>>> the time symfony 1.0 was released. Zend Framework 1.0 was released a few
>>>> months later (somewhere in the summer of 2007 if memory serves me well?)
>>>>
>>> Yes, we start working on our current LMS on june 2006 with symfony
>>> 0.8. It's sad that at the time we don't know the Chamilo 2.0 project,
>>> maybe we were able to merge our 2 projects.
>>>
>>>
>>>> So where does that leave us now: with a modest framework (and that's
>>>> such a "heavy" word) which doesn't offer all the functionality giants
>>>> like ZF or S offer, but doesn't really need it either IMO.
>>>>
>>> My current perception is that new generation frameworks (SF2/ZF2)
>>> doesn't do much, but try to do it well. The problem I see in current
>>> Chamilo is that nearly all things that in SF/ZF are in Chamilo but in
>>> a less polish and efficient way. So it's not really a question of
>>> functionality scope, but rather having something easier to use, with
>>> less code, more efficiently. Maybe it seems a huge project to change
>>> so dramatically the project only to have something is more easy to
>>> develop with, but in the other hand, pushing this logic to its end, we
>>> would all use Moodle?
>>>
>>>
>>>> I'm not saying we should reinvent the wheel every single time, but at the 
>>>> very
>>>> least we should make sure the wheel fits our Cars (? Pixar / Disney). I
>>>> welcome ideas like using the Doctrine DBAL for access to DBMS storage
>>>> engines. But, and I could be wrong about this of course, to me there is
>>>> big difference between actually using something for a specific piece of
>>>> functionality and using it as the basis for your entire platform. I can
>>>> live with (and like) the first, but the second, at this point in time
>>>> ... well ... A (virtual) Bridge Too Far (even if it features Laurence
>>>> Olivier and Michael Caine)
>>>>
>>> It's clear that this have a Deep Impact (yes, I can also use movie
>>> metaphor :p ) Moving to a SF2/ZF2 would take at least one year and
>>> probably more (I would be happy if it would be available for june 2012
>>> release)
>>>
>>>
>>>> You could simply use whatever you need from whichever framework as a
>>>> library, but considering most of them are integrated solutions, that
>>>> just seems like creating extra - unwanted - overhead.
>>>>
>>> In fact, the way SF2 is built you can use just the Request component
>>> without any other components (and so without other overhead) It's
>>> really a bunch of components loosely coupled.
>>> http://symfony.com/components
>>>
>>> It will also help a migration as parts of Chamilo can be replaced 
>>> step-by-step.
>>>
>>>
>>>> Do we really want to have both the ZF classes for dealing with HTTP 
>>>> Requests AND
>>>> the  symfony classes for dealing with HTTP Requests included in our 
>>>> project?
>>>> (in response too: why not have more then one in there)
>>>>
>>> Personnally I would say no: just one. I don't see the interest to have
>>> two libs to handle the same thing.
>>>
>>>
>>>> I know this all sounds quite negative, but sadly enough I have to work
>>>> in the real world ... even though I'd much prefer to live in Utopia,
>>>> where I can keep on breaking (a modest number of) things to move on to
>>>> better architectures, ideas, concepts and whatnots.
>>>>
>>> I'd say that you're wise and realistic. I want the best for chamilo2
>>> but I also need something that works! It's good to have someone who
>>> keep an eye on that as coordinator :)
>>>
>>>
>>>> Btw. what is the current status of (stable releases for) symfony 2
>>>> and/or ZF 2?
>>>>
>>> Don't know for ZF2 but SF2 is Preview Release 9. I know some people
>>> currently use it in prod. But due to deadlines I consider to be
>>> realistic (circa June 2012 for a full migration), it's not really a
>>> problem.
>>>
>>> Regards,
>>>
>>> Goulwen
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [email protected]
>>> http://lists.chamilo.org/listinfo/dev
>>>
>>
>>
>> --
>> Met vriendelijke groeten
>>
>> Sven Vanpoucke
>> Digitaal Leren
>> Directie Onderwijs
>> Hogeschool Gent
>> http://digitaal-leren.hogent.be/
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Thu, 31 Mar 2011 09:19:36 +0200
>> From: Systho <[email protected]>
>> Subject: Re: [chamilo-dev] A big dependency... Symfony2
>> Cc: [email protected]
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>
>> Hi all,
>>
>> I think my question has derived a little bit so may I have your opinion
>> about the following idea :
>>
>> Not breaking anything but doing the same things we did before by
>> delegating to components from SF2. or ZF2.0. Then mark the still working
>> way of doing stuff deprecated and propose a new way.
>>
>> As most of you know my main concern is automated tests and the
>> froncontroller/request/response stuff.
>>
>> We might keep the Request class workable but let it delegate the work to
>> a SF2:Request class, introduce a FronController class delegating to
>> several components of SF2 but still do its previous work and introduce a
>> Response class, delegating its work to a SF2:Response but still allowing
>> people to write echo in their ManagerComponent if they want : we will
>> just propose them a new (better) way of doing it.
>>
>> If the size of the dependency is not a problem (none of you stated it
>> is), then from my POV the only problem left is that we might finish with
>> a lot of dependency :
>>
>> SF2.0 for request handling / ZF2.0 for templating / CodeIgniter for
>> logging / ....
>>
>> I think it is not a problem as long as we hide those dependencies behind
>> custom adapter classes but your opinion would be highly valuable before
>> I begin the work ;)
>>
>> Systho
>> Le 31/03/2011 8:17, Sven Vanpoucke a ?crit :
>>> Hi All
>>>
>>> The last few days i took a big look at how symfony and doctrine work.
>>> I must say that i'm impressed about the possibilities of the two
>>> frameworks.
>>>
>>> However... We are currently at the point where all the available
>>> developers need to deliver something between july / september.  This
>>> means that we do not have the resources to integrate an entire new
>>> framework. I really really hope that after going in production and
>>> solving the first production issues the core developers of the product
>>> can spend some time again on these things.
>>>
>>> I do feel that using an entire framework at this stage of development
>>> is as hans already stated just a bridge to far. This would mean that
>>> we would need to change our entire architecture and i believe that if
>>> we would do that we could really forget new releases in the following
>>> years. I do agree that both SF2 / ZF2 have some very interesting
>>> features but i propose that we try to learn as much as possible from
>>> these frameworks so we can make our own chamilo framework even better.
>>>
>>> But if you can find me at least 20 developers who can maintain the
>>> current product and fix all the remaining issues then i'm not opposed
>>> to spend time on changing these things entirely ;)
>>>
>>> Best regards
>>> Sven
>>>
>>> Op 30/03/11 22:55, Nautile Bleu schreef:
>>>>> Ok ... so this is a tough one. Please not that the following is a
>>>>> mildly
>>>>> sarcastic joke: while we're at it ... could we please just move to Java
>>>>> for Chamilo 2. That would solve most problems and frustrations and give
>>>>> us access to a complete set of widely supported libraries that have
>>>>> really proven themselves (Hibernate, anyone?)
>>>> If leaves to change, I then preferred that we move to Python. Among
>>>> other advantages, it will give us lots of opportunities to revisit the
>>>> sketches of Monty Python :)
>>>>> Back to the serious world. I can see where this is coming from.
>>>>> Truth be
>>>>> told, if I had to restart today with Chamilo 2 ... or actually if I
>>>>> were
>>>>> the one starting ... then some other decisions might have been made.
>>>>> Sadly enough we've been around for a while now. I started working on
>>>>> Chamilo 2 back in February 2007. If my sources are correct that's about
>>>>> the time symfony 1.0 was released. Zend Framework 1.0 was released a
>>>>> few
>>>>> months later (somewhere in the summer of 2007 if memory serves me
>>>>> well?)
>>>> Yes, we start working on our current LMS on june 2006 with symfony
>>>> 0.8. It's sad that at the time we don't know the Chamilo 2.0 project,
>>>> maybe we were able to merge our 2 projects.
>>>>
>>>>> So where does that leave us now: with a modest framework (and that's
>>>>> such a "heavy" word) which doesn't offer all the functionality giants
>>>>> like ZF or S offer, but doesn't really need it either IMO.
>>>> My current perception is that new generation frameworks (SF2/ZF2)
>>>> doesn't do much, but try to do it well. The problem I see in current
>>>> Chamilo is that nearly all things that in SF/ZF are in Chamilo but in
>>>> a less polish and efficient way. So it's not really a question of
>>>> functionality scope, but rather having something easier to use, with
>>>> less code, more efficiently. Maybe it seems a huge project to change
>>>> so dramatically the project only to have something is more easy to
>>>> develop with, but in the other hand, pushing this logic to its end, we
>>>> would all use Moodle?
>>>>
>>>>> I'm not saying we should reinvent the wheel every single time, but
>>>>> at the very
>>>>> least we should make sure the wheel fits our Cars (? Pixar / Disney). I
>>>>> welcome ideas like using the Doctrine DBAL for access to DBMS storage
>>>>> engines. But, and I could be wrong about this of course, to me there is
>>>>> big difference between actually using something for a specific piece of
>>>>> functionality and using it as the basis for your entire platform. I can
>>>>> live with (and like) the first, but the second, at this point in time
>>>>> ... well ... A (virtual) Bridge Too Far (even if it features Laurence
>>>>> Olivier and Michael Caine)
>>>> It's clear that this have a Deep Impact (yes, I can also use movie
>>>> metaphor :p ) Moving to a SF2/ZF2 would take at least one year and
>>>> probably more (I would be happy if it would be available for june 2012
>>>> release)
>>>>
>>>>> You could simply use whatever you need from whichever framework as a
>>>>> library, but considering most of them are integrated solutions, that
>>>>> just seems like creating extra - unwanted - overhead.
>>>> In fact, the way SF2 is built you can use just the Request component
>>>> without any other components (and so without other overhead) It's
>>>> really a bunch of components loosely coupled.
>>>> http://symfony.com/components
>>>>
>>>> It will also help a migration as parts of Chamilo can be replaced
>>>> step-by-step.
>>>>
>>>>> Do we really want to have both the ZF classes for dealing with HTTP
>>>>> Requests AND
>>>>> the  symfony classes for dealing with HTTP Requests included in our
>>>>> project?
>>>>> (in response too: why not have more then one in there)
>>>> Personnally I would say no: just one. I don't see the interest to have
>>>> two libs to handle the same thing.
>>>>
>>>>> I know this all sounds quite negative, but sadly enough I have to work
>>>>> in the real world ... even though I'd much prefer to live in Utopia,
>>>>> where I can keep on breaking (a modest number of) things to move on to
>>>>> better architectures, ideas, concepts and whatnots.
>>>> I'd say that you're wise and realistic. I want the best for chamilo2
>>>> but I also need something that works! It's good to have someone who
>>>> keep an eye on that as coordinator :)
>>>>
>>>>> Btw. what is the current status of (stable releases for) symfony 2
>>>>> and/or ZF 2?
>>>> Don't know for ZF2 but SF2 is Preview Release 9. I know some people
>>>> currently use it in prod. But due to deadlines I consider to be
>>>> realistic (circa June 2012 for a full migration), it's not really a
>>>> problem.
>>>>
>>>> Regards,
>>>>
>>>> Goulwen
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> [email protected]
>>>> http://lists.chamilo.org/listinfo/dev
>>>
>>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Thu, 31 Mar 2011 09:24:37 +0200
>> From: Laurent Opprecht <[email protected]>
>> Subject: Re: [chamilo-dev] A big dependency... Symfony2
>> To: [email protected]
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>
>> Let's me add my two cents there.
>>
>> While SF or ZF may be  good frameworks what would be the tangible
>> benefits to move to any of them? That is beside making us happy to know
>> we are using the latest trend in development framework. And, would those
>> benefits offset the effort to do a major refactoring, once again should
>> I say? Could we decrease code size significantly? Could we implement new
>> functionalities, for example templates a la smarty, that would be
>> visible to the end user?
>>
>> I am certainly not against assessing those two frameworks and possibly
>> moving to them but only once we have completed the work at hand. I
>> certainly aggree that for now we should focus on supporting production
>> moves. That is correcting bugs, adding needed new functionalities, etc.
>>
>> Then I think it would help to see a few examples on how we could use any
>> of those two framework to make our life easier. Personnaly I don't have
>> enough time at hand to have a deep look into those frameworks so having
>> a few examples would help me make an opinion.
>>
>> Cheers
>>
>>
>> Le 31.03.2011 08:17, Sven Vanpoucke a ?crit :
>>> Hi All
>>>
>>> The last few days i took a big look at how symfony and doctrine work.
>>> I must say that i'm impressed about the possibilities of the two
>>> frameworks.
>>>
>>> However... We are currently at the point where all the available
>>> developers need to deliver something between july / september.  This
>>> means that we do not have the resources to integrate an entire new
>>> framework. I really really hope that after going in production and
>>> solving the first production issues the core developers of the product
>>> can spend some time again on these things.
>>>
>>> I do feel that using an entire framework at this stage of development
>>> is as hans already stated just a bridge to far. This would mean that
>>> we would need to change our entire architecture and i believe that if
>>> we would do that we could really forget new releases in the following
>>> years. I do agree that both SF2 / ZF2 have some very interesting
>>> features but i propose that we try to learn as much as possible from
>>> these frameworks so we can make our own chamilo framework even better.
>>>
>>> But if you can find me at least 20 developers who can maintain the
>>> current product and fix all the remaining issues then i'm not opposed
>>> to spend time on changing these things entirely ;)
>>>
>>> Best regards
>>> Sven
>>>
>>> Op 30/03/11 22:55, Nautile Bleu schreef:
>>>>> Ok ... so this is a tough one. Please not that the following is a
>>>>> mildly
>>>>> sarcastic joke: while we're at it ... could we please just move to Java
>>>>> for Chamilo 2. That would solve most problems and frustrations and give
>>>>> us access to a complete set of widely supported libraries that have
>>>>> really proven themselves (Hibernate, anyone?)
>>>> If leaves to change, I then preferred that we move to Python. Among
>>>> other advantages, it will give us lots of opportunities to revisit the
>>>> sketches of Monty Python :)
>>>>> Back to the serious world. I can see where this is coming from.
>>>>> Truth be
>>>>> told, if I had to restart today with Chamilo 2 ... or actually if I
>>>>> were
>>>>> the one starting ... then some other decisions might have been made.
>>>>> Sadly enough we've been around for a while now. I started working on
>>>>> Chamilo 2 back in February 2007. If my sources are correct that's about
>>>>> the time symfony 1.0 was released. Zend Framework 1.0 was released a
>>>>> few
>>>>> months later (somewhere in the summer of 2007 if memory serves me
>>>>> well?)
>>>> Yes, we start working on our current LMS on june 2006 with symfony
>>>> 0.8. It's sad that at the time we don't know the Chamilo 2.0 project,
>>>> maybe we were able to merge our 2 projects.
>>>>
>>>>> So where does that leave us now: with a modest framework (and that's
>>>>> such a "heavy" word) which doesn't offer all the functionality giants
>>>>> like ZF or S offer, but doesn't really need it either IMO.
>>>> My current perception is that new generation frameworks (SF2/ZF2)
>>>> doesn't do much, but try to do it well. The problem I see in current
>>>> Chamilo is that nearly all things that in SF/ZF are in Chamilo but in
>>>> a less polish and efficient way. So it's not really a question of
>>>> functionality scope, but rather having something easier to use, with
>>>> less code, more efficiently. Maybe it seems a huge project to change
>>>> so dramatically the project only to have something is more easy to
>>>> develop with, but in the other hand, pushing this logic to its end, we
>>>> would all use Moodle?
>>>>
>>>>> I'm not saying we should reinvent the wheel every single time, but
>>>>> at the very
>>>>> least we should make sure the wheel fits our Cars (? Pixar / Disney). I
>>>>> welcome ideas like using the Doctrine DBAL for access to DBMS storage
>>>>> engines. But, and I could be wrong about this of course, to me there is
>>>>> big difference between actually using something for a specific piece of
>>>>> functionality and using it as the basis for your entire platform. I can
>>>>> live with (and like) the first, but the second, at this point in time
>>>>> ... well ... A (virtual) Bridge Too Far (even if it features Laurence
>>>>> Olivier and Michael Caine)
>>>> It's clear that this have a Deep Impact (yes, I can also use movie
>>>> metaphor :p ) Moving to a SF2/ZF2 would take at least one year and
>>>> probably more (I would be happy if it would be available for june 2012
>>>> release)
>>>>
>>>>> You could simply use whatever you need from whichever framework as a
>>>>> library, but considering most of them are integrated solutions, that
>>>>> just seems like creating extra - unwanted - overhead.
>>>> In fact, the way SF2 is built you can use just the Request component
>>>> without any other components (and so without other overhead) It's
>>>> really a bunch of components loosely coupled.
>>>> http://symfony.com/components
>>>>
>>>> It will also help a migration as parts of Chamilo can be replaced
>>>> step-by-step.
>>>>
>>>>> Do we really want to have both the ZF classes for dealing with HTTP
>>>>> Requests AND
>>>>> the  symfony classes for dealing with HTTP Requests included in our
>>>>> project?
>>>>> (in response too: why not have more then one in there)
>>>> Personnally I would say no: just one. I don't see the interest to have
>>>> two libs to handle the same thing.
>>>>
>>>>> I know this all sounds quite negative, but sadly enough I have to work
>>>>> in the real world ... even though I'd much prefer to live in Utopia,
>>>>> where I can keep on breaking (a modest number of) things to move on to
>>>>> better architectures, ideas, concepts and whatnots.
>>>> I'd say that you're wise and realistic. I want the best for chamilo2
>>>> but I also need something that works! It's good to have someone who
>>>> keep an eye on that as coordinator :)
>>>>
>>>>> Btw. what is the current status of (stable releases for) symfony 2
>>>>> and/or ZF 2?
>>>> Don't know for ZF2 but SF2 is Preview Release 9. I know some people
>>>> currently use it in prod. But due to deadlines I consider to be
>>>> realistic (circa June 2012 for a full migration), it's not really a
>>>> problem.
>>>>
>>>> Regards,
>>>>
>>>> Goulwen
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> [email protected]
>>>> http://lists.chamilo.org/listinfo/dev
>>>
>>>
>>
>>
>> --
>> ____________________________________
>> Meilleures salutations
>>
>> Laurent Opprecht
>> chat: [email protected]
>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: laurent_opprecht.vcf
>> Type: text/x-vcard
>> Size: 404 bytes
>> Desc: not available
>> URL: 
>> <http://lists.chamilo.org/pipermail/dev/attachments/20110331/9d011956/attachment.vcf>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Dev mailing list
>> [email protected]
>> http://lists.chamilo.org/listinfo/dev
>>
>>
>> End of Dev Digest, Vol 14, Issue 25
>> ***********************************
>>
>

_______________________________________________
Dev mailing list
[email protected]
http://lists.chamilo.org/listinfo/dev

Reply via email to