Hi Guys, I have worked on developing a few CMS's, and the idea of being able to have an initial request that dynamically calls-in/loads other content elements is very useful (think H-MVC). The problem I have is that due to the very dynamic behaviour of those includes we can't easily identify which parts of the original request parameters will be useful.
Currently, when we include another controller or URL, a new request is authored without any parameters being passed through. I understand this is to do with how ESI technology works, but I don't think that it has to be the only exclusive way of handling this. Is it possible to have an option that allows the current request parameters/files etc passed through automatically in a subrequest. I have thought about it in the past, and wasn't sure whether I thought it should be part of the main app. A trivial example where this makes sense: A page that loads some static content, but also draws in a Form (using the render call or similar). We can not anticipate the requirements of the form in the initial controller in this case, unless we want to create that dependency. If we draw in that other form we lose access to the original request parameters/files unless we explicitly define them in the view level. The simplest example of this would be a page that loads and article, and has included some form of a subscription form on the right hand side. The request is to be sent to the same current page, and using H-MVC the form is handled independently. The original controller used to load the article shouldn't be involved in handling the form, or need to have the view updated with changes to the subscription form. Of course alternative approaches exist for this scenario, but there could be 15 or more different actions that are being embedded on each page, each with their own MVC (hence the H-MVC capability). I would suggest that an additional flag (like the standalone flag) that would allow us to pipe the request (sans the controller identification etc) with all the parameters/files etc to that page.This will allow us to develop H-MVC approaches without creating cascading pass-throughs needing to be defined at every level to be able to hold onto parts of the request that further down the chain needs. It may very well be a feature that is not supported by the caching/ESI component, but for a flexibility for creating dynamic H-MVC that can handle forms (post data) further down the chain. Cheers Cameron -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en