One major concern in my team about Skuid is the seeming lack of a proper MVC support. Visualforce pages have backend apex controllers that perform necessary logic to produce the variables that they use. They are separate from the logic as the View. Skuid on the other hand seems to expect you to make a component which does the Controller and View part in javascript.
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.
I see you can embed a Skuid page inside a Visualforce page and use the variables in the apex controller behind it, but again, it seems to expect you to create the View in javascript (which is rather unwieldy).
Another nice Visualforce page feature is remote actions embedded in the javascript. Not sure if Skuid has as convenient a function, but it’d be good to know about.
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.
Hi Matthías,
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.
If you need to write substantial code with Skuid, then you are probably developing either your own Javascript library to extend Skuid’s core functionality or you are developing custom components. In either case, a good architectural strategy is extremely important to ensure your code is maintainable.
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.
If you are developing a completely custom user interface (using Skuid primarily for its Model architecture and API), then you may be interested in some Javascript implementations of MVC, including Backbone and Angular. Using these technologies, your templates would act as the View (similar to Visualforce), your Javascript code would act as the controller (similar to Apex) and Skuid could be used as your Model (similar to SObjects).
Summary
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:
http://help.skuidify.com/m/page-assignments-and-overrides/l/201793-using-the-skuid-page-visualforce-…
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.
JD,
Your explanation would be a good blog post for the technical audience.
Irvin
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:
