You can use the template component to render the contents of a model, but that’s limited to rendering model contents as far as I see.
So in summary, I’d just like to know how others are doing this, and what the recommended procedure for proper MVC development with Skuid.
You ask a very good question, and one that we’ve heard often at Skuid. If you are used to developing on Salesforce, then it’s very tempting to see Skuid as a super-powerful version of Visualforce. But we cram a lot of logic into Skuid, including our own Model framework, so it can be very confusing to figure out how Skuid avoids breaking the MVC architecture you are used to.
What is MVC?
It’s helpful first to take step back and consider MVC as an abstract concept rather than seeing it only through Salesforce’s implementation. MVC was originally developed for Smalltalk, and all the components of the MVC architecture were written in that single language: the Model was written in Smalltalk, the View was written in the Smalltalk and the Controller was written in Smalltalk.
The development of largely declarative Models that remove the need for writing code to directly access and manipulate your data (at the database level) is relatively new and Salesforce was one of the first to come up with a viable solution. There are still very few technologies that are capable of doing what Salesforce does at the same scale.
Another innovation that is relatively recent is to use a declarative language (typically XML-based) for your view and to use a templating language to passively reference values in your controller. Before this approach was developed, either the controller (aka “presenter”) was responsible for actively manipulating the view to insert data into the UI, or the View actually contained code/logic for fetching this data from the controller. Again, Salesforce was an early adopter and leader in this space (Microsoft’s XAML coming many months later).
While Salesforce’s declarative data model and UI language are very powerful innovations, MVC predates them. MVC is not tied to a particular implementation, rather it’s an abstract architectural pattern with the goal of separating concerns in your code to make it more maintainable and, possibly, reusable.
MVC in Skuid
So how does Skuid fit into Salesforce’s MVC architecture? In short, it doesn’t.
Skuid is not a more powerful version of Visualforce. Skuid is more like a client-side, in-browser application. While underneath it all it runs on Visualforce and Apex and uses Salesforce as its data store, it’s not accurate to approach Skuid development from the same place as you would Visualforce development. Skuid largely abstracts away the Salesforce architecture, in the same way that Salesforce abstracts away the Oracle database and Java code it runs on, in the same way that those technologies abstract away the Operating System and the binary code that they run on, etc.
Skuid is its own development platform, but that doesn’t mean that your code must now be a disorganized mess.
Architectural styles for libraries are very well documented already, so I won’t repeat too much here. The main thing to keep in mind is to make good use of namespacing (to decrease the risk of conflicts with other libraries) and to carefully organize your library around domains or services (so that related features are grouped together in an intuitive way).
For it’s UI, Skuid has adopted a Component-Based architecture. If developing your own components, it would be beneficial for you to read up on this approach and to follow some best practices. For example, Skuid uses component properties to define how each component instance connects with data. So, rather than hard-coding a model name, we expose a property so that the user can define this behavior. This makes our components easily re-usable and reasonably separates the UI implementation from the business logic.
Skuid is its own unique application and not an extension of Visualforce. Our goal is to remove the need for complicated, code-based solutions by providing a declaratively built application with a sweet library of awesome re-usable components.
In those cases where you need to extend Skuid, it’s best to look at what you are trying to accomplish and then select an architectural strategy that is best suited to your goals and to the technologies you are working with. While MVC provides many benefits, it’s not a one-size-fits-all architectural pattern.
As to your question about using Remote Actions from a Skuid page, check out this article:
Thanks for the explanation. I’ve found Skuid very handy for interacting with Salesforce objects, probably because of the premade components for that.
We have some visualforce pages that we wanted to use in Skuid popups, but Skuid had dropped the support for using them as includes, so that’s when we attempted to remake them as components. It proved to be a bit too much of a complication without a view mechanism and tools to produce html that is consistent with the Skuid theme, so we just direct to those pages with buttons for now.
Maybe I’m just a too inexperienced component maker though. I could look at the default component’s code for a better idea perhaps.
Your explanation would be a good blog post for the technical audience.
As far as embedding VisualForce pages in a popup:
VF Pages can be included in a Template component using iframe syntax, this is how we were able to show third-party integrations that come in through VisualForce pages on a standard Salesforce object detail page, like Evernote or Sharefile.
Here’s the code for your template, replace “VisualForce_PageName” with the API name of your VisualForce page: