[Vtigercrm-developers] vt6 versus zf2

[Prasad]

Adam,


> Reading through the wiki documentation you posted yesterday, I see what
> you describe, but I haven't seen anything of the sort working on my test
> vt6 server.  I'll try to take a closer look later this week and report back.


Look forward for your feedback.

Sorry, I wasn't clear -- vt5 = copy pasta, not vt6.  The point I was trying
> to make wasn't bashing the vt6 codebase; I was attempting to point out that
> you're making this MVC refactoring more difficult than it needs to be.


I'm not clear about the complexity you are referring too, I would wait for
your feedback after you having a closer look.

In 5.4, I saw you guys start to do the kind of refactoring that I like to
> see: you went through all the modules and replaced ListView.php copy pasta
> with require_once('modules/Vtiger/ListView.php');  It's not glamorous, it
> doesn't feel like you're accomplishing as much as "rip and replace", but
> guess what?  That change didn't cause any disruption.  Everyone got a
> leaner, more maintainable codebase and barely noticed!  You could have done
> the same thing with a MVC refactoring; built only the "fallback to vt5"
> piece, and shipped it!  There would be no vt5/vt6 toggle, vt6 would always
> be in fallback mode!  Instead you have put yourself in a position where
> nobody trusts the virgin, untested vt6 code.


VT5 templates (views) has its deeps roots with library like prototype,
scriptaculous etc..., in VT6 we have introduced better libraries like
jQuery and take advantage of CSS framework like bootstrap along with the
ability to roll better layouts down-the-road. Such a massive change
wouldn't be possible with VT5 template refactoring. It would end-up with
just a rewrite as well.

Although, in VT5 we did reduce the ListView.php code-redundancy in most
traditional way we certainly wanted to bring in the OOP into the core
(similar to what vtlib API had followed). That would give better flow
detection and ability to extend behavior which would not be possible
otherwise.

We are gathering regular feedback on VT6 and rolling updates to the code.
The EA (early access) on SVN was to get more hands to make the product more
mature and stable for release. We would not be releasing a half-baked
product.

One of my college professors taught me a great lesson years ago, that no
> complex system (that works) is built from scratch.  You can only build it
> from a simpler system (that works).


Thanks for sharing your learning - certainly a good one.

I have made my best attempt to capture your thought process, feel free to
correct me if I have stepped in a wrong direction with respect to it. In
case you need more clarity my comments don't hesitate to ask.

Regards,
Prasad

On Wed, Feb 20, 2013 at 9:25 PM, Adam Heinz <amh at metricwise.net> wrote:

>
> On Wed, Feb 20, 2013 at 4:04 AM, Prasad <prasad at vtiger.com> wrote:
>
>> 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.
>>
>
> Reading through the wiki documentation you posted yesterday, I see what
> you describe, but I haven't seen anything of the sort working on my test
> vt6 server.  I'll try to take a closer look later this week and report back.
>
>
>> Can you please share details on the vt5 patches you are referring too.
>>
>
> Start with my two dozen or so unaccepted patches in Trac, then add several
> hundred more that I haven't bothered to (or am unable to) submit.
>
>
>> 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
>>
>
> Sorry, I wasn't clear -- vt5 = copy pasta, not vt6.  The point I was
> trying to make wasn't bashing the vt6 codebase; I was attempting to point
> out that you're making this MVC refactoring more difficult than it needs to
> be.
>
> In 5.4, I saw you guys start to do the kind of refactoring that I like to
> see: you went through all the modules and replaced ListView.php copy pasta
> with require_once('modules/Vtiger/ListView.php');  It's not glamorous, it
> doesn't feel like you're accomplishing as much as "rip and replace", but
> guess what?  That change didn't cause any disruption.  Everyone got a
> leaner, more maintainable codebase and barely noticed!  You could have done
> the same thing with a MVC refactoring; built only the "fallback to vt5"
> piece, and shipped it!  There would be no vt5/vt6 toggle, vt6 would always
> be in fallback mode!  Instead you have put yourself in a position where
> nobody trusts the virgin, untested vt6 code.
>
> One of my college professors taught me a great lesson years ago, that no
> complex system (that works) is built from scratch.  You can only build it
> from a simpler system (that works).
>
> _______________________________________________
> http://www.vtiger.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20130221/0f98060a/attachment.html