Los Techies - Latest Comments

Re: Patterns of Compositional Architecture: Domain Specific Languages

PowerPoint Recovery — Mon, 14 May 2012 01:50:00 -0000

This is very useful to many readers like me.

Re: Running Jasmine in .NET

Abraão Alves — Tue, 10 Apr 2012 13:17:23 -0000

Jasmine testrunner in VisualStudio, console, browser, teamcity with one plugin package chutzpah.codeplex.com

Re: Patterns of Compositional Architecture: Domain Specific Languages

keylogger — Tue, 03 Apr 2012 01:24:57 -0000

Good post. I are very interested in the article!

Re: Running Jasmine in .NET

jmarnold — Mon, 05 Mar 2012 17:08:35 -0000

Tom McKearney I think that I didn't properly communicate the origins of this tooling. It was born out of FubuMVC work and thus does not follow the standard that you may be used to.

By "All .NET web templates", I think that you're referring to "All ASP.NET MVC web templates". We use a top-level content folder that is used as the primary directory for all assets (scripts, styles, images). This then feeds into our asset pipeline giving you a lot of power and control over each file.

Re: Running Jasmine in .NET

Tom McKearney — Mon, 05 Mar 2012 16:05:18 -0000

Seems a little odd to buy into the standard delivery mechanism of the code via NuGet, yet require non-standard (for ASP.NET) location of the "Scripts" folder. All .NET web templates have "Scripts" as a root-level folder.

Re: Running Jasmine in .NET

Derick Bailey — Tue, 28 Feb 2012 11:40:46 -0000

+1 to the annoyance! it gets messy and painful, fast.

Re: Running Jasmine in .NET

jmarnold — Tue, 28 Feb 2012 11:36:39 -0000

RE: The standalone runner, you are right and I'll make an update to the post for that. I was attempting to refer to the pain involved with maintaining either individual runners or one big one. This is only annoying when you get into script dependencies.

Re: Running Jasmine in .NET

Derick Bailey — Tue, 28 Feb 2012 10:42:31 -0000

This couldn't have been better timed! I was just looking for some tips from the .NET world on using Jasmine with ASP.NET MVC. :)

I'm definitely going to be trying Serenity ... maybe even later today as I was hoping someone would create a Jasmine runner for .NET. :)

FWIW: I think the statement "For each spec file that you want to test, you need an equivalent test runner html file" is a bit off. When I use the standalone runner (as I'm doing now) I put all my specs in the one runner. This really isn't any different than using an automated runner, where all of the specs are run. The big difference is that you have to manually maintain the spec runner html file, and it's difficult to integrate in to a build process, as you pointed out.

Re: Our Ajax Conventions–Clientside Continuations

jmarnold — Tue, 21 Feb 2012 01:22:30 -0000

Yes, precisely. We actually plugin to $.ajax as a global convention. Basically if you call: $.ajax and do not specify a success callback, then this fires:
https://github.com/DarthFubuMV...

If you want to participate in that pipeline, you can call $.continuations.applyPolicy. (I cover this in my latest post http://lostechies.com/josharno...

You can also specify a continuationSuccess callback to $.ajax that lets you hook in before the pipeline. Or just provide a success callback and override altogether.

Re: Our Ajax Conventions–Clientside Continuations

Ryan — Tue, 21 Feb 2012 00:24:20 -0000

Excellent. I just realized I could mix event streaming and still use a traditional $.ajax() success callback to have it basically skip this whole pipeline when events are not needed. I was thinking you routed all responses through Amplify.

Re: Our Ajax Conventions–Clientside Continuations

jmarnold — Mon, 20 Feb 2012 23:35:34 -0000

Let's split those two up for clarity: the server simply tracks the correlation id so you have more control of your requests. Honestly, this is most beneficial in one place: automated testing. We keep track of pending requests so that we have a fairly reliable condition to test against while we "wait" for async stuff to process.

The topic/payload piece is just part of the pipeline and are completely optional. We've found that the continuations represent more of a snapshot of the system state and then we layer on metadata. That's vague so let me expand on that with an example:

Our system is time-sensitive and we capture "timestamps" for entities in the system (e.g., "The patient was here at 12:00"). Our first pass at the endpoint for this sent back a continuation with the topic/payload of: "timestamp-updated"/{ relevant entity info }. That was then relayed through our clientside event aggregator. When websockets were introduced, the clientside didn't have to change because it was already listening for that topic. My point being: the topic/payload thing works great for event-based systems (i.e., event sourcing).
I understand your hesitation about the mixing of UI/non-UI concerns but consider it from more of an API approach where you provide entity-related information. An example being: Create a User. The response could return the id of the User and some urls (github does this in their api when requesting resources that are paginated).

Re: Our Ajax Conventions–Clientside Continuations

Ryan — Mon, 20 Feb 2012 23:09:06 -0000

This is very cool! One question though. Whenever you request data from the server do you have to send a "topic" with the payload, or do you use the correlationId somehow? It seems that requiring a topic server-side could lead to some mixing of UI and non-UI concerns. As far as I could tell, correlationId is only available on the "AjaxCompleted" event. I suppose if you are streaming multiple results with web sockets the topic concept makes more sense.

Re: Our Ajax Conventions–Validation

What a wonderful article? You have described very well. How you got this idea? Great work.

Re: Our Ajax Conventions–Validation

web hosting — Mon, 09 Jan 2012 23:46:52 -0000

I get it clear idea what i am expecting all the things get it from through this blog.Above all the points are explained very clearly.

Re: Our Ajax Conventions–Request Correlation

jmarnold — Sat, 07 Jan 2012 23:05:13 -0000

Interesting. Would love to hear more about what you're doing with that ;).

We carefully choose our usage of amplify but it serves as a standard event aggregator for our system. One of the advantages of publishing the continuation (w/ the correlation id) through amplify is that we can have multiple subscribers.

An example of another subscriber would be for some of our dialogs that hit the server for information. We can conventionally display a loading state and then transition into the content when it's available.

Re: Our Ajax Conventions–Request Correlation

Joey Vano — Sat, 07 Jan 2012 11:42:47 -0000

Very cool.

I do something similar and use behaviors to issue tokens and track duplicate requests (nonce). I push it through the request headers and listen onbefore and ajaxcomplete, similar to what you did, just not through Amplify.

Re: Modularity via Bottles

jmarnold — Thu, 05 Jan 2012 20:50:42 -0000

This is something that has come up a few times. The short answer is: no but soon. Unless of course someone added it and I don't know about it.

Re: Modularity via Bottles

Johannes Hansen — Tue, 03 Jan 2012 01:33:25 -0000

Does bottles support inter-bottle dependencies?

Re: FubuMVC–Action discovery

Rauhr — Mon, 17 Oct 2011 11:17:45 -0000

IActionSource is what set Fubu apart from any other framework out there right now. To be able to scan your application and packages for that matter and generate endpoints... If you get cleaver you can really dry up your code. I think this power is handover fist more powerful than lets say "rails scaffolding"

Re: Modularity via Bottles – Continued

jmarnold — Thu, 13 Oct 2011 00:55:59 -0000

Jay Smith I'm going to try and answer this question carefully as I am NOT intending to speak ill of any of the alternatives that you mentioned.

Here's the bottom line: ASP.NET MVC was not and is not built around highly compositional concepts. Therefore, your extensibility points are limited. They may work great for most teams but they limit you in what you can accomplish. As such, PortableAreas never really made it that far. MvcTurbine comes a LOT closer to what we're trying to accomplish.

Let me put it this way: If you used Bottles in ASP.NET MVC, you'd get DI-enabled Blade implementations (from the limited knowledge that I have of Blades) + PortableAreas. You probably wouldn't get much else than that.

We get much more bang for our buck in FubuMVC because the framework is designed around a semantic model that can be modified by Bottles (and anything else for that matter). So not only can you extend an application with a reusable block of functionality, you can modify existing functionality (e.g., add validation to all routes, switch all POST routes to serialize their results to JSON). The options really become limitless.

Re: Modularity via Bottles – Continued

Jay Smith — Wed, 12 Oct 2011 10:03:21 -0000

How does this compare to MvcContrib's PortableAreas, or MVC Turbine's blades?

I am looking for a modular approach to creating MVC applications, especially in regards to pieces that are common accrose application. ie user management and security, etc.

Re: Modularity via Bottles – Continued

jmarnold — Tue, 11 Oct 2011 23:41:43 -0000

Matt Sollars Jeremy's team made heavy use of extension properties: http://codebetter.com/jeremymi...

These extensions could then be loaded into your configuration via an IActivator.

You could also hook into your ORM's configuration by loading additional mappings from an IActivator. For example, you could have an entire new set of entities and screens in a bottle.

FubuFastPack has some of this infrastructure in place and could serve as a good reference point for you. And of course, there's always the mailing list :)

Re: Modularity via Bottles – Continued

Matt Sollars — Tue, 11 Oct 2011 09:55:19 -0000

Nice, Josh. I am very interested to hear more on Bottles and how it has been used to make customizations to an existing website product for an individual customer (Jeremy mentioned that Dovetail used it for this).

However, the thing I'm most fuzzy on is how you would augment business logic in your domain entities with a Bottles package. Would I need to change how I configure my ORM, so it could return a different entity descendant if a package was loaded?

Re: Modularity via Bottles

Andrei Volkov — Tue, 06 Sep 2011 14:10:54 -0000

Same here. I'm dumb. Explain me what it is.

Re: Modularity via Bottles

jeremydmiller — Tue, 06 Sep 2011 09:11:03 -0000

As Josh said, there's a "linking" mechanism to just reference an external project on the file system as a "Bottle" for development mode (it would work in production mode too, but I'm not entirely sure why you'd do that).

Also, Bottles does not require you to embed any resources, views, content, what have you if you use the Zip file mode.