Shall we use Zend Framework in eShop?

English forums
1

Hi everybody,

I would like to point you to Erik’s blog post:
http://www.oxid-esales.com/en/news/blog/zend-framework-and-oxid-eshop

We are certainly thinking about using Zend Framework in OXID eShop. Erik enlightenes about some advantages and disadvantages - it is still not a clear case.

Thats why we want to know what you think about it.

Cheers

2

My first ideas about this question are:

  • Its better for me, if I learn more ZF and I hope the oxid code helps me.
    I think I need ZF more often… for other Projects :wink:
  • Very good international documentation.
  • ZF listen in marketing papers very nice. Good for Oxid-Company.
  • More or less easy to integrate third party applications which based on ZF, too… I guess then more or less only zend-auth and zend-acl needs to comunicate between this applications.
  • Much overhead, less Speed?
  • Many bugs on the beginning, of course.
  • No Smarty? Maybe good, then something like ‘$oObject->getInstance()->getValue’ is possible in templates without all the confusing assigns. :cool:

For me it listen more or less nice, but I think, that will be much work for the customers to update a tuned shop to this system.

3

Good idea using zf in future release of OXID. But (user like avenger) - please do not compare with magento (too complicated and not mature enough!!).

The problem of the last zf releases was a continously changing way of coding (bootstrap, db etc.). I hope this will have come to an end and then zf will be a very good choice for OXID. I have built several applications using zf and I will no longer miss it.

4

[QUOTE=ahaller;13235]The problem of the last zf releases was a continously changing way of coding (bootstrap, db etc.). [/QUOTE]

I think a non-continously and often changing way of coding is a desaster for a user. For a small non-commercial, non-developing and non-evolving project this might be ok. But i think for a shop system like Oxid there must be a long lasting, continuous and integrated solution. (Ok, i could find better worlds in german)

CYA
Firefax

5

[QUOTE=Firefax;13244]I think a non-continously and often changing way of coding is a desaster for a user. For a small non-commercial, non-developing and non-evolving project this might be ok. But i think for a shop system like Oxid there must be a long lasting, continuous and integrated solution.[/QUOTE]

I’ve read some threads and posts to those considerations and can understand the thoughts behind it.

But i had to agree with firefax: For me OXID is a system, that, since i started to use it, changes that often, that i am not sure, wehether it was the right decision to use it. Everything is changing that fast. If i start to build new features and extensions, i want to be sure, that i can use them in the next releases too.

6

Hi,

I am new to oxid. After (frustrating)working with typo3-shop extension, I was really happy to find a slim and fast solution.

Please keep it like this. It is so easy to extend the classes and modules.

In Addition to the arguments above, there is one point: If you use a third party framework, you are dependent on the framework in development, bugs and !security issues!. And all the developers too! Too much time will go into maintenance and updates.
The owner of the shop (customers of developers and designers) won’t pay for it.

I agree with jkrug. If you change too much the code-base, you may losse more community-members.

And: If I need my own dedicated server for a shop (Like Magento) I cannot use it.

Hjue

7

We are using ZF for various projects and find it would complement the current clean and well structured code of oxid.

There are several advantages of using ZF!

8

[QUOTE=bitconstructor;14658] There are several advantages of using ZF![/QUOTE]
Which ones???

9

Hi,

we have started making a spike solution, integrating Zend Framework into the latest version of OXID CE.

What is a spike solution ? see
http://www.extremeprogramming.org/rules/spike.html

In short: Quick try out to test feasibility. It’s not meant to be production code!

We are [B]not[/B] implementing Zend Framework in the shop as part of the normal “product development”. Meaning we are not writing production code here.

We feel that we have a lot of uncertainty about the technical consequences of using the ZF in OXID shop. Therefore we are doing this spike solution. We have also decided to make this an ‘public’ experiment. The svn will be readable for all.

Several people have expressed there opinions on using ZF or not. A lot of them on the premise that a total rewrite of the software is to done.
Let me add that using ZF does not mean we must use [B]everything [/B]ZF has. ZF is a component library. We can pick and choose what we want.

Everyone who is interested in the code, please have a look in the svn and tell us what you think of this. If you have ideas or suggestions how to use of ZF and where, tell us. Here or in the dev-general mail list.

Experiences gained from the spike solution will help us to make a decision [B]if[/B] we want to incorporate ZF or not. And which parts of ZF we want to start using.

Personally I think it doesn’t make sense to rewrite the shop completely new on top of ZF. There are advantages when using ZF. But as many shop owners already stated correctly here, a complete rewrite will have many grave disadvantages as well. There are many modules out there. Think of all the existing templates. That’s why I, currently, think that only a gradual incorporation into the shop and a smooth transition can be a possibility. That is, if we decide to go that way :smiley:

Regards,

Erik

10

[QUOTE=erik kort;14719]Let me add that using ZF does not mean we must use [B]everything [/B]ZF has. ZF is a component library. We can pick and choose what we want.[/QUOTE]
Is that really true???

How can you ensure then, that each and every ZF-based module can interact with OXID, what is imo the rationale of considering ZF after all?

I’d rather think that this is an “[B]all-or-nothing[/B]” problem, instead of a selective one.

11

In eFire we use parts of ZF. But definitely not everything.

I think the potential for modules is that modules can use components for which the shop framework has no alternative. Or shouldn’t provide one in the first place. Modules should extent the shop beyond the standard shop functionality. For instance the ZF web services classes who wrap API’s like Google, Amazon, Flickr, etc. The shop framework was never meant to provide stuff like that. I don’t want OXID to deplete our resources to develop similar wrapper classes for this API’s on the cost of writing less shop core code. But these kind of components can be a major help for modules who want to use them.

I think there is a third option to “[B]all-or-nothing[/B]”. Use ZF there where it benefits :D. Again, I don’t think we should do an all rewrite off the shop just for including ZF.

Erik

12

I believe, we are talking about 2 completely different aspects:

you seem to be looking at ZF-integration as a way to make the OXID shop-developper’s live (i.e. your’s!) easier.

However, I conclude from the discussion so far, that most people look at ZF-integration as a way to be able to interface [B]to the shop(!) [/B]with a sort of standard API and not the OXID API…

These are 2 totally different animals with imo also totally different requirements concerning the level of ZF.integration…

13

[QUOTE=avenger;14729]These are 2 totally different animals with imo also totally different requirements concerning the level of ZF.integration…[/QUOTE]

Yes, I agree. And exactly that I want to be part of this discussion to. What kind of ZF integration, if any, makes sense?

There are different scenarios for the core developers, for the module developers, and shop owners, etc. For the core developers for now there will be no direct benefit. Just extra work. Later it may pay of. The module developers benefit first from ZF. If done compatible to older module system :D. Shop owners will benefit indirectly. Only if there are benefits for the module developers, which translate in better, cheaper and ultimately more modules later on.

14

Hi,

see our preliminary report about the Spike Solution:
http://www.oxidforge.org/wiki/Zend_Framework_-_preliminary_report_October,_12th_2009

Regards

15

I think is not good idea to integrate ZF, its a bad idea. Integrate easy MVC and provide good docs so that users can integrate their own modules. Maybe I have just bad experience with Magento.

Good app are:

  • Easy
  • Light
  • Fast
  • Powerful
  • …and easy upgrades

ZF is not easy, is not fast and is not light (22M) and is not so powerful after all and upgrades will not be so easy too. In Magento is impossible to do upgrades, you are stuck with old ver.

Maybe CodeOgniter MVC is better than ZF. ShopIgniter coming out next early year will have CodeIgniter.

16

Hi,

[QUOTE=MrDavid;21174]Maybe CodeOgniter MVC is better than ZF. ShopIgniter coming out next early year will have CodeIgniter.[/QUOTE]

Well, actually OXID is already an own framework and uses MVC strictly… :wink:

Regards

17

[QUOTE=Marco Steinhaeuser;21180]Hi,
Well, actually OXID is already an own framework and uses MVC strictly… :wink:
Regards[/QUOTE]

This is great Marco. So have you already consider to go with ZF and answer of those question here:
http://www.oxidforge.org/wiki/Zend_Framework_-_preliminary_report_October,_12th_2009

The biggest driver for OXID in many decisions nowadays is to see if we can attract more people joining the eShop community.

  • What really OXID need is more serious Admin panel look, maybe more fancy (like Interspire shop have) - its a MUST to do list .
  • Default English language on the site and demo shop site
  • Better demo shop design
  • Better marketing, nobody know about OXID, and those who know they look and don’t see how powerful OXID is, because of the look and design in front and end panel.

I didn’t know that you can do great shop with OXID a half year ago, till now, today, when I saw references like this:

Half year ago I leaved a site OXID site without any impresion about shop. Admin panel look nasty. Now I’am here because Magento is stuck, is hard to maintain the code, hard to do upgrades, hard to implement module your own, no docs at all, no reply on forums, Prototype java, code is a mess, very slow shop, Magento is dead…etc.

You don’t need to implement ZF to attract more people, really.

Is there any OXID shop future roadmap?

18

Hi MrDavid,

right, we know that. Of course, for the next year a “cosmetical” refresh for the admin panel as well as for the store front end is on the plans but not implemented into a defined road map yet.
The road map for version 4.3.0 will be published at the beginning of the new year.

Regards

19

thank for reply Marco,

anyway, I don’t want to open new tread, so I’ll ask here.
I heard that is planing ver. Oxid 5.0, so is set any release date? new fetatures?