[Marco Steinhaeuser]

Hi everybody,

I would like to point you to Erik's blog post:
http://www.oxid-esales.com/en/news/b...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

[MBa]

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
- 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.

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.

[ahaller]

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.

[Firefax]

Originally Posted by ahaller

The problem of the last zf releases was a continously changing way of coding (bootstrap, db etc.).

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

[jkrug]

Originally Posted by Firefax

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.

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.

[hjue]

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

[bitconstructor]

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!

[avenger]

Originally Posted by bitconstructor

There are several advantages of using ZF!

Which ones????

[erik kort]

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 not 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 everything 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 if 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

Regards,

Erik

[avenger]

Originally Posted by erik kort

Let me add that using ZF does not mean we must use everything ZF has. ZF is a component library. We can pick and choose what we want.

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 "all-or-nothing" problem, instead of a selective one.