initially in AspView I was copying all of the parent's properties to the
subview's properties, then overwriting the subview parameters ontop of that.
That way I got the subview the ability to access parent properties, and have
local properties override. It also acheived isolation.

When I started dealing with more and more complex rendering (we have a
"newsfeed" page that can render a good few hundreds of subviews for each
page!), we discovered that copying values over and over again is quite
costly.

We then changed to an IDictionary that is made out of an internal
"parentScope" IDictionary, and a LocalScope IDictionary.
any SET or ADD goes to the LocalScope.
any Get goes first to the LocalScope, and then to the ParentScope if it does
not exist in the current one.

The overhead on GET is negligible in comparison to the recurring copies
(thoroughly profiled and tested).

I am actually working on a new rendering engine, similar to AspView in
nature however with zero dependencies (not MR, not even Web) - I have a
simple version of this dictionary here:
https://github.com/kenegozi/ntemplate/blob/master/src/NTemplate/Internal/TemplateParameters.cs

the tricky part btw was the enumerator. it's one of my least favourite
interfaces to implement





2010/11/30 Henry Conceição <[email protected]>

> The razor pages supports section as well. It shouldn't be hard to add
> support to sections there too.
>
> Cheers,
> Henry Conceição
>
>
>
> On Tue, Nov 30, 2010 at 3:18 AM, hammett <[email protected]> wrote:
> > What I find most useful is being able to have sections with a
> > component, and render them as many times as I wanted.
> >
> > I believe it's fairly simple to replicate the behavior with webforms.
> > Not sure about others though.
> >
> > 2010/11/29 Henry Conceição <[email protected]>:
> >> Hi,
> >>
> >> I'm starting to scratch the View Component feature, and would like to
> >> hear from the people here what do you think about the current (mr2)
> >> implementation of it. What do you think that needs to be improved,
> >> removed or maintained?
> >>
> >> Cheers,
> >> Henry Conceição
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "Castle Project Development List" group.
> >> To post to this group, send email to
> [email protected].
> >> To unsubscribe from this group, send email to
> [email protected]<castle-project-devel%[email protected]>
> .
> >> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
> >>
> >>
> >
> >
> >
> > --
> > Cheers,
> > hammett
> > http://hammett.castleproject.org/
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "Castle Project Development List" group.
> > To post to this group, send email to
> [email protected].
> > To unsubscribe from this group, send email to
> [email protected]<castle-project-devel%[email protected]>
> .
> > For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Castle Project Development List" group.
> To post to this group, send email to [email protected]
> .
> To unsubscribe from this group, send email to
> [email protected]<castle-project-devel%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
>
>


-- 
Ken Egozi.
http://www.kenegozi.com/blog
http://www.delver.com
http://www.musicglue.com
http://www.castleproject.org
http://www.idcc.co.il - הכנס הקהילתי הראשון למפתחי דוטנט - בואו בהמוניכם

-- 
You received this message because you are subscribed to the Google Groups 
"Castle Project Development List" 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/castle-project-devel?hl=en.

Reply via email to