http://www.magentohub.com/68/fix-run-into-500-internal-server-error-problem/

Пуснах и питане http://www.magentocommerce.com/boards/viewthread/22658/

Някакви идеи? От Хост.бг казаха, че не знаят някой при тях да го ползва Магентото. Честно казано след 4 дена борба – вярвам им…

И резултата http://shop.pm-co.net/ – мъка!

Пуснах и питане в Магентокомерс:
http://www.magentocommerce.com/boards/viewthread/22658

Нядавам се да успее някой да ми помогне :(

За CI не знам какви magic неща има, но като се има предвид PHP4 съвмесимостта, по-скоро може би ползват overload(), въпреки, че не съм гледал какво има в карантиите. Иначе пайпинга за викане на неща мене ме кефи — свикнал съм след дългите години работа с jQuery и … Rudolf ;)

Да не влизам в детайли, че пак ще стане някой дълъг коментар, обаче с нищо не съм съгласен от коментарите за Магенто ;) Определено не е инструмент за “малки магазинчета”. Коя от функционалсностите и възможностите вътри ти се струва излишна ?

В случай, че ще се използва за някакво просто сайтче, така или иначе таз променлива “умира” в един момент (след dispatch-a на controllera). Обаче, ако си седнеш да правиш малко по-сложна система понякога е по-удобно да си ползваш стандартния начин, които съществува примерно при ZF с $obj = new Class и в някой момент, можеш да го ънсетнеш/изчистиш.
Ако ти трябва някакво “репозитори за обекти” (ако мога така да го нареча), то при ZF си имаш Registry-то.

Имам напредвид, че ZF не се опитва да разширява езика (при CI, ако не се лъжа са ползвали доста от magic functions) и колкото и да е тази глезотия товари безмислено при CI. Пак казвам, при малък проект е незабележимо, но..при голям може да стане проблем.

..Магенто – “best new project” незнаех, но защо пък не. Като чисто нов проект, доста бързо се разви. Но между него и osCommerce има голяма разлика и това е в “performance”-a. Повечето потребители на отворен код, биха предпочели да ползват Магенто, като май той се оказва единствената поддържана алтернатива на osCommerce. Тук споменах за фючърите, защото в него има купища неща, някой хубави и удобни, но някой (в определени случай) ненужни. Те товарят + ZF (за един малък магазин) = доста изразходван перформънс.

Иначе това което написа:
“Един “фреймуърк” без истинско приложение е умряла работа.”
Абсолютно си прав, нищо чудно точно поради тази причина от Zend, да се опитват да добавят основно “екзотични” класове, а от там и наистина заприлича на PEAR.

Структурата на ZF и това, че всичко си има място — мааалко не съм съгласен. Много често се случва да няма единен подход при имената на класовете, и това е нещо, което като чета форума на Nabble, се оказва го виждат и други хора. Ако си разглеждал имплементацията на някои неща, ще видиш, че може би някои са направени излишно сложни. От друга страна, това е сравнително млада платформа, така че може би трябва да мине още малко време докато се изгладят ръбовете. Така или иначе, сега с представянето на namespace-овете проекта ще трябва да се преустрои ;)

За оптималност в ZF въобще не може да говорим. Не знам какво точно си гледал, но CI е оса, а ZF е прасе. Всички забелязват, че с всяка следващата версия, платформата става все по-бавна и по-тежка, и бях чел, че Уил Синклер специално ще обърне внимание на производителността в някоя от следващите (близки) версии.

За Магенто – не си ме разбрал, или аз не те разбирам. Вътре карантиите му наистина са някаква джунгла, но е едно от малкото приложения, в които ZF се използва. Един “фреймуърк” без истинско приложение е умряла работа. Иначе Магентото като продукт е супер. Не знам за какви бизнес модели приказваш – Магенто си е продукт, точно както OSCommerce. Само че Магенто лично на мен ми харесва много много повече, има много по-удобен интерфейс, и няколко иновативни решения (като функционалност). Ако не си чел за Source Forge 2008 Community Awards, Магенто е победител с “best new project”. И какво е “фючър” — “feature” ли ?

Като цяло, може би проблема да е бил основно под PHP4, но лично за мен самата структура, която ползва CI, не ми допада. Може би става за проект с 5 “почти статични” странички, но това си е нещо, което трябва да се реши според случая/проекта.

Относно ZF, доста луда работа е там. С удоволствие наблюдавам проекта от както се появи официално бетата. В началото имаха доста неща за дооправяне, малки проблеми като цяло, а начина на contribution-а към проекта е малко кофти и доста бавно стартираха. Впредвид, че са Zend и community-то, което се издигна в началото..бавно си беше. Нищо де, сега гледах са пооправили това-онова.
В ZF ми харесва, това че всичко си има място. Класовете, naming conventions..като цяло, по-голямата част от кода е написана по оптимално (от гледна точка перформънс), за разлика от CI. Тук обаче, перформънса има цена (така да се каже), докато в CI, всичко е някак си … “нахвърляно” и кода им е изключително малко, то е нормално в тази статия да “бъде бърз”. Реално ако се наложи да се ползва при малко по-голямо приложение (сайт), то … нещата определено ще се обърнат и ZF ще е по-добро решение :)

Както по-рано казах, важен е самият случай/проект, а не чак толкова Framework-a.

Оф..магенто..подкрепям те относно тази глупост. Не мисля, че е сериозно един еКомърс продукт да изглежда така. Кода на доста места е мазало, структурата на цялото приложение е малко нестандартна. Мисля, че опитът им да изпълнят стандартният бизнес модел при open source, чрез услуги беше добър. Но едва дали бих прибягнал да ползвам Магенто, защото с всеки изминал ден се блъскат редица ненужни функции, а това влияе на перформънс, а пък и секюрити. Както обичат да казват от 37signals, “1 нов фючър = 10 които ще последват”

Нека се опитам да обобща мнението ми, CI според мен не е сериозен фреймуърк, на които да може да се разчита за големи проекти. ZF, благодарение на структурата си е доста добър избор за големи проекти, поради причината, че кода е лесен за “четене” (както и трябва), стриктен, структуриран и прочие.
Лично аз за малък проект бих избрал symfony, а за нещо по-голямо ZF :)

От къде мога да разгледам какво има в CakePHP 2.0 ? На сайта намерих само 1.1 и 1.2, както и в trunk-a на svn-а:

https://svn.cakephp.org/repo/trunk/cake/