Hello Tobias,

Thanks for your message. I agree with most of your points.

Tobias Struckmeier wrote:
> >> - 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.

Isn't it possible to do with Url component natively ?

> - 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'm unsure how this can be part of MvcTools, debug calls are not supposed to
remain in the code, according to the coding standarts. Though the documenta=
tion
of mvctools should describe how to do this.

> - 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).
I'm unsure if the component should supply such features, but the guide shou=
ld
definitively describe how it could be done in the router.

> - There really should be a fallback controller when no
> controller/action is found or a rerouting on another controller should
> be done.

I'm unsure if the component should supply a 404 default controller, but mvc=
tools
guide should definitively describe the procedure to it.

> - What is with filtering? Isnt that part of the MVC?

Filtering what ?


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

Isn't it possible to support both ?

In the first stage of the development, we have production needs and the urls
aren't the most important. When deploying to production : it's often useful
to explicitely set up "url rewriting" in the php-application - if you don't 
want to do it with apache.

> 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

 Thanks for your feedback, regards, James.

-- 
James Pic
GPG Key : 13185F50x8 / AEE2 CC15 8FF8 339C 23AC  5A91 491B 1638 1318 5F58
Downloadable on http://jamespic.com/pubkey.asc

Attachment: pgpYEH96CSnix.pgp
Description: PGP signature

-- 
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components

Reply via email to