Contributing a view engine

[Louis DeJardin]

Hello all,

I've been working on a view engine I'd like to offer to contribute. I
believe it's hit the point where it's pretty much functional.

http://dev.dejardin.org/trac/spark
http://dev.dejardin.org/trac/spark/wiki/SparkDocumentation

The development has been done on an svk mirror of mvccontrib. It can
be checked out from the following location, although I could also
create a patch if that would be more convenient.

http://dev.dejardin.org/svn/svk/local/mvccontrib/trunk/

And feedback is greatly appreciated, as always .

Thanks,
- Lou

[Bill Barry]

Neat; I like the syntax. Any chance it might be coming to monorail sometime?

[Louis DeJardin]

I don't see why not. The helpers and <viewdata/> would be different of
course, but it should be possible to move the fundamentals into a mvc/
monorail agnostic assembly and make a second view engine based on it.

[Louis DeJardin]

Looks like I picked the wrong commit to send a message to the
group. :) I need to svn add a few files from a machine at home. Sorry
for the inconvenience if anyone's pulled down a copy already.

[Eric Hexter]

After dealing with the build which has been unstable at best.  I would like to see the majority of the parser in a seperate project and than some light weight integration classes that are part of the contrib project.  I could see having the implementations for the IViewEngine and IViewLocator being part of the contrib project and the view engine being in a separate trunk.  If you are up for it I would like to try that with your engine as a way to test the waters before attempting to do this with the other view engines.  That being said .. the trunk for your view engine could be located in the mvccontrib source tree. I am totally open to that.  I really see the contrib project as providing the integrations between existing self managed features.  I am thinking that the view engine parsers and renderers would be treated similar to the Inversion Of Control frameworks.  We just include the binaries and the plumbing code to make it work in the contrib project.  You open to this?  If you want we can take the conversation offline if you wish.

 

Thanks,

Eric

[Louis DeJardin]

That sounds perfectly reasonable. Oddly enough that's almost exactly
what I've just started doing to have a Spark.dll to use as the basis
of both Asp.Net MVC and Castle MonoRail view engines.

http://dev.dejardin.org/svn/spark/trunk

It's going quite well so far and I'll let you know as it proceeds.

[Louis DeJardin]

Well that was pretty quick. There are only four files left in the
contrib view engine:
http://dev.dejardin.org/svn/svk/local/mvccontrib/trunk/src/MvcContrib.SparkViewEngine/

And it refers to binary:
http://dev.dejardin.org/svn/svk/local/mvccontrib/trunk/bin/spark/

Which is the build output of the separate trunk:
http://dev.dejardin.org/svn/spark/trunk

The split turned out to be very clean. The spark.dll doesn't have a
reference to mvc preview libraries, which should isolate it pretty
well from change.

[Eric Hexter]

Great!  Would you make the patch for the contrib project?

[Louis DeJardin]

Sure, see:
http://www.codeplex.com/MVCContrib/SourceControl/PatchList.aspx

Is it just me or is tortoise patch useless for adding binary files and
new folders? What a nightmare!

Also, for Spark related defects, feature requests, verbal abuse, etc:
http://dev.dejardin.org/trac/spark/newticket

On Jun 8, 7:34 am, "Eric Hexter" <eric.hex...@gmail.com> wrote:
> Great! Would you make the patch for the contrib project?
>

> On Sun, Jun 8, 2008 at 2:35 AM, Louis DeJardin <Louis.DeJar...@gmail.com>

> wrote:
>
>
>
> > Well that was pretty quick. There are only four files left in the
> > contrib view engine:
>

> >http://dev.dejardin.org/svn/svk/local/mvccontrib/trunk/src/MvcContrib...