Just an update: On Sun, Jun 19, 2011 at 11:48 PM, hammett <[email protected]> wrote: > Ever wanted to give f# a try, or already a f# hacker? MR+++ needs your help! > > ++ Easy Items ++ > > Helpers need most attention. See > > https://github.com/castleproject/Castle.MonoRail3/blob/master/src/Castle.MonoRail/Mvc/Mvc.Helpers.fs > https://github.com/castleproject/Castle.MonoRail3/blob/master/src/Castle.MonoRail/Mvc/Mvc.Helpers.UrlHelper.fs > https://github.com/castleproject/Castle.MonoRail3/blob/master/src/Castle.MonoRail/Mvc/Mvc.Helpers.FormTagHelper.fs > https://github.com/castleproject/Castle.MonoRail3/blob/master/src/Castle.MonoRail/Mvc/Mvc.Helpers.FormHelper.fs
Helpers are being integrated with the metadata model, which also needs some thinking. > Castle Blade is fully operational, but the parser and code gen are not > 100% complete. > You can check the AST > (https://github.com/castleproject/Castle.MonoRail3/blob/master/src/Castle.Blade/src/Castle.Blade/AST.fs) > and the CodeGen > (https://github.com/castleproject/Castle.MonoRail3/blob/master/src/Castle.Blade/src/Castle.Blade/CodeGen.fs) > to check the nodes not being generated. This is still pending > We also need a decent test infrastructure. > Also for Castle Blade, we need better error reporting. One way to help > is to generate pragma declaration in the generated code. For that, > each parser need to include positional information and pass that along > to the AST. See > http://stackoverflow.com/questions/6350752/position-information-in-fparsec I ended up implementing these two. -- Immediate needs -- == Model Metadata Now we need to design ModelMetadata/MetadataProviders. I think the canonical representation of metadata can be System.ComponentModel and DataAnnotations. The source can be anything, as long as it translates into those objects. I started something: https://github.com/castleproject/Castle.MonoRail3/blob/master/src/Castle.MonoRail/Mvc/Mvc.Model.fs but would be happy to replace it :-) == Deserialization of Form data Should work together with FormHelper/FormBuider and ModelMetadata. To be implemented at https://github.com/castleproject/Castle.MonoRail3/blob/master/src/Castle.MonoRail/Mvc/Mvc.Serializers.fs == Improvement of Generator Check https://github.com/castleproject/Castle.MonoRail3/tree/master/src/Castle.MonoRail.Generator It creates partial classes exposing strongly typed Url object targets. See https://github.com/castleproject/Castle.MonoRail3/blob/master/WebApplication1/Generated/GeneratedRoutes.cs This needs great improvements to support non-default routes. -- Interesting ideas to explore, all of them up for grabs -- == Integration with JSIL I have *nothing* against javascript, but in my heart I prefer statically compiled languages, and I know of people who share this preference. Instead of going for a full blown framework like GWT, how could we provide a more lightweight integration? - Strongly typed dom manipulation - typed calls to controllers that render js ajax calls. - Integration with some UI framework like jQuery UI, ext, etc The final goal is - and always been - boost productivity == Integration with Coffee Script Code coffee views and have them being rendered in javascript. IronJS is probably your friend if you want to implement this. == Composition of apps MR3's core is a foundation for modularity. When you have a web project using MR3 it is treated internally by the framework as a module (root). Imagine that you can implement many web sites (forum, wiki, issuetracking) that work just fine independently, but you deploy them as modules of a master project (myproduct.com). *This is the goal* The modules are isolated from each other in different ways - different loading contexts - see http://hammett.castleproject.org/index.php/2011/03/using-loading-contexts-effectively/ - different framework instance (if a module is using Spark instead of Blade, it has no impact on other modules). This is achieved by separating each module as it's own instance of the framework - and that's why we cannot ever rely on statics Ideally then we should use a package mechanism to package and integrate modules within a master project.. This implementation is somewhat relying on MEF, but I'd also be happy to replace it with a tool that provides the right abstractions and perf. == Tooling VS integration should be developed. Minimally we should create template project/project items. > > How to contribute? > > 1 - git clone [email protected]:castleproject/Castle.MonoRail3.git > 2 - Download and install http://fsprojectextender.codeplex.com/ > 3 - Open Castle.MonoRail.sln and make your changes > 4 - Send a pull request, and we will merge your changes. It's that easy ;-) > > Note, WebApplication1 is an experimentation zone for the functionality > Henry and I are coming up with. Exploring the code and views there > will give you a lot of insight. > > Thanks! -- Cheers, hammett http://hammett.castleproject.org/ -- You received this message because you are subscribed to the Google Groups "Castle Project Users" 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-users?hl=en.
