We pass the container of the parent request as a parameter to the sub
request action when rendering dynamic content on a page, e.g.
public function fooAction($parentContainer) {
$formData = $parentContainer->get('request')->get('fooFormData');
}
On 14 July 2011 23:05, cammanderson <[email protected]> wrote:
> 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 [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
>
--
Dan Leech
Web Developer
www.dantleech.com
--
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
