No comment. You can use your imagination here ... maybe I thought of the idea 5m before you posted... maybe I've been thinking about it for 5yrs and am lazy? .... rather than trying to list all the reasons why not to do it.... id rather only think of reasons why i should.
I didn't mean anything by that comment, I was simply asking, incase, you found alternatives, difficulties, etc.
Implementing a truly fleixble eCommerce solution is much like building Joomla/Drupal but gear towards eCommerce not general CMS.
What's your first choice?
My own controller framework, of course. Zend is just over engineered, IMO. I have yet to extract the dispatching from the core front, but thats coming, and even when I do, the codebase is a fraction of Zend implementation in terms of SLOC. I don't expect anyone to use it, I am simply replying to your question, what is my first choice.
I implemented a very simple generic TDG and that solves 95% of all SQL queries, 100% so far in the latest project. Models are not required, but you could easily use Doctrine, etc. As for views, there is a generic View adapter, which can use Smarty, Native Syntax, etc.
Thats why I don't really call it a MVC framework, as it's really just the very basic core components in a controller architecture, front controller, a few actions, plugins/intercepting filters, dispatcher, routing, etc. Very minimal. The model and view are left to the client developer, if used at all.
One of the 2 big reasons I like Zend is not a marketing stand point, but rather a legal stand point & a quality stand point
Win-win. Most general frameworks are BSD, so licensing is rarely a concern for me. Quality, well, again, it is my personal opinion they over-engineered a lot of things (ie: controller architecture), a lot of extraneous checks, etc. That being said, it's quality is probably highest of all frameworks I have seen to date.
They require contributor agreements so later on you don't get a cease & desist letter signed by 150 developers because you made a few bucks off their contributions
Interesting. Isn't that was BSD eliminates? Basically the idea is free for everything and anything just don't remove copyright notices?
It is also extensively unit tested which is a big factor for me
yes I know it is. Whats the code coverage like? 100%? My only concern is, we all know people can write unit tests for just about any code with enough effort. Therefore having unit tests alone is not enough of a selling point for me. I guess if I am not the one writing them I guess it's OK.
I've worked on a few projects where the tests were so complicated, used so many stubs, writing/maintaining the test took more effort than implementing code. However, I will take your advice on the fact that Zend tests are done right and of high quality, as they clearly have a talented team of developers working on the software. This point of mine is moot, I am just saying for the sake of conversation, so just ignore it.
When I said TDD I don't care if its "test last" or "test first", but we should have a strict policy on tests like ZF does. In my opinion I should be in charge of deciding if it has "enough" tests, but who ever else is participating would help to vote on if a component is even "welcome" in our framework (and then, if it is welcome, I would have the power to veto the addition for reasons of test coverage, test quality, stability, etc..)
Well, my general opinion is test everything. If you don't have 100% code coverage of the SUT, something needs to be refactored, IMO. This is why I steered towards BDD I think, partially because I could never determine if I had enough tests or was testing the right thing. Writing specs inconjunction with code coverage make that decision easy. Basically run your SUT under all given/known contexts and execute all paths.
As for addressing control of unit tests, that is a political issue, something we would have to discuss in more detail. Suffice it to say, if I understand exactly what you desire, I wouldn't have much an issue of with it. Of course, more detail needs to be fleshed out.
So TDD could be optional. But I think "documentation first" needs to be a rule. Why build what can't be explained to the target user? I've talked to software veterans and the general opinion is that writing documentation before you begin (either targeted at humans, or in the form of unit tests) makes the project go a lot smoother
I write a lot of documentation in initial phases. I plan a lot on paper, but usually on napkins, etc.
Another reason I started following BDD was the story writing, specififying behaviors which could possibly be translated into english form as a document for clients to sign off on. I found it could serve multiple purposes, even to be used with an estimate calculator I had built.
The other question is at what level of abstraction would this be at? Are we building a framework & application, a sort of dichotomy? Or are we trying to not implement the application? Or is it really just an application (and not a framework)
Define framework in this context? A series of API specialized for eCommerce, that a developer ties to gather and creates the interfaces for? Does it come with a backend? Then client then implements the front side using the backend API, much like a web service?
Cheers,
Alex