MonoRail roadmap/todos
John Simons
next from Monorail v3.
I've already created a uservoice for Monorail v3:
http://castle.uservoice.com/forums/38553-monorail-v3
But there is a list that I've started working on (this list is still
growing and there will be more added), most of these are just by going
through the source code of Monorail:
- Need to break the coupling that Monorail currently has on other
libs, at the moment Monorail is dependant on nearly all other Castle
projects. I think to do this we need to enforce the same mechanism
that Windsor uses by the use of facilities to extend the container.
- MonoRail routing, well this is a grey area that currently is not
totally complete, my view on this is lets just use the
System.Web.Routing
- javascript support, I think we are supporting too many different
frameworks in this area, we are trying to maintain prototype,
jquery,delicious,...
- Scaffolding, why is this tight to ActiveRecord?
- How do we stay in business now with other offers like ASP.Net MVC,
FubuMVC,... ?
- The whole code base needs a clean-up, remove obsolete code, ...
The list is not finished, it is a work in progress.
Cheers
John
Krzysztof Koźmic (2)
On 18 Sty, 13:05, John Simons <johnsimons...@yahoo.com.au> wrote:
> Now that Monorail v2 is out, is time to start thinking about what is
> next from Monorail v3.
>
> I've already created a uservoice for Monorail v3:http://castle.uservoice.com/forums/38553-monorail-v3
>
> But there is a list that I've started working on (this list is still
> growing and there will be more added), most of these are just by going
> through the source code of Monorail:
>
> - Need to break the coupling that Monorail currently has on other
> libs, at the moment Monorail is dependant on nearly all other Castle
> projects. I think to do this we need to enforce the same mechanism
> that Windsor uses by the use of facilities to extend the container.
As long as we don't end up with tens of small assemblies with very few
types.
I'm all for breaking dependencies where it makes sense, but think
three time before creating yet another assembly for that.
>
> - MonoRail routing, well this is a grey area that currently is not
> totally complete, my view on this is lets just use the
> System.Web.Routing
This would be a major breaking change. And while my experience with
Monorail routing is none, does it not offer any advantages
over System.Web.Routing? OpenRasta for example, is a framework that
deliberately does not use SWR providing its own routing engine
While SWR has the advantage of being part of BCL and being very well
documented by books, blogs and MSDN, I would be very careful
when introducing such change.
>
> - javascript support, I think we are supporting too many different
> frameworks in this area, we are trying to maintain prototype,
> jquery,delicious,...
I'd say due to immense popularity, we should put major emphasis on
JQuery
>
> - Scaffolding, why is this tight to ActiveRecord?
>
> - How do we stay in business now with other offers like ASP.Net MVC,
> FubuMVC,... ?
We release more often :)
>
> - The whole code base needs a clean-up, remove obsolete code, ...
Perhaps before v3.0 we should have a minor release first, with little
breaking changes
and mostly concentrated on clean up and polish?
Jonathon Rossi
This also makes planning and implementing releases much easier for the castle team.
I think most people would agree that we can never again make as many breaking changes that RC3->2.0 has without making small releases in between.
John, when you say you want to break the coupling that MonoRail has on other projects (e.g. AR and Windsor), are you saying they should be released in separate packages, because they are already all separate assemblies AFAIK.
--
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 castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
--
Jono
Krzysztof Koźmic (2)
breaking changes, along with clear migration path. This concerns not
just Monorail, but all existing projects.
I suggest we maintain next to changes.txt a upgrade.txt (or similar
name) in the following format:
- Short description/justification of the change (along with revision
numbers where it was committed)
- Description of the suggested migration paths, best with code
samples.
For example:
===============================================================================================
- removed "UsingFactory" method from IoC fluent registration API,
because it provides no real
value over "UsingFactoryMethod" method, and only confuses users
(r666)
- All calls to UsingFactory can be replaced corresponding calls to
UsingFactoryMethod.
- sample:
kernel.Register(
Component.For<ICarProvider>()
.UsingFactory((AbstractCarProviderFactory f) => f.Create
(kernel.Resolve<User>()))
);
The above call can be replaced with semantically identical call to
UsingFactoryMethod:
kernel.Register(Component.For<ICarProvider>()
.UsingFactoryMethod(
k => k.Resolve<AbstractCarProviderFactory>()
.Create(k.Resolve<User>()))
);
=======================================================================================
John Simons
On Jan 18, 11:31 pm, Krzysztof Koźmic (2) <krzysz...@kozmic.pl> wrote:
> inline
>
> On 18 Sty, 13:05, John Simons <johnsimons...@yahoo.com.au> wrote:
>
> > Now that Monorail v2 is out, is time to start thinking about what is
> > next from Monorail v3.
>
> > I've already created a uservoice for Monorail v3:http://castle.uservoice.com/forums/38553-monorail-v3
>
> > But there is a list that I've started working on (this list is still
> > growing and there will be more added), most of these are just by going
> > through the source code of Monorail:
>
> > - Need to break the coupling that Monorail currently has on other
> > libs, at the moment Monorail is dependant on nearly all other Castle
> > projects. I think to do this we need to enforce the same mechanism
> > that Windsor uses by the use of facilities to extend the container.
>
> As long as we don't end up with tens of small assemblies with very few
> types.
> I'm all for breaking dependencies where it makes sense, but think
> three time before creating yet another assembly for that.
My idea is to make it their own packages with their own release
schedules.
>
> > - MonoRail routing, well this is a grey area that currently is not
> > totally complete, my view on this is lets just use the
> > System.Web.Routing
>
> This would be a major breaking change. And while my experience with
> Monorail routing is none, does it not offer any advantages
> over System.Web.Routing? OpenRasta for example, is a framework that
> deliberately does not use SWR providing its own routing engine
> While SWR has the advantage of being part of BCL and being very well
> documented by books, blogs and MSDN, I would be very careful
> when introducing such change.
I would actually not consider it a major change.
The benefit of using System.Web.Routing vs our own (which btw we have
2 implementations, so we would be breaking code anyway!) is that would
be less code to maintain and an easier migration from someone coming
from either ASP.Net MCV or FubuMVC.
As it stands, our implementation does not offer any advantages over
System.Web.Routing, actually I find the System.Web.Routing a lot more
extendible than ours.
>
>
>
> > - javascript support, I think we are supporting too many different
> > frameworks in this area, we are trying to maintain prototype,
> > jquery,delicious,...
>
> I'd say due to immense popularity, we should put major emphasis on
> JQuery
>
I agree, we should concentrate our efforts on one javascript library.
>
>
> > - Scaffolding, why is this tight to ActiveRecord?
>
> > - How do we stay in business now with other offers like ASP.Net MVC,
> > FubuMVC,... ?
>
> We release more often :)
Agree
>
>
>
> > - The whole code base needs a clean-up, remove obsolete code, ...
>
> Perhaps before v3.0 we should have a minor release first, with little
> breaking changes
> and mostly concentrated on clean up and polish?
Agree
Krzysztof Koźmic
On 2010-01-18 22:05, John Simons wrote:
> Inline
>
> On Jan 18, 11:31 pm, Krzysztof Ko�mic (2)<krzysz...@kozmic.pl> wrote:
>
>> inline
>>
>> On 18 Sty, 13:05, John Simons<johnsimons...@yahoo.com.au> wrote:
>>
>>
>>> Now that Monorail v2 is out, is time to start thinking about what is
>>> next from Monorail v3.
>>>
>>
>>> I've already created a uservoice for Monorail v3:http://castle.uservoice.com/forums/38553-monorail-v3
>>>
>>
>>> But there is a list that I've started working on (this list is still
>>> growing and there will be more added), most of these are just by going
>>> through the source code of Monorail:
>>>
>>
>>> - Need to break the coupling that Monorail currently has on other
>>> libs, at the moment Monorail is dependant on nearly all other Castle
>>> projects. I think to do this we need to enforce the same mechanism
>>> that Windsor uses by the use of facilities to extend the container.
>>>
>> As long as we don't end up with tens of small assemblies with very few
>> types.
>> I'm all for breaking dependencies where it makes sense, but think
>> three time before creating yet another assembly for that.
>>
> My idea is to make it their own packages with their own release
> schedules.
>
It feels like micromanagement to me, and I don't think we have enough
resources to play this game.I would try to avoid it, unless there's
really good reason to do so.
goodnight,
Krzysztof
SerialSeb
written before MVC. It's entirely possible to swap around the
implementation of the URI repository to whatever implementation you
want.
There's one main reason why I do not want to support MVC's routing
engine, it's greedy, which mean you can't run it side by side with any
other components unless you add all the URIs mapped to another module
as ignored routes.
And of course, it's asp.net specific and OpenRasta is not, so we can't
rely on it being there when we're running in-process or in our own
managed AppDomain.
On Jan 18, 9:16 pm, Krzysztof Koźmic <krzysztof.koz...@gmail.com>
wrote:
> inline,
>
> On 2010-01-18 22:05, John Simons wrote:
>
>
>
> > Inline
>
> > On Jan 18, 11:31 pm, Krzysztof Ko mic (2)<krzysz...@kozmic.pl> wrote:
> >>> John- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Ken Egozi
--
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 castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
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 - הכנס הקהילתי הראשון למפתחי דוטנט - בואו בהמוניכם
James Curran
> do we actually need MR to continue as a full framework, or did MVC with
> version 2 became good enough as a basis for web development,
From what I know of MVC2, The functionality of
SmartDispatchController is still missing, which I consider a virtual
requirement. Now, is that part of the core framework, or something
that can be an add-on?
Truth,
James
Henry Conceição
direction, we should have a close relationship with he asp.net/ms mvc
team. It'll be pretty disappointing (and kinda useless) to work hard
on something and discover that ms will, again, launch their own
implementation of it.
Have said that, I think we should move in a completely new direction
(from Monorail v1 and v2). Like it or not, Ms MVC will be default
choice for the masses, so, I wouldn't try to offer a tool for this
market. I think we can try something new taking advantage of f# or
even ironruby.
Cheers,
Henry Conceição
Ian Cooper
> and if MVC was brought up - I'd like to raise the question:
> do we actually need MR to continue as a full framework, or did MVC with
> version 2 became good enough as a basis for web development, and MR can work
> as an added value package, (much like mvc-contrib, or even be an addition to
> mvc-contrib)
I think we are at an intesting point for MR. Sure one option is to
decide that ASP.NET MVC is good enough to make further investment in
Monorail lack value. However I do recgonize that I don't contribute
but just use Monorail, so it's perhaps a little unfair of me to ask
you to commit time if you feel that MVC is now a solved problem and
time would be better spent elsewhere.
Yet at the same time other projects such as FubuMVC spring up because
of percieved weaknesses with MVC. The question for me would be could
Monorail like FubuMVC and take a more opiononated path. If the goal is
no longer simply to be the default MVC framework for .NET developers,
then surely the goal becomes to be an alternative framework for .NET
developers that makes different choices. You might have more freedom
about the choices you make if you no longer decide to appeal to all
MVC framework users, but instead those dissatisfied with ASP.NET MVC.
In other words what is your unique selling point?
I think it is a shame that that new ideas from FubuMVC did not just
play back into Monorail giving the community more focus. Perhaps the
two projects should think about combining in some way?
I also think it is inevitable that all the frameworks will compete.
That may not be unhealthy if it results in better software.
Krzysztof Koźmic
I'm not a web developer, so I am even less in a position to make
opinionated statements here, but you more or less
summarized how I feel about this.
Quick search on google, returned that on Java there are at least 20 MVC
frameworks in use
There are even more in Ruby land, similar in PHP. Why are we setting on
having just a handful in .NET space?
I know that .NET is different because everything resolves around
Microsoft, but as EF/l2s didn't made NHibernate and other ORMs disappear
I think it's much to early to make decisions like this. Let's not throw
the baby out with the water.
Krzysztof
Ian Cooper
wrote:
> I'm not a web developer, so I am even less in a position to make
> opinionated statements here,
Probably implies that as a consumer of the goods I should try to give
more back though.
Krzysztof Koźmic
:-) Especially for people
who are well known for their skills and have good understanding of the
codebase.
Being an active user is also a big plus, but that goes without saying.
Dogfooding FTW!
Krzysztof
On 2010-01-19 20:05, Ian Cooper wrote:
> On Jan 19, 6:35 pm, Krzysztof Ko�mic<krzysztof.koz...@gmail.com>
Krzysztof Koźmic (2)
http://spmason.com/post/343293206/why-aspnetmvc-2-is-broken
On 19 Sty, 20:10, Krzysztof Koźmic <krzysztof.koz...@gmail.com> wrote:
> I didn't mean to imply anything. But contributions are always welcome
> :-) Especially for people
> who are well known for their skills and have good understanding of the
> codebase.
> Being an active user is also a big plus, but that goes without saying.
> Dogfooding FTW!
>
> Krzysztof
>
> On 2010-01-19 20:05, Ian Cooper wrote:
>
> > On Jan 19, 6:35 pm, Krzysztof Ko mic<krzysztof.koz...@gmail.com>
John Simons
SerialSeb, are you talking about specifically about your experience in
OpenRasta with trying to use System.Web.Routing ?
Cheers
John
On Jan 20, 1:14 am, SerialSeb <s...@serialseb.com> wrote:
> Note that we use a different routing engine from MVC because it was
> written before MVC. It's entirely possible to swap around the
> implementation of the URI repository to whatever implementation you
> want.
>
> There's one main reason why I do not want to support MVC's routing
> engine, it's greedy, which mean you can't run it side by side with any
> other components unless you add all the URIs mapped to another module
> as ignored routes.
>
> And of course, it's asp.net specific and OpenRasta is not, so we can't
> rely on it being there when we're running in-process or in our own
> managed AppDomain.
>
> On Jan 18, 9:16 pm, Krzysztof Ko¼mic <krzysztof.koz...@gmail.com>
> wrote:
>
> > inline,
>
> > On 2010-01-18 22:05, John Simons wrote:
>
> > > Inline
>
> > > On Jan 18, 11:31 pm, Krzysztof Ko mic (2)<krzysz...@kozmic.pl> wrote:
>
> > >> inline
>
> > >> On 18 Sty, 13:05, John Simons<johnsimons...@yahoo.com.au> wrote:
>
> > >>> Now thatMonorailv2 is out, is time to start thinking about what is
> > >>> next fromMonorailv3.
>
> > >>> I've already created a uservoice forMonorailv3:http://castle.uservoice.com/forums/38553-monorail-v3
>
> > >>> But there is a list that I've started working on (this list is still
> > >>> growing and there will be more added), most of these are just by going
> > >>> through the source code ofMonorail:
>
> > >>> - Need to break the coupling thatMonorailcurrently has on other
> > >>> libs, at the momentMonorailis dependant on nearly all other Castle
> > >>> projects. I think to do this we need to enforce the same mechanism
> > >>> that Windsor uses by the use of facilities to extend the container.
>
> > >> As long as we don't end up with tens of small assemblies with very few
> > >> types.
> > >> I'm all for breaking dependencies where it makes sense, but think
> > >> three time before creating yet another assembly for that.
>
> > > My idea is to make it their own packages with their own release
> > > schedules.
>
> > It feels like micromanagement to me, and I don't think we have enough
> > resources to play this game.I would try to avoid it, unless there's
> > really good reason to do so.
>
> > goodnight,
> > Krzysztof
>
> > >>> -MonoRailrouting, well this is a grey area that currently is not
> > >>> totally complete, my view on this is lets just use the
> > >>> System.Web.Routing
>
> > >> This would be a major breaking change. And while my experience with
> > >>Monorailrouting is none, does it not offer any advantages
John Simons
an easy ride!
We have learned a lot, from developing such a framework, and at the
moment I have to say with confidence that in terms of features we are
still ahead of the game in comparison to ASP.NET MVC.
Our down point is in the doco/samples.
And yes, I agree we will never be able to draw the masses of
developers that ASP.NET MVC is able to, but hey do we really want
that, I don't think so!
Regarding using ASP.NET MVC code base or extend it, my question is
what for? What are we going to get from that, is not that we need it
(we have already got the code written in MonoRail).
Hamilton just quickly mentioned the word on another thread,
"Composition".
As far as I know at the moment no other .Net MVC framework has the
concept of "Web page composition" server side.
The way developers are achieving this is by using Ajax to load
sections of their web page, but this is done client side.
My proposal is for us to change Monorail to do this on the server
side.
The idea is simple, and I've already started looking at the source
code to see what is involved in doing this.
So my proposal is:
- We change the routing to support the idea of "composite routing", so
that we can tell the routing engine that we do not want to just
execute one action/controller, but instead we want to execute
multiple.
- We then create a new HttpHandler that handles this by instead of
instantiating only one controller and calling its action, it
instantiates as many as were defined (this could be done sequential or
in parallel or support both).
- Once all action execute, we bring it all together into one single
response.
If we go this path we could also implement what ASP.NET MVC does
where they only support one model per view(ViewModel) and get rid of
the PropertyBag to pass data to the view.
Thoughts?
Cheers
John
On Jan 20, 11:20 pm, Krzysztof Koźmic (2) <krzysz...@kozmic.pl> wrote:
> Just a reference link. Not everyone is happy with ASP.NET MVC...
>
> http://spmason.com/post/343293206/why-aspnetmvc-2-is-broken
>
Gauthier Segay
> I think there is still a market for MonoRail, but is not going to be
> an easy ride!
as for me, the code is not rusting, I agree that MSMVC has the masses
attention, but MR will live as long as it's user base and maintainers
keeps it moving forward.
there are other .net web frameworks in various states of maturation
(bistro, fubu, ...), not a compeling reason for MR to fade away
because MS has a competing implementation.
From my point of view (using MR since 2007) What would be interesting
is to leverage some parts of the ASP.MVC third part "market" if such
thing develop: I mean reusing some of the work done with typed form
helpers or other things.
I don't know if it actually mean a really complex work now that
System.Web.Mvc bits are in the standard .net distribution, but that
would mean that most of the tutorial / samples talking about MS bits
would be transposable.
routing engine abstraction supporting System.Web.Routing along side
with MR and other implementations would be a step in this direction.
Thinking about how to leverage VS / MD tooling for MSMVC could also
enhance the end user experience, looking up with them integration
points would be huge (I think they done so with some parts choosing
unit test frameworks).
> Our down point is in the doco/samples.
As for documentation, I'm not sure if the goal is to have MRDN (MSDN
is great but style used in most sample could give me headaches), but I
agree that some clear sample tutorials using nested model binding of
request params in action signature, basic formhelper client automatic
validation would help the newcommers.
The problem is not the lack of discoverability, to me the castle doc
site is ok, looking at the test coverage of the various parts allow to
learn a great deal.
I agree that for further material there is some kind of inference
required because of the timespan theses bits were published (and the
evolution of MR and other parts API), but that would be the same in a
year or so for MSMVC.
> And yes, I agree we will never be able to draw the masses of
> developers that ASP.NET MVC is able to, but hey do we really want
> that, I don't think so!
+1, I think Ken (or someone else) made some statements about
opensource userbase and project healthyness
> Hamilton just quickly mentioned the word on another thread,
> "Composition".
+1, too bad for SmartDispatchController ;)
> As far as I know at the moment no other .Net MVC framework has the
> concept of "Web page composition" server side.
RenderAction idea came from actual MSMVC (google search lead to
article such as http://blogs.intesoft.net/post/2009/02/renderaction-versus-renderpartial-aspnet-mvc.aspx)
I think the implementation is a way to circumvent viewcomponents (or
porting problem of the UserControl away from Webforms), and I'm not
sure it's the right abstraction in most cases, but that would surely
deserve it's purpose if technical implication is not huge.
> The idea is simple, and I've already started looking at the source
> code to see what is involved in doing this.
> So my proposal is:
> - We change the routing to support the idea of "composite routing", so
> that we can tell the routing engine that we do not want to just
> execute one action/controller, but instead we want to execute
> multiple.
> - We then create a new HttpHandler that handles this by instead of
> instantiating only one controller and calling its action, it
> instantiates as many as were defined (this could be done sequential or
> in parallel or support both).
> - Once all action execute, we bring it all together into one single
> response.
looking at pointed article and your description, I'm now unsure if
I've keep up with your idea.
is the rendering and calling being arbitrated by the view markup or is
it something completely separated which purpose is to populate the
view data context?
IMHO, first is best achieved via viewcomponents or using view engine
features (eg. spark have include with named typed parameters), second
is something I'm not sure I would like to use in a web context (just
me)
> If we go this path we could also implement what ASP.NET MVC does
> where they only support one model per view(ViewModel) and get rid of
> the PropertyBag to pass data to the view.
to me, using the dictionary adapter is as clean (and enforce I'm using
plain dto interface) and view model independant.
if extending MR using ViewModel, we still need access to the plain
property bag, which is the case in MSMVC
http://msdn.microsoft.com/en-us/library/system.web.mvc.viewdatadictionary(loband).aspx
http://msdn.microsoft.com/en-us/library/dd470798(loband).aspx
Nitpicking on MS: what is sad in MSMVC API is that ViewPage<TModel>
doesn't implement a polymorph able signature that would help
abstracting and share things accross viewengine, as is this semantic
it is strictly bound to webform viewengine...
Back to MR: I'm not sure of the implication on the viewengine
behaviour and API refactor required, it may require implementing some
semantics in the view engine to have that integrate nicely.
Still unsure if this is a one size fit all problem
I'm not in favor or against both of your propositions, I think looking
at MSMVC is required for the evolution, but there are also other
projects / ideas to seek.
I'll try to add some suggestion in MR UV next time, all theses words
just made me think at a naughty thing about dynamic actions:
this.DynamicActions["someaction"] = (enginecontext, controller,
controllercontext) => { do something }
or another one
this.DynamicActions["someaction"] = (FooForm form) => { do something
with idatabinder processed FooForm }
John Simons
so 2nd try!
Imagine you have a webpage that requires you to show:
- User name (logged on user) on the top right corner
- A navigation on the left had side
- A product in the middle (you looking at the product)
- The shopping cart items on the right had side
- The customer comments after the product
- And finally purchasing history (of the current logged on user)
You may have guessed, Yes I'm kind of talking about Amazon!
Currently to implement this in Monorail you would have something like
this in your action method:
PropertyBag["username"] = GetUsername();
PropertyBag["navigation"] = GetNavigation(currentLocation)
PropertyBag["product"] = GetProduct(id);
PropertyBag["cart"] = GetShoppingCart();
PropertyBag["customerComments"] = GetCustomerComments(id);
PropertyBag["purchasingHistory"] = GetHistory();
As you can see, a big mess! No separation of concerns!
Yes I know you can use ViewComponents for eg navigation, but then you
are adding complexity to your view.
One good and clean way to separate each one of these concerns is to
use ajax, so in this case we would have 6 ajax calls to MonoRail.
Each one of these ajax calls would call an action and would render
html in our website page, the advantage is also that they can run in
parallel :) Much faster rendering a web page in this style.
So what I'm proposing is pretty much what the ajax is doing, except we
would be doing it all server side.
So there would be 6 controller/action running in parallel and then
everything would come together server side.
Does this makes it more clear?
Cheers
John
> article such ashttp://blogs.intesoft.net/post/2009/02/renderaction-versus-renderpart...)
Gauthier Segay
thanks for further explanation, I'd say that what I understood but you
made this more clear, could you put a sample on a view template
implication in pseudo code? would it look like the article / MSMVC
implementation:
Html.RenderAction("List", "Project", new {personId = Model.Person.Id})
I think the sample you showed make the impact of the action
discoverable (but doesn't look appealing anyway ;)), moving that to
view templates make it a bit harder to track what logics runs just
looking at the controller.
I think the idea of parallelizing is interesting but this might have
implication on sync and lock access to underlying
System.Web.HttpContext, this might as well impact some infrastructure
like ISession for NH/AR.
I'm not sure such solution could work without some restrictions of how
you can access the MR / System.Web context.
Aside, in my applications, I think Filter level Action could
circumvent the need of such code in the controller, I use that
(IFilter) at a controller level to populate some bits of my *base view
model*, this eliminate most of the redundant property bag assignation
code/logic in multiple actions / controllers in my current needs,
something like:
[PropertyBagPopulationFilter(typeof(IHeaderContextPopulator))]
with a bit of ioc the solution is working ok enough for me at the
moment
> ...
>
> read more »
Henry Conceição
thousands of pageviews, then multiply it by 6. Also, you'll
multiplying the number of requests, nh/ar sessions, transactions and
etc.
Cheers,
Henry Conceição
Mauricio Scheffer
http://castle.uservoice.com/forums/38553-monorail-v3/suggestions/310267-add-renderaction-to-monorail
I've used it in ASP.NET MVC (v1 has it in MvcFutures and it will be
core in v2) and it's a nice, useful feature.
It all runs within the same request so there is no scaling / perf
problem.
On Jan 23, 11:03 am, Henry Conceição <henry.concei...@gmail.com>
wrote:
> >> > in parallel or support...
>
> read more »
Gauthier Segay
what John has explained will mean a single http request triggering
multiple actions (potentially on multiple controllers), the difference
of the MSMVC implementation with John proposition is that each action
would be triggered in parallel (which I think need some abstraction/
encapsulation on what is possible to execute because multiple thread
couldn't share NH ISession or web context) and would possibly defined
via routing instead (I'm unsure about John vision on view template
side)
Mauricio,
from your experience with ASP.NET MVC, would you say that this feature
is bringing something usefull considering what viewcomponents can do?
On Jan 23, 6:58 pm, Mauricio Scheffer <mauricioschef...@gmail.com>
wrote:
> There's already a suggestion on uservoice to implement RenderAction:http://castle.uservoice.com/forums/38553-monorail-v3/suggestions/3102...
Ken Egozi
--
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 castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
Mauricio Scheffer
separating concerns.
I have found it useful to model reusable, orthogonal concerns to a
page, things that not only display information but also have an
associated action. A good example is
http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/06/18/the-filter-viewdata-anti-pattern.aspx
On Jan 23, 7:05 pm, Ken Egozi <egoz...@gmail.com> wrote:
> Nothing is stopping anyone from spawning these calls in parallel,
> asynchronously, then get it all back, and spill the data into the property
> bag.
>
> in my view, the Controller's job is exactly that (plus binding data to/from
> http, and dealing with authentication via filters)
> and by "that" I refer to "call service layer to grab data, and stuff the
> data into properyBag".
>
> I have had much success in the past using the CCR to get required data in
> parallel.
> the nice thing is that you don't get many concurrency issues - the data
> querying is parallel, however the Context access is either before (when
> mining context data and pushing it to the service layer for querying) or
> *after* querying, when serially pushing the returned data into the prop=bag.
>
> so, I really don't thing that it is the FW responsibility, but rather the
> programmers.
>
> On Sat, Jan 23, 2010 at 11:39 PM, Gauthier Segay
> <gauthier.se...@gmail.com>wrote:
> > > > >> Nitpicking on MS:...
>
> read more »
John Simons
benefits of what I'm proposing.
But in this article the author chose to use RenderAction to separate
the concerns, but by doing that we now have mixed concerns on our view
file(the template itself).
What I'm proposing is to go one step further, and come up with
hopefully total separation of concerns including on the view file.
And because action takes care of one and only one concern (hence the
reason I said we don't need a PropertyBag any longer), we should be
able to render all these in parallel.
This way of separation is used quite frequently in Windows
applications where different developer teams take care of different
screen sections.
My vision to register all this would be something like this:
RoutingModuleEx.Engine.Add(
new CompositeRoute("ProductRoute", "/Products/<productId>/<action>")
.ComposedOf(
Controller("Product").Action("View"),
Controller("Login").Action("Info"),
Controller("ShoppingCart").Action("Summary"),
Controller("CustomerFeedback").Action("List"),
Controller("PurchasingHistory").Action("SummaryList"))
WithLayout("productlayout")
);
Cheers
John
On Jan 25, 1:12 am, Mauricio Scheffer <mauricioschef...@gmail.com>
wrote:
> It's not about getting data in parallel, but a different way of
> separating concerns.
>
> I have found it useful to model reusable, orthogonal concerns to a
> page, things that not only display information but also have an
> associated action. A good example ishttp://www.lostechies.com/blogs/jimmy_bogard/archive/2009/06/18/the-f...
> ...
>
> read more »
Mauricio Scheffer
layout or in the view, so it's the same as RenderAction. The only
advantage is the possibility of processing all these sub-actions in
parallel, but you'd lose the ability to define different parameters
for each sub-action (i.e. they would all get the same context, whereas
with RenderAction you can define different querystring/parameters/
context for each sub-action).
But the main problem I see with this is that I don't know who's really
in control of the response. If they all run in parallel and Product/
View decides that the product is offline and the response should be
redirected, what happens to the other actions?
PropertyBag would still be needed to render each sub-action.
Or maybe I got it all wrong and didn't understand you...
With RenderAction screen sections can be easily split among developers
since they are orthogonal and ultimately just regular controllers.
Then the main controller does the final composition.
SubControllers are a similar concept: http://mhinze.com/subcontrollers-in-aspnet-mvc/
Anyone here knows Seaside? I hear it's great at composability, we
could borrow some ideas from it.
Cheers
Mauricio
John Simons
On Jan 25, 10:15 am, Mauricio Scheffer <mauricioschef...@gmail.com>
wrote:
> But you would still have to place these concerns somewhere in the
> layout or in the view, so it's the same as RenderAction. The only
> advantage is the possibility of processing all these sub-actions in
> parallel,
Not really, in my example I have "WithLayout("productlayout")"
But I see this layout as being very dumb, agnostic to models or data,
the really only thing it would do is render the small areas in the
right places.
But yes, I haven't figure out everything yet, things like title of the
page, ....
All I want is to put this idea out there, so that we can discuss it
and see if it is something we want to move towards.
There are other things I have been thinking about, like we could have
Caching on a per Controller/Action, so eg the navigation doesn't
really change that frequently so it would be a very good candidate to
cache for a specific amount of time.
> but you'd lose the ability to define different parameters
> for each sub-action (i.e. they would all get the same context, whereas
> with RenderAction you can define different querystring/parameters/
> context for each sub-action).
Not sure if I follow you, you would still have this ability, your
action can access whatever it needs to do its job in the current
context.
With RenderAction on the view you would have to hardcode the
parameters/querystring right?
> But the main problem I see with this is that I don't know who's really
> in control of the response. If they all run in parallel and Product/
> View decides that the product is offline and the response should be
> redirected, what happens to the other actions?
Well, the question is, is it the responsibility of the Product/View
action to work out if it should be displayed? Separation of concerns.
Maybe we do require some kind of way of running Filters/Rules before/
after the compositeview?
> PropertyBag would still be needed to render each sub-action.
>
> Or maybe I got it all wrong and didn't understand you...
No, you are in the right track :) , I'm the one that is probably
trying to do something that is out there and simply doesn't make
sense!
>
> With RenderAction screen sections can be easily split among developers
> since they are orthogonal and ultimately just regular controllers.
> Then the main controller does the final composition.
Yes you can, but if the main controller does the final composition
then this controller needs to be aware of the others.
>
> SubControllers are a similar concept:http://mhinze.com/subcontrollers-in-aspnet-mvc/
>
> Anyone here knows Seaside? I hear it's great at composability, we
> could borrow some ideas from it.
Haven't looked at Seaside, but will research it, to see how they do
it.
I also like the approach that FubuMVC took, convention over
configuration.
Cheers
John
> ...
>
> read more »
John Simons
on this, since he mentioned it ;)
> ...
>
> read more »
David Burton
momentum, support from Microsoft and integration with Visual Studio,
and just because it's a really good framework. Trying to support too
many could be asking for trouble, although having simple helpers to
use references from Google's copies of the libraries or the like would
be a little nicety that wouldn't take much or create much clutter.
For me, coming from working with MSMVC and now looking at MR, the
reason why it's interesting is the integration with Windsor and
ActiveRecord, so to me separating them out risks making Castle less
appealing in compared to, say, just popping ActiveRecord into MSMVC.
One area where MSMVC sometimes still falls down with people getting
started is in getting a site up onto hosting... they've now got the
Web Platform installer, but that's not bullet-proof, and doesn't much
help for getting something running on cheap-ish hosting. Castle's
licencing and ability to run on both older versions of .NET and Mono
is an advantage here. You're never going to get Microsoft particularly
promoting how to run MSMVC on a Linux-based stack, but it's nice
flexibility to have for if a client has particular OS requirements.
Alternatively, a VM that offers a standard stack, version control and
continous integration could be interesting, too, if you can check out
a template project, modify it, check it in and have the changes
immediately verified and deployed within the VM, then that could
provide a development process that's neater and more powerful than the
standard MSMVC one.
I'd agree with the 'opinionated' approach - MSMVC doesn't fully adopt
the style promoted by the likes of Rails, and leaves you to make your
own choice as to database mapping framework and various other aspects.
You then end up with a bit of the separation of presentation and
logic, but with more of the configuration and decision-making still
needing to be done. You're probably better off looking at other major
frameworks like Rails to see what they do well that MSMVC doesn't
handle as neatly. The one that stands out most is probably generators
to quickly generate skeleton parts of the code.
The other concern that prompted me to look at Castle MonoRail rather
than sticking with MSMVC is the Microsoft tendency to not really fix
things properly and then just move onto something else. The original
ASP.NET improved over ASP, but didn't do AJAX properly. Their first
effort at AJAX was genuinely horrible. They've sort of got the right
idea now with MSMVC, but it doesn't play so well with IIS 6.5, rather
pushes LINQ and LINQ to SQL (still largely ignoring other databases),
and who knows how quickly attention will fall away as it moves on to
its next preferred model. A mature, stable framework that's that's an
open source alternative is definitely a good thing.
Anyway, hopefully I'll have a chance to contribute more (perhaps
starting by looking at documentation), but please do keep up with the
roadmap and development, because it's good to see it not being just
Microsoft MVC all the way.
David
On Jan 18, 12:05 pm, John Simons <johnsimons...@yahoo.com.au> wrote:
> Now that Monorail v2 is out, is time to start thinking about what is
> next from Monorail v3.
>
> I've already created a uservoice for Monorail v3:http://castle.uservoice.com/forums/38553-monorail-v3
>
> But there is a list that I've started working on (this list is still
> growing and there will be more added), most of these are just by going
> through the source code of Monorail:
>
> - Need to break the coupling that Monorail currently has on other
> libs, at the moment Monorail is dependant on nearly all other Castle
> projects. I think to do this we need to enforce the same mechanism
> that Windsor uses by the use of facilities to extend the container.
>
> - MonoRail routing, well this is a grey area that currently is not
> totally complete, my view on this is lets just use the
> System.Web.Routing
>
> - javascript support, I think we are supporting too many different
> frameworks in this area, we are trying to maintain prototype,
> jquery,delicious,...
>
> - Scaffolding, why is this tight to ActiveRecord?
>
> - How do we stay in business now with other offers like ASP.Net MVC,
> FubuMVC,... ?
>
> - The whole code base needs a clean-up, remove obsolete code, ...
>
Markus Zywitza
Would you care to make a blog post of it? This is something I'd like
to refer to when discussing with people over MR vs MSMVC.
-Markus
2010/1/27 David Burton <eloquen...@gmail.com>:
David Burton
http://www.aenikata.com/drupal/?q=node/13. The previous post was
incidentally about Castle MonoRail - as mentioned here I was proposing
a stack using MonoRail that gives you a skeleton project, source
control (GIT), project tracking (RedMine) and so on. I've started work
on that idea - once I've worked through the Mono/Linux-related
configuration issues (e.g. case-sensitive filesystem issues, gaps in
web.config security setting support, etc), then I'll put up a post
about that, along with some of the gotchas. Most of what's slowed me
down there has been issues configuring a VM, Linux, Postgres, RedMine,
etc.
David
On Jan 31, 6:37 am, Markus Zywitza <markus.zywi...@gmail.com> wrote:
> Great mail, David.
>
> Would you care to make a blog post of it? This is something I'd like
> to refer to when discussing with people over MR vs MSMVC.
>
> -Markus
>
> 2010/1/27 David Burton <eloquentdesi...@gmail.com>:
John Simons
http://haacked.com/archive/2008/04/10/upcoming-changes-in-routing.aspx
So it should now be considered a good candidate to replace our
implementation.
Cheers
John
On Jan 20, 1:14 am, SerialSeb <s...@serialseb.com> wrote:
> Note that we use a different routing engine from MVC because it was
> written before MVC. It's entirely possible to swap around the
> implementation of the URI repository to whatever implementation you
> want.
>
> There's one main reason why I do not want to support MVC's routing
> engine, it's greedy, which mean you can't run it side by side with any
> other components unless you add all the URIs mapped to another module
> as ignored routes.
>
> And of course, it's asp.net specific and OpenRasta is not, so we can't
> rely on it being there when we're running in-process or in our own
> managed AppDomain.
>
> On Jan 18, 9:16 pm, Krzysztof Ko¼mic <krzysztof.koz...@gmail.com>
> wrote:
>
> > inline,
>
> > On 2010-01-18 22:05, John Simons wrote:
>
> > > Inline
>
> > > On Jan 18, 11:31 pm, Krzysztof Ko mic (2)<krzysz...@kozmic.pl> wrote:
>
> > >> inline
>
> > >> On 18 Sty, 13:05, John Simons<johnsimons...@yahoo.com.au> wrote:
>
> > >>> Now thatMonorailv2 is out, is time to start thinking about what is
> > >>> next fromMonorailv3.
>
> > >>> I've already created a uservoice forMonorailv3:http://castle.uservoice.com/forums/38553-monorail-v3
>
> > >>> But there is a list that I've started working on (this list is still
> > >>> growing and there will be more added), most of these are just by going
> > >>> through the source code ofMonorail:
>
> > >>> - Need to break the coupling thatMonorailcurrently has on other
> > >>> libs, at the momentMonorailis dependant on nearly all other Castle
> > >>> projects. I think to do this we need to enforce the same mechanism
> > >>> that Windsor uses by the use of facilities to extend the container.
>
> > >> As long as we don't end up with tens of small assemblies with very few
> > >> types.
> > >> I'm all for breaking dependencies where it makes sense, but think
> > >> three time before creating yet another assembly for that.
>
> > > My idea is to make it their own packages with their own release
> > > schedules.
>
> > It feels like micromanagement to me, and I don't think we have enough
> > resources to play this game.I would try to avoid it, unless there's
> > really good reason to do so.
>
> > goodnight,
> > Krzysztof
>
> > >>> -MonoRailrouting, well this is a grey area that currently is not
> > >>> totally complete, my view on this is lets just use the
> > >>> System.Web.Routing
>
> > >> This would be a major breaking change. And while my experience with
> > >>Monorailrouting is none, does it not offer any advantages
> > >> over System.Web.Routing? OpenRasta for example, is a framework that
> > >> deliberately does not use SWR providing its own routing engine
> > >> While SWR has the advantage of being part of BCL and being very well
> > >> documented by books, blogs and MSDN, I would be very careful
> > >> when introducing such change.
>
> > > I would actually not consider it a major change.
> > > The benefit of using System.Web.Routing vs our own (which btw we have
> > > 2 implementations, so we would be breaking code anyway!) is that would
> > > be less code to maintain and an easier migration from someone coming
> > > from either ASP.Net MCV or FubuMVC.
> > > As it stands, our implementation does not offer any advantages over
> > > System.Web.Routing, actually I find the System.Web.Routing a lot more
> > > extendible than ours.
>
> > >>> - javascript support, I think we are supporting too many different
> > >>> frameworks in this area, we are trying to maintain prototype,
> > >>> jquery,delicious,...
>
> > >> I'd say due to immense popularity, we should put major emphasis on
> > >> JQuery
>
> > > I agree, we should concentrate our efforts on one javascript library.
>
> > >>> - Scaffolding, why is this tight to ActiveRecord?
>
> > >>> - How do we stay in business now with other offers like ASP.Net MVC,
> > >>> FubuMVC,... ?
>
> > >> We release more often :)
>
> > > Agree
>
> > >>> - The whole code base needs a clean-up, remove obsolete code, ...
>
> > >> Perhaps before v3.0 we should have a minor release first, with little
> > >> breaking changes
> > >> and mostly concentrated on clean up and polish?
>
> > > Agree
>
> > >>> The list is not finished, it is a work in progress.
>
> > >>> Cheers
hammett
On Mon, Jan 18, 2010 at 4:05 AM, John Simons <johnsi...@yahoo.com.au> wrote:
> Now that Monorail v2 is out, is time to start thinking about what is
> next from Monorail v3.
--
Cheers,
hammett
http://hammett.castleproject.org/
Krzysztof Koźmic (2)
ASP.NET MVC's portable areas and their lack in Monorail. Perhaps this
is something worth taking a look at?
James Curran
add to Castle. If you look at the MenuComponent in CastleContrib (at
the bottom, in the #if false block), You'll see a attempted an ad hoc
version some time ago.
First part: Having a single assembly with all code for a widget. ---
Done, just put the Controller-derived (say WidgetController) class in
an assembly, and add to your project.
(www.example.com/Widget/DoStuff.rails)
Next part: Having all associated files as resources in the assembly.
This is a bit tricker, and is best divided into two parts, (a) CSS,
Image, JS etc files (ie, files loaded by the browser), and (b) View
templates (ie, files used by the framework)
My first thought for handling (a) was a controller built into the
filework , FilesController, with an extensibilty point, so that
individual controller can include their files
(www.example/Files/Widget.rails?widget.css). However, what I think
would be easier is to merely create a PortableAreasController (derived
from SmartDispatchController, from which you would derive you widget),
which defines a Files action,
(www.example.com/Widget/Files.rails?widget.css) Actually, with a
default action defined, I should be able to reference it as
www.example.com/Widget/widget_css.rails. And that can be handled
just by a base class, which should take less than a day, and I can
stick in CastleContrib without affecting the Core.
(b) gets a bit trickier, and I believe involves adding features to the
framework itself (unless there's already an extensibilty point for
this).
Truth,
James
2010/3/15 Krzysztof Koźmic (2) <krzy...@kozmic.pl>:
James Curran
> (b) gets a bit trickier, and I believe involves adding features to the
> framework itself (unless there's already an extensibilty point for
> this).
Poking around the framework source, it seems there *is* an extension
point for exactly that (AssemblySourceInfo), so this whole thing
should be simple.
Truth,
James
Jan Limpens
discussion, MR's future should concentrate less in features and more
in architecture.
After all, functionality like the one provided by
SmartDispatcherController should be (and mainly is) provided as an
aspect.
The aforementioned functionality to render multiple controller actions
into a single view inverts the mvc paradigm and is no good idea in my
point of view. The view should not be able to make such decisions,
that's the controllers job.
The controller how it is today is a point of very low cohesion and one
of the points that should be implemented in a very different way.
Fortunately, with the availability of DynamicActions, the controller
could actually become the aspect providing Action-registration node,
it ought to be, imho.
This would make reuse much more efficient and would allow for better
composibility. Imagine, one has (fake MEF style)
public class MyController {
[Import]
public void MyAction {
}
}
[Export("MyController.MyAction")]
public class MyActionContent : DynamicAction{
//impl
}
[Export("MyController")]
public class MyActionLayout : DynamicAction{
//impl
}
this would solve composition pretty well - on the controller side.
On the view side, I completely dig OpenRasta's codec and content
negotiation paradigm. It is sad, MR does not offer such a clean
implementation.
Composite UI is much more difficult to envision, in my eyes, because,
contrary to WebForms, we do not have externally programmable views (we
can not say "Body.Insert(new Whatever())"). But from a separation of
concerns point of view, this is a good thing, probably. Still all
frameworks offering composite GUIs have this somewhere. The problem
is, that a view in a composite world cannot know of what parts it
consists, but probably the solution ought to be similar to the
controller: the view as a registration point for sub views based on
some conventions.
<% SubViews
.For(v => v.ForNode = "contentNode")
.With(v => viewData.GetData(v))
.OrderedBy(v => layout.ApplyOrder(v)) %>
Composition is a big deal (I'd love to read hammett's take on this,
but both of his blogs seem abandoned...) and is something really
difficult to implement currently.
Probably I should have said IMHO, much more often, so please take this
as the opinion this is.
--Jan
On Jan 24, 8:15 pm, Mauricio Scheffer <mauricioschef...@gmail.com>
> ...
>
> read more »
hammett
One thing that bites 'technologists' like us is thinking too much in
the terms of features disregarding the whole end-to-end story. asp.net
mvc, to give an obvious example, has less features than MonoRail, but
has a great end-to-end story including a nice VS integration.
One thing to use to avoid this pitfall is to have every feature
suggestion being backed up by at least three reasonable scenarios.
Another thing is listing the whole pain points associated with a
technology, an prioritize them. For MR, routing and creating a project
seems to be the bigger ones.
I can keep rambling on and on, but that's the essence of it.
Just two cents.
On Mon, Mar 15, 2010 at 7:26 PM, Jan Limpens <jan.l...@gmail.com> wrote:
> From my point of view, I hope nobody minds my late involvement in this
> discussion, MR's future should concentrate less in features and more
> in architecture.
--
Cheers,
hammett
http://hammett.castleproject.org/
bdaniel7
Pardon the intrusion as I'm not a contributor to the project.
From the poll (http://twtpoll.com/r/bbsrdu) it seems the NV has many
users, if not the most.
I think the integration of NV with VS 2008/2010 should be improved.
CVSI is doing a good job, however it still has bugs.
The intellisense stops working sometimes and the coloring is
scrambled.
Another thing which I consider important for making Castle framework
more apealing
is reviving the project wizard, which used to work in RC 3.
Regards,
Dan
On Jan 18, 2:05 pm, John Simons <johnsimons...@yahoo.com.au> wrote:
> Now that Monorail v2 is out, is time to start thinking about what is
> next from Monorail v3.
>
> I've already created a uservoice for Monorail v3:http://castle.uservoice.com/forums/38553-monorail-v3
>
> But there is a list that I've started working on (this list is still
> growing and there will be more added), most of these are just by going
> through the source code of Monorail:
>
> - Need to break the coupling that Monorail currently has on other
> libs, at the moment Monorail is dependant on nearly all other Castle
> projects. I think to do this we need to enforce the same mechanism
> that Windsor uses by the use of facilities to extend the container.
>
> - MonoRail routing, well this is a grey area that currently is not
> totally complete, my view on this is lets just use the
> System.Web.Routing
>
> - javascript support, I think we are supporting too many different
> frameworks in this area, we are trying to maintain prototype,
> jquery,delicious,...
>
> - Scaffolding, why is this tight to ActiveRecord?
>
> - How do we stay in business now with other offers like ASP.Net MVC,
> FubuMVC,... ?
>
> - The whole code base needs a clean-up, remove obsolete code, ...
>
Jan Limpens
discipline than a open source community driven project can reasonably
offer. After all, I imagine very few MRers say with the dlls they
initiated their projects with.
Things got worse with the dependency mix up the separation of the
castle project has brought us (together with some good things).
Personally I think that some horn-get triggering command in the
solutions dependencies folder should be the way to go.
Routing really is a pain point. Whenever something changes there, it
means lot of work for me, because to get my routing work the way I
imagine them, I need to make use of the more reclusive parts of that
API. From what I can see MVC has a simpler approach for that and
arguments not to take that one would have to be very convincing...
But still, the best of MR in my point of view is that it has a way of
convincing its users to go an architecturally sane way. It is much
more difficult to do something wrong, than to do something right - and
I think this is where the actual value lies. The concepts are simple
and clean and easy to understand (in most parts), the gritty parts are
abstracted out of sight. This makes extending the framework fun,
understanding it educating and maintaining quite friction free.
Now Asp.net MVC is more or less there, too. OpenRasta is conceptually
cleaner and simpler, but feature-wise relatively poor in comparison
(from what I could see), Fubu, I don't know. But all are going to
evolve and I would feel sad if MR would lose its vanguard state. Soon
(next release, or the one after that) asp.net mvc will be better than
the current mr in almost every aspect and has a huge community behind
it. It would not be a good decision to place your bets on a small foss
project, if there is another version of the same backed by the biggest
player in the marked, community behind it, almost open sourced,
extensible, etc...
So, I think, if MR does not want to carry the [Obsolete] attribute, it
will have to evolve radically.
More 2 cents here :)
Jan
> --
> 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 castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
>
>
--
Jan
Stuart
>
> Soon
> (next release, or the one after that) asp.net mvc will be better than
> the current mr in almost every aspect and has a huge community behind
> it. It would not be a good decision to place your bets on a small foss
> project, if there is another version of the same backed by the biggest
> player in the marked, community behind it, almost open sourced,
> extensible, etc...
>
> So, I think, if MR does not want to carry the [Obsolete] attribute, it
> will have to evolve radically.
>
May I say something likely to be unpopular? The .Net ecosystem is anti-
FOSS. For all the talk championing open source over the past couple
years, we can clearly see from the example of the MonoRail project
that .Net developers prefer proprietary software. They will use an
open source project only insofar as there is no alternative solution
from Microsoft. Meanwhile we will continue to see MSFT crank out
'official' solutions to compete with any sufficiently popular open
source project.
I've had the privilege of working completely outside the .Net
ecosystem for the past several months, using python, django,
postgresql, debian, etc. I'm spoiled. As freeing as working with the
Castle Project and NHibernate felt when I was coming from
'traditional' .Net development, I have to say that my present
experience with FOSS -- pure FOSS -- is a thousand times more freeing.
I love the Castle Project. If 'they' ever make me go back to Visual
Studio, Windows, and .Net, then MonoRail + Windsor et. al. will
continue to be my first-choice technology for buildling web apps. I
hope that you guys will be able to keep this project around and
thriving. You have an uphill battle in front of you. It shouldn't be
that way, but it is.
--Stuart
Jan Limpens
http://devlicio.us/blogs/rob_reynolds/archive/2010/02/01/warmup-getting-started.aspx
Sound just like the thing - backed via a hornget build (with some
architecture in place everybody can agree upon, maybe some switch for
the desired view engine), people could just get the newest builds,
tested and working well together from some castle build server.
In regards to FOSS and MS - things are changing, too. Nobody would
have guessed that MS ever would release sources for anything at all or
just use a FOSS project, JQuery, as it's mainly supported js engine
(even having something similar not all that bad ready). There is a
huge contrib movement towards mvc, that is entirely in community
hands.
We .netties have the luxury of having somebody bank the development of
a huge framework that encompasses 80% of everything needed. Java,
phytonists etc.. have to take care of themselves quite a lot more.
With both good and bad consequences...
Stuart
>
> In regards to FOSS and MS - things are changing, too. Nobody would
> have guessed that MS ever would release sources for anything at all or
> just use a FOSS project, JQuery, as it's mainly supported js engine
> (even having something similar not all that bad ready). There is a
> huge contrib movement towards mvc, that is entirely in community
> hands.
> We .netties have the luxury of having somebody bank the development of
> a huge framework that encompasses 80% of everything needed. Java,
> phytonists etc.. have to take care of themselves quite a lot more.
> With both good and bad consequences...
>
I'm not so much interested anymore in the fact that things are
'changing'. Changing can take decades. Things are *changed* elsewhere.
I reckon MSFT is just fine with things 'changing' so long as they get
to control that changing process and the 'changing' never results in a
full-blown change. I'm afraid that's where we are with open source in
the .Net ecosystem. Hopefully I'm wrong, but I wouldn't count on
it. ;)
I would have written essentially what you wrote above a year ago,
especially in regards to others "hav[ing] to take care of themselves
quite a lot more." However, my experiences with python/django/etc.
have not borne that out. Turns out Microsoft wasn't doing me anywhere
near the amount of favors I thought they were.
I'll [try to] be quiet now. I just wanted to share my perspective on
this matter.
Regards,
--Stuart
John Simons
My line of thought at the moment is why have a controller at all?
See Chad Myers post on it:
http://www.lostechies.com/blogs/chad_myers/archive/2009/06/18/going-controller-less-in-mvc-the-way-fowler-meant-it.aspx
I have been hacking MR to bend it the way I want, so far I'm able to
convert a request into a command (using convention over configuration)
and execute that command with a simple interface.
Eg.
Assume a request comes in for /Products/List
I then convert this request into ProductsListWebCall
And then I go to my container and do the following:
var webCallHandlers =
windsorContainer.ResolveAll<Handles<TWebCall>>(new { EngineContext =
engineContext, ControllerContext = context});
var webCall = Activator.CreateInstance<TWebCall>();
foreach (var handler in webCallHandlers)
{
handler.Handle(webCall);
}
And the Handle interface is:
public interface Handles<T> where T: WebCall
{
void Handle(T command);
}
public interface WebCall
{
}
As u can see I'm also injecting the ControllerContext and
EngineContext so that in the Handler I can do this:
public class ProductsListHandler :
Handles<ProductsListWebCall>
{
public IEngineContext EngineContext { get; set; }
public IControllerContext ControllerContext { get; set; }
public void Handle(ProductsListWebCall webCall)
{
ControllerContext.PropertyBag["message"] = "Hello from handler";
}
}
Sorry about the formatting of the code, I'll try to write a blog post
about it soon.
Cheers
John
> ...
>
> read more »
Henry Conceição
controller, is now called handler. With the downside that now I'm
obligated to implement an extra class honoring the web call contract.
But perhaps I didn't get the big picture...
Cheers,
Henry Conceição
John Simons
So here is something a bit more complex, and with a few more smarts.
Lets say that as part of displaying /Products/List we also display on
the same screen a shopping cart + product specials + recommended
products, actually lets say that we do this for any url that is part
of the Products "area" (/Products/*).
The way we do this using the Controller/Action is something like this:
public void List(){
PropertyBag["cart"] = GetCart();
PropertyBag["recommended"] = Recommended();
PropertyBag["specials"] = Specials();
PropertyBag["productsList"] = GetProductsList();
}
public void Search(){
PropertyBag["cart"] = GetCart();
PropertyBag["recommended"] = Recommended();
PropertyBag["specials"] = Specials();
}
public void ComingSoon(){
PropertyBag["cart"] = GetCart();
PropertyBag["recommended"] = Recommended();
PropertyBag["specials"] = Specials();
PropertyBag["comingSoon"] = ComingSoon();
}
And yes I know you can do a bit of refactoring here or use Filters,
but the point is that an action method has a lot of responsibilities
with this model.
Also, remember that your controllers tend to not just have one single
action method but many (this can make the Controllers quite large
classes!).
The way I would do this using Handles is (Note: I'm using inheritance
to work out what handles to execute):
public class ProductsListWebCall : ProductsWebCall{
}
public class ProductsWebCall : WebCall {
}
public class ProductsListHandler :
Handles<ProductsListWebCall>
{
public IEngineContext EngineContext { get; set; }
public IControllerContext ControllerContext { get;
set; }
public void Handle(ProductsListWebCall webCall)
{
ControllerContext.PropertyBag["productsList"]
= GetProductsList();
}
}
public class ProductsSpecialsHandler :
Handles<ProductsWebCall>
{
public IEngineContext EngineContext { get; set; }
public IControllerContext ControllerContext { get;
set; }
public void Handle(ProductsWebCall webCall)
{
ControllerContext.PropertyBag["specials"] =
Specials();
}
}
public class ProductsRecommendedHandler :
Handles<ProductsWebCall>
{
public IEngineContext EngineContext { get; set; }
public IControllerContext ControllerContext { get;
set; }
public void Handle(ProductsWebCallwebCall)
{
ControllerContext.PropertyBag["recommended"]
=Recommended();
}
}
public class CartHandler : Handles<WebCall>
{
public IEngineContext EngineContext { get; set; }
public IControllerContext ControllerContext { get;
set; }
public void Handle(WebCall webCall)
{
ControllerContext.PropertyBag["cart"] =
GetCart();
}
}
The advantage I get from using this model is hopefully total
separation of concerns on my handlers.
I will write a post about this, with sample code that I hope will
clarify a lot of the unanswered question in this thread.
Cheers
John
On Mar 22, 12:16 pm, Henry Conceição <henry.concei...@gmail.com>
wrote:
> For me, it appears to be just a rename. What we used to call
> controller, is now called handler. With the downside that now I'm
> obligated to implement an extra class honoring the web call contract.
> But perhaps I didn't get the big picture...
>
> Cheers,
> Henry Conceição
>
> On Sun, Mar 21, 2010 at 9:38 PM, John Simons <johnsimons...@yahoo.com.au> wrote:
> > Jan,
> > My line of thought at the moment is why have a controller at all?
> > See Chad Myers post on it:
> >http://www.lostechies.com/blogs/chad_myers/archive/2009/06/18/going-c...
> ...
>
> read more »
Alex Henderson
> ...
>
> read more »
John Simons
(I'm not too keen on the use of 'I' for interfaces any more, that can
be a different discussion)
public interface WebCall{}
public interface Handles<T> where T: WebCall
{
void Handle(T command);
}
Cheers
John
On Mar 22, 4:13 pm, Alex Henderson <bitterco...@gmail.com> wrote:
> I'm not sure that inheritance of commands (which are bound to form
> parameters etc.) is a good mechanism for determining handlers for a request,
> this limits your ability to compose things easily (you run up against the
> limitations of single inheritance etc.).
>
> Also would this be the mechanism used in place of things like filters - so
> effectively a handler of the base command class "WebCall" would behave like
> a BeforeAction filter (kinda). If so, isn't ordering of handlers then
> going to become an issue to implementing things like security,
> authentication etc. filters.
>
> Interesting discussion though.
>
> Cheers,
>
> - Alex
>
> ...
>
> read more »
Ken Egozi
> ...
>
> read more »
--
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 castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
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 - הכנס הקהילתי הראשון למפתחי דוטנט - בואו בהמוניכם
John Simons
The same way as I resolve Handlers, eg:
windsorContainer.ResolveAll<IRunBeforeAllHandlersFor<TWebCall>>(new { EngineContext = engineContext, ControllerContext = context});
windsorContainer.ResolveAll<IRunAfterAllHandlersFor<TWebCall>>(new { EngineContext = engineContext, ControllerContext = context});
We can even have validation done this way, eg:
windsorContainer.ResolveAll<IHandleValidationFor<TWebCall>>);
Eg.
public class ProductViewWebCall : WebCall{
public string ProductId { get; get; }
}
or
public class UserCreateWebCall : WebCall{
public string Name { get; get; }
public string Password { get; get; }
}
>how do you enforce ordering
That said, yes I do agree that sometimes you may want to run a handler first, specially if we have an authorisation handler.
I'm thinking about implementing the ordering the same way NServiceBus does it (see http://www.nservicebus.com/Documentation.aspx):
public void SpecifyOrder(Order order)
{
order.Specify(First<H1>.Then<H2>().AndThen<H3>().AndThen<H4>() //etc);
}
Please remember this is just a hobby at the moment and I know that there is still a lot to think about, also if I go down this path and get it working, I would create a new project and not call it MR because this is a huge change for Monorail users, that said this would definitely give us the edge over the difference between the MS implementation of MVC and our own :)
Cheers
John
From: Ken Egozi <ego...@gmail.com>
To: castle-pro...@googlegroups.com
Sent: Mon, 22 March, 2010 5:10:51 PM
Subject: Re: MonoRail roadmap/todos
Alex Henderson
config.For("/Product/Update/")
John Simons
Cheers John
Alex Henderson
Henry Conceição
are proposing.
One thing that we should avoid, imho, is the "class/interface
explosion" thing. Take fubumvc for example: to create a simple hello
world you need to write 4 classes.
1 - http://bistroframework.org/index.php?title=Quickstart
Cheers,
Henry Conceição