[Vtigercrm-developers] vt6 versus zf2

Wed Feb 20 01:04:16 PST 2013

*Porting Module From Vtiger 5 to Vtiger 6*

Adam said:

*I don't know about anybody else, but in order to migrate to vt6, I'm
> looking at:
> 1. rewrite sixteen custom modules*

Vtiger6 provides fallback implementation to standard actions and views for
Entity modules,
and let the module override this if required. The Entity module (following
vtlib guidelines on Vtiger 5) should continue to work without much changes
on Vtiger6.

Example:

   - Accounts (handlers for special actions / views are coded in module).
   - Assets (continue to work without any code implementation).

If you have implemented Extension modules on Vtiger5 and look forward to
make it work with Vtiger6 without re-implementing - use the option of
Embedding as documented. Look at (RecycleBin/MailManager implementation in
the code-base).

> *2. reimplement all vt5 patches for vt6*

Can you please share details on the vt5 patches you are referring too.

*Vtiger 6 Code Structure*

Adam said:

 *"Keep the vtiger6 code operational?"  How about keeping the vtiger5 code
> operational?!  You forked your own modules to create the vtiger6 subfolder.
> **This is the largest bowl of copy pasta I've ever encountered in fifteen
> years of professional development.** *

Vtiger 6 is completely rewritten from ground up following the MVC design.
So, we are puzzled as to what you mean by "largest bowl of copy paste". We
would love to understand it

New development on Vtiger 6 is much easier than on Vtiger 5. Though that is
the main yardstick that we are looking to measure ourselves against, we
also tried to ensure backward compatibility to the extent possible on the
new framework.

*It shows a grave lack of restraint and/or understanding of how to refactor
> a system while keeping it operational.*

As you can see from the above suggestions, we have tried to support
existing code as much as possible, by providing the fall back option.

*"No clues on where to start"*

Joe said:

*I think the biggest problem is the lack of transparency and knowledge. We
> have no idea what vtiger is doing, we have no participation in the changes
> being made, we don't even see them coming, all of a sudden you have months
> worth of work to understand a whole new set of rules and code base with no
> real clues as to where to start or continue.*

It is true that documentation is not fully complete. We are still working
on the Vtiger 6 code and will continue to share updates. As far as
transparency goes, we are giving it our best shot. For example, Vtiger 6
screenshots have been shared 8 months ago . And now, Vtiger 6 EA code base
has been shared since October and updated regularly as we continued the
development.

Developer Documentation, including porting tips, will be in much better
shape as we get close to the release.

Regards,
Prasad

On Wed, Feb 20, 2013 at 10:05 AM, Prasad <prasad at vtiger.com> wrote:

> Team,
>
> Thank you for participations on this thread,  I hope you did look at the
> wiki documentation that was targeted to capture the changes made:
>
>    - https://wiki.vtiger.com/index.php/Vtiger_6_Developer_Guide
>    - https://wiki.vtiger.com/index.php/Vtiger_6_Language_Translation
>
> As said, the code in SVN is under-development, our focus is primarily to
> get the Vtiger6 functionality
>  working (both module + settings) without disturbing the Vtiger5 runtime.
>
> Vtiger6 module folder structure should be much simpler than what is
> Vtiger5.
> We would be looking at refactoring and remove files which aren't required
> anymore.
>
> I hope this cleared the confusions?
>
> Regards,
> Prasad
>
> On Wed, Feb 20, 2013 at 3:33 AM, Joe Bordes <joe at tsolucio.com> wrote:
>
>>  It isn't a price to pay for forking, even if you have been playing by
>> the (scarce) rules it is still a nightmare. I think the biggest problem is
>> the lack of transparency and knowledge. We have no idea what vtiger is
>> doing, we have no participation in the changes being made, we don't even
>> see them coming, all of a sudden you have months worth of work to
>> understand a whole new set of rules and code base with no real clues as to
>> where to start or continue. You might just as well start with any other
>> code base from scratch. That said, we have nothing to reproach, we are here
>> because we want to, if you don't like it, change it. I'm sure you'll see
>> that it isn't easy at all.
>>
>> While we decide and try to keep pace, it does feel good to vent off a
>> little once in a while  :-)
>>
>> Joe
>> TSolucio
>>
>>
>> On 19/02/13 22:28, Richard Hills wrote:
>>
>> 1 - Unfortunately we're in the same boat. I am hoping that at least some
>> vtlib module migrations will be straight forward, however have ignored this
>> completely so far as I await a rc.
>> 2 - This is the price we pay for forking the base of the system right?
>>
>> On 20/02/13 10:14, Adam Heinz wrote:
>>
>> I don't know about anybody else, but in order to migrate to vt6, I'm
>> looking at:
>> 1. rewrite sixteen custom modules
>> 2. reimplement all vt5 patches for vt6
>>
>>  Without any sort of adapter to provide backwards compatibility, I am
>> forced to do all this work at once, instead of being able to spread it out
>> over time as I respond to our normal queue of bugs and feature requests.
>>  As far as one might "prefer one hard redesign, without compatibility,"
>> I think that's only true when you have a deprecation period to make the
>> transition.
>>
>>
>> On Tue, Feb 19, 2013 at 11:00 AM, Stefan Warnat <ich at stefanwarnat.de>wrote:
>>
>>>  I don't have look at details of the vtiger6 structure vtiger6 and I
>>> think it isn't a perfect system,
>>> but I think anything inside the modules directory will be deleted on
>>> release date and later modules will be only in vtiger6 directory.
>>>
>>> My experience is, that files from "modules" Directory won't be used
>>> inside new vtiger6 theme.
>>>
>>> But probably it's true, most/all vtiger developer prefer one hard
>>> redesign, without compatibility, before lots of little changes, which needs
>>> lots of tests/work with every version.
>>>
>>> Freelancer at Webdevelopment
>>>
>>> *Web*: http://www.stefanwarnat.de
>>> *Xing*: https://www.xing.com/profile/Stefan_Warnat2
>>> *eMail*: ich at stefanwarnat.de
>>> *
>>> Telefon*: 0162 / 2548568
>>> (Werktags 12 - 18 Uhr)
>>>
>>> Am 19.02.2013 16:36, schrieb Adam Heinz:
>>>
>>>  "Keep the vtiger6 code operational?"  How about keeping the vtiger5
>>> code operational?!  You forked your own modules to create the vtiger6
>>> subfolder.  I have no idea how I'm supposed to merge a branch that contains
>>> a partial copy of itself, much less attempt to preserve any sort of
>>> merge/edit history.  This is the largest bowl of copy pasta I've ever
>>> encountered in fifteen years of professional development.  It shows a grave
>>> lack of restraint and/or understanding of how to refactor a system while
>>> keeping it operational.
>>>
>>>
>>> On Mon, Feb 18, 2013 at 11:30 PM, Prasad <prasad at vtiger.com> wrote:
>>>
>>>> Adam,
>>>>
>>>>  We did have a look at several frameworks and evolved a simple one that
>>>> can give us better control to keep the vtiger6 code operational with
>>>> 5.x while
>>>> our dev-team is on making progress.
>>>>
>>>>  Please do share your feedback if you find anything essentially
>>>> lacking in vtiger6 framework.
>>>>
>>>>  Regards,
>>>> Prasad
>>>>
>>>>
>>>>  On Tue, Feb 19, 2013 at 3:06 AM, Adam Heinz <amh at metricwise.net>wrote:
>>>>
>>>>>  I'm poking around in vgcal right now and am extremely glad to see
>>>>> how much Zend code it uses.  Did you guys consider using ZendFramework 2
>>>>> MVC instead of rolling your own for vtiger6?
>>>>>
>>>>>
>>>>>
>>
>> _______________________________________________
>> http://www.vtiger.com/
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20130220/a29e78d1/attachment-0001.html 