Latest spark (1.7.5.2) breaks SharingGraph, need to lock to 1.7.5.1

[Bob Pace]

FYI: The SharingGraph functionality that lets you export spark views to other bottles is not working under the latest version of Spark. (views.config -> export to all)

For now if you need, lock your version of spark to 1.7.5.1 like this in your ripple.config:

<Dependency Name="Spark" Version="1.7.5.1" Mode="Fixed" />

I'll try to take a look at what got broken with it sometime and get it up to speed so this is hopefully a temporary measure.

[RobertTheGrey]

Sorry guys, I didn't realize the changes would affect it. Does this function us the IPartialProvider interface or any implementations directly? For the 1.7.5.2 change we've added a new IPartialReferenceProvider in addition to the existing interface so that it's more flexible to specify where Spark should look for its partial views. Previously, the partials would only be found by Spark if they existed in the ViewFolder that was linked to the parent view. With the new Interface, Spark is now able to look at an additional reference path specified in your implementation, but this should have been completely optional, the fallback method is the resort to existing functionality so I'm not sure what broke here.

Let me know if you need anything changed in Spark to accomodate this.

Cheers,

Rob

[Bob Pace]

Hey just got a chance to look into what went wrong with that latest pull request and I believe i have pin pointed it. 

If you take a look at the commit here: https://github.com/SparkViewEngine/spark/commit/415ca92c110da984023bcc714132459762360474

Specifically, the constructor:

        public DefaultPartialReferenceProvider()
        {
            _proxy = new DefaultPartialProvider();
        }

This is hard coding to DefaultPartialProvider, which is not the implementation we are using in FubuMvc.ViewEngines.
We register a new IPartialProvider (the FubuPartialProvider) that takes over for that service, and it is no longer the one being used. The fix will be to change that up so it takes it in as a constructor parameter.

On another note though, the IPartialReferenceProvider looks *extremely* similar to the IPartialProvider other than adding a new boolean parameter to the signature, I would rather see the original interface get extended to include that paramater than have a second thing that looks almost identical to wrap it. What do you think about that?

Thanks,
Bob

[Robert Greyling]

Hi Bob,

Thanks for coming back on this. I agree the classes look very similar, and the only reason for choosing that route initially was to try and prevent a breaking change in the public API, which means we'd have to bump the version of Spark to 2.0 just for this change. The additional parameter on the new interface allows a lot of freedom when it comes to integrating Spark with SharePoint, hence the change, but I appreciate the problem you're having now. I think this can be fixed by passing back the existing instance of IPartialProvider in your code snippit and ony creating new if it doesn't exist which would allow for FubuPartialProvider to be passed in and that should hopefully solve your issue.

Is there another way that you see that I'm missing here without of course bumping the version to 2.0 just for this minor change?

Any advice welcome, but I'll look at putting in a fix the way I described.

Cheers,

Rob

--
You received this message because you are subscribed to a topic in the Google Groups "FubuMVC Development Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fubumvc-devel/wRn2bzHMf8g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fubumvc-deve...@googlegroups.com.
To post to this group, send email to fubumv...@googlegroups.com.
Visit this group at http://groups.google.com/group/fubumvc-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[Bob Pace]

Ah, yeah as a means of preserving backwards compatibility I can see why (even though that IPartialProvider is pretty new and was introduced in 1.7.5.0) it still counts as a breaking change to mess with it's public API so that's all fine by me. All I need to make it work is to have it use the one that gets set on the engine, here is the snippet of code from FubuMVC.ViewEngines that makes this thing fire off:

            engine.PartialProvider = new FubuPartialProvider(_directoryProvider);

We just straight set that property, so anytime we do that we need it to propogate down into anything that is decorating it. I have a pull request already to go that I'm testing against FubuMVC.ViewEngines directly to make sure it works, and was even going to try and leave behind a test in the spark codebase to assert that it wires up that way to help prevent breakage in the future, since it's hard to know how anyone is making use of those things. 

[Robert Greyling]

Ok cool - I'll definitely take a look at the pull req. In the last 5 mins I just tried out chaning the signature of the contructor to this:

public DefaultPartialReferenceProvider(IPartialProvider partialProvider)

        {

            _proxy = partialProvider ?? new DefaultPartialProvider();

        }

This will make sure that if you created the engine with FubuPartialProvider it will use that one instead. Do you think that would solve your problem?

Rob

[Robert Greyling]

Hmm, ok, if you're setting that property at an undetermined point in time, then perhaps I'll need to do more than just change the contructor. I probably need to change the setter as well unless the reference passing just works. Will need to test it. Let me know how you get on and I'll get the change in

[Bob Pace]

Just submitted a pull request for it :D

[Robert Greyling]

Thanks Bob - Nuget v1.7.5.3 is now up with those changes

All the best,

Rob