If passed, dialog contents will be loaded remotely via ajax. You can pass the URL (e.g. $.jqm({ajax:’remote/dialog.html’}) or extract it from an attribute of the triggering element. For instance, $(.jqm({ajax:’@href’}) would grab contents from bar.html if the triggering element was <a href=”foo/bar.html”>Open Dialog</a>. If a more complicated loading routine is desired, the onShow() callback should be leveraged.

So, letâ€™s say you have the above as described where you want to open a dialog for a list of items : the above dialog contains the very important trigger reference that is saying â€˜any a href with class â€˜triggerLinkâ€™ will fire an event to open the dialog.

Then, the added functionality is â€˜when this happens, itâ€™s going to call to the href of that trigger to determine the ajax form to load.

Letâ€™s say I have a html form that I want in the dialog. The href will need to point to that htmlâ€¦. ie. myform.html. I could just do the following:

When the trigger link is clicked ie. a href=â€#â€ class=â€triggerLinkâ€ (brackets removed) it will open a dialog with the myform.html as itâ€™s content.

This works particularly well with something like asp.net mvc. ie. my system is to use a ascx (a snippet of html basically) that is loaded by calling a controller action. Letâ€™s say I have a html form that I want in the dialog. The href will need to point to that htmlâ€¦. ie. mycontroller/myaction/1

when you click on the link, it will create the href attribute of the link, injecting in the url to call via ajax â€“ this will occur before the jqmodal will fire (thankfully) â€“ and open up the dialog with the corresponding html returned from the controller action. This also can be done through the â€˜onShowâ€™

onShow (callback)

Called when a dialog is to be shown. Be sure to show (set visible) the dialog.

If passed, dialog contents will be loaded remotely via ajax. You can pass the URL (e.g. $.jqm({ajax:’remote/dialog.html’}) or extract it from an attribute of the triggering element. For instance, $(.jqm({ajax:’@href’}) would grab contents from bar.html if the triggering element was <a href=”foo/bar.html”>Open Dialog</a>. If a more complicated loading routine is desired, the onShow() callback should be leveraged.

So, letâ€™s say you have the above as described where you want to open a dialog for a list of items : the above dialog contains the very important trigger reference that is saying â€˜any a href with class â€˜triggerLinkâ€™ will fire an event to open the dialog.

Then, the added functionality is â€˜when this happens, itâ€™s going to call to the href of that trigger to determine the ajax form to load.

Letâ€™s say I have a html form that I want in the dialog. The href will need to point to that htmlâ€¦. ie. myform.html. I could just do the following:

When the trigger link is clicked ie. a href=â€#â€ class=â€triggerLinkâ€ (brackets removed) it will open a dialog with the myform.html as itâ€™s content.

This works particularly well with something like asp.net mvc. ie. my system is to use a ascx (a snippet of html basically) that is loaded by calling a controller action. Letâ€™s say I have a html form that I want in the dialog. The href will need to point to that htmlâ€¦. ie. mycontroller/myaction/1

when you click on the link, it will create the href attribute of the link, injecting in the url to call via ajax â€“ this will occur before the jqmodal will fire (thankfully) â€“ and open up the dialog with the corresponding html returned from the controller action. This also can be done through the â€˜onShowâ€™

onShow (callback)

Called when a dialog is to be shown. Be sure to show (set visible) the dialog.

From my understanding RIA.NET is going to be CTP in July, however, with one of the core items being that RIA.NET will utilize the underlying ADO.NET Data Services (Astoria) protocol. I think this is a good move.

I must say, emphatically, that Domain-Driven Design by Eric Evans should be a required read by any software engineer in the field that is using an object-oriented language (I canâ€™t speak outside of that yet).

"This book belongs on the shelf of every thoughtful software developer."

2. Then we see patterns emerge in that code base – â€˜factory pattern, strategy pattern, inversion of controlâ€™ â€“ not even as much as â€˜in codeâ€™ but as a way to â€˜talk about codeâ€™. When one dev says to another â€˜we need to use a factory hereâ€™ â€“ itâ€™s a common language.

What is interesting is several projects Iâ€™ve seen were driven from a technology perspective and not from a domain driven one â€“ and have required someone coming in and â€˜savingâ€™ the project.

In my current project itâ€™s been an evolving model, expanding and refactoring as I have learned more of the business and itâ€™s rules. Our jobs as developers are twofold â€“ be experts in the technologies we work in , but more than that â€“ to learn how businesses work â€“ to relate to customers, etcâ€¦ itâ€™s quite a task! Many times I see organizations attempt to conquer the problem through the technology only without really grasping the domain being modeled.

I started with the layered approach, and honestly began to learn how to shape the parts as the knowledge of the domain began to shape and form. Evolving is the keyword, to me though â€“ itâ€™s a learning process, there are times that difficult decisions are made when shaping the code, and yet when trying to stick close to first being conscious and aware of â€˜howâ€™ Iâ€™m writing the code. Having a DDD up front, separating the domain, repositories, understanding â€˜specificationâ€™, â€˜factoriesâ€™, etcâ€¦ all produce an environment where the software can shape and grow without becoming too unwieldy. Eric Evans helps to shape and form his experience is a way that provides insight and wisdom into domain-driven development.

First off, itâ€™s really a shame that when an assembly is expecting a certain other assembly that the error messages would indicate which assembly is failing.

Case in point â€“ MvcContrib.Castle was built with Castle.Windsor 1.x – but the only error I get when building my project with the new Castle.Windsor 2.0 was that an assembly was expecting Castle.Windsor 1.x

I was pulling my hair out trying to figure it out â€“ since I updated NHibernate to 2.1 with the new proxy setup (Iâ€™m using Castleâ€™s DynamicProxy) I was fishing around attempting to figure it out.

Luckily I ran a nunit test that uses all those pieces minus the MvcContrib.Castle. It worked. So I was still stumped.

Finally it hit me that the MvcContrib had a register controllers functionality I was using that is sorta an adapter for Castle.Windsor.

So I went to get the latest, assuming that MvcContrib.Castle would be using the latest version of Castle.Windsor 2.0 which finally came out as a non-betaâ€¦ nope.

I ended up getting the contrib source code, and rebuilding the MvcContrib.Castle pieces I needed with Castle.Windsor 2.0.

That is frustrating â€“ most of it because of Visual Studio not giving me the pertinent information needed on why it failed.

Ah well. At least I figured it out and got it to all work in the end 🙂