Damn i hit accidentically reply instead reply all. So i try again :) Hi all,
first - if I double a some points already said, just see it as a sign that I found it very important ;-). > >> Target and scope I think this is the most important point to be defined such an MVC - TARGETS. There should be first some goals defined, what should be achieved with the approach. I think those goals can be used to focus on the real world requirements during specification, design, testing and implementation. As we all know, its often the best approach to have a custom MVC based on the need of the application. But beside that its often more important to get something started fast without a big hassle, so such a component is welcome and should imho therefore fulfill some requirements. When I start with a project I don't want to build the same basics again and again. So one of the goals must be to have something that I can get running pretty fast that suits common needs in todays web development and gives me a basic environment to sit in and a first path to follow. This standard environment should be slick (e.g. prevent having dozens of classes autoloaded by default) and fast, but conceptional complete. It should make it easy to still use other libraries. Also I don't want to build huge configuration files or first extend a basic controller with an app specific controller where I put tons of code in. I just should be able to write my first "page/action controllers" right away (or at least have a sample main controller that i just need to rename *grin*). I think "convention" is the key here. (Yes I want to be able to customize that, but customization requires work, like extending, configuring etc.). It should be possible to inject own/extended components, but it shouldn't be required. Also I would like to see the common use cases of a web application/website ready to use. Like supporting different output formats (rss, json,... not concrete but abstract in the concept) and a basic handling of AJAX in the framework. (I think Gaetano already raised this point in his email). > But please keep in mind, that we cannot provide the testing environment > itself. This does a) not fit into the component and b) our test > "component" is not an official component can only be used to test eZ > Components. However, we could provide detailed information and possibly > some helper classes for the testing of applications build on this component. I agree that should be done specific (which is not that hard usually). Important is that controllers stay testable, which might require some options in the MVC to mock things etc. > > Should MvcTools use a unified user-project configuration file (with paths, > > database access ...) ? Or should this be left to a "Deployment component" ? > > No, MvcTools (or whatever name it will get ;) should be configurable as > any other of our components: Instantiating classes with certain values > submitted to the constructor for settings and instantiate and configure > option classes for optional configurations. For more information see [4]. Ack. No configuration which is required (as far as possible). > >> - Input abstraction (also see above) > >> - Routing > >> - Controllers > >> - Output abstraction I want to add here: - A standard "URL building mechanism" should be there that helps to build the urls for the specific contexts (eg. AJAX), make redirections etc. - A logging proposal (documentation/tie-in etc..) should be there. I usually want to output some stuff like (template use, accumulations, db queries made, debug etc...) during development that should be logged and/or emailed during productive use. - Some basic mechanims for hooking autorisation on controller/action level into it would be helpful. As well as a standard way to deal with unauthorized access (Fallback controller or so). - There really should be a fallback controller when no controller/action is found or a rerouting on another controller should be done. - What is with filtering? Isnt that part of the MVC? To get a bit into more details (but important ones i think). How should the mapping of urls to controller/actions happen? Magically by using function names? Or explicit by array maps or similar? I will watch the development of this tight and hope I was and will be able to give some helpful input. I would like to see that becoming "official" later as well. Best regards from Hamburg, Tobi -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
