Hi Tobi! On 01/28/2008 09:29 AM Tobias Struckmeier wrote:
>>>> Target and scope <snip /> > 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. I agree with you, that in many cases a custom MVC implementation is more valuable than using something pre-built. This is the main reason why I a) still call this package MvcTools instead of Mvc (because I intend to create somtehing that users can base their Mvc on) and b) I want to just ship the most basic implementations of the interface we're going to design with it. Good to hear that you agree with this. :) > 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. Fully agreed. > 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). I think this is what we also discussed with Gaetano and what we have in mind with "output-abstraction". >> 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. Input- / output-abstraction should solve this point. We can also ship specific classes to mock this with the component, as we for example do with the memory-backend for Webdav. >>> Should MvcTools use a unified user-project configuration file (with paths, >>> database access ...) ? Or should this be left to a "Deployment component" ? <snip /> >>>> - 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. This should be a part of the input-/output-abstraction then, right? James, what do you think? > - 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. I don't think this belongts into either a tie-in or similar, but would be part of a "Framework" package. > - 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). Same here. This is all application logic and should not become a component, but be part of a "Framework" package. > - There really should be a fallback controller when no > controller/action is found or a rerouting on another controller should > be done. Yes, we already have this in mind. But thanks for stressign this point. > - What is with filtering? Isnt that part of the MVC? That depends on what you mean with it, I would say. Basically, all input should be filtered through its input-abstraction class in the way that is feasible for a certain way of input. However, I see a problem here, if this changes for different actions (e.g. the difference between GET/POST). James: What do you suggest here? > 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? Depends on the router implementation I would say. For the very basic router I would suggest to go a similar approach as our autoload-arrays go: Map action names to PHP class names. > 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. I hoped that, since you already have some real-world experience with other MVC implementations by now. :) Thanks for your input, Tobi. Cheers from your old home! Toby -- Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer [EMAIL PROTECTED] | eZ Systems AS | ez.no -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
