Re: Extension point for PartialViewFolderPaths

19 views
Skip to first unread message

RobertTheGrey

unread,
Nov 13, 2012, 7:01:31 AM11/13/12
to spar...@googlegroups.com
Thanks very much Bob! This has been released for you up on Nuget in v1.7.5.0

On Tuesday, November 13, 2012 12:18:14 AM UTC, Bob Pace wrote:
I've been looking into FubuMVC.ViewEngines and its usage of Spark and have determined that an extension point in Spark itself would be nice to have to help facilitate the functionality of letting Fubu bottles be the providers of shared partials. A similar extension was added for IBindingsProvider awhile back, this is very much like that one.


Let me know if there's anything that needs to be changed with the proposed commit, or if anyone has any other feedback to offer on it.

Bob Pace

unread,
Nov 13, 2012, 3:23:46 PM11/13/12
to spar...@googlegroups.com
Awesome, thanks for the speedy turnaround!

I'm noticing a bit of a weird thing between the net35 and the net40 versions of the new Spark.dll available through nuget for 1.7.5.0, specifically in the ViewLoader class.

The property for IPartialProvider seems to have come out differently.

I can see in Reflector that the net35 version has this implementation (as I would expect)
public IPartialProvider PartialProvider
{
  get
  {
    if (this.partialProvider == null)
    {
      this.partialProvider = new DefaultPartialProvider();
    }
    return this.partialProvider;
  }
  set
  {
    this.partialProvider = value;
  }
}

But in the net40 version it is just this:

public IPartialProvider PartialProvider { get; set; }

Any idea why that might be?

Not a big deal, but it is a tad less convenient for some of the tests to have to provide the default value of new DefaultPartialProvider() explicitly to the ViewLoader instance.

Rob G

unread,
Nov 13, 2012, 3:44:22 PM11/13/12
to spar...@googlegroups.com
I've just loaded the binaries for 3.5 and 4.0 in reflector that I used to build the nuget packages and both have the default (expanded) implementation of PartialProvider.

Also, checking the source code, nothing strange happened with commits that I can see, and in any case, I cherry pick the commit into the 3.5 branch from the 4.0 branch as a rule as a backwards compatibility test for all commits that are possible. Looking at both branches, they are the same commit - direct from your pull req, so I can't imagine what has happened there.

Thoughts?

--
You received this message because you are subscribed to the Google Groups "Spark View Engine Dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/spark-dev/-/guWJrdE0LVMJ.

To post to this group, send email to spar...@googlegroups.com.
To unsubscribe from this group, send email to spark-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/spark-dev?hl=en.

Bob Pace

unread,
Nov 13, 2012, 4:06:46 PM11/13/12
to spar...@googlegroups.com
Ah ha, yeah false alarm on my part turns out I had failed to update the .csproj hint path for that dll in the fubu project and it was pulling an older cached version of it and had me very confused for a bit there but it's all sorted out and working now.

My apologies, thanks again!
Reply all
Reply to author
Forward
0 new messages