While I totally understand what motivates Scot's thinking here and know that we need to prioritize performance, stability and consistency, I would also like to make sure that we do not lose sight of some of our original architectural thinking—or at least my interpretation of it.
The separation of the front and back ends in OAE suggests advantages in that the primary user interface depends on and requires an API (for lack of a better term) from the back end that is then also available for other user interfaces (eg, mobile, integration, etc), and offers a lower level of effort for additional development/developers (eg, widgets). If OAE's primary user interface no longer relies on an open, backend API, that allows us to be less focused on that API, perhaps letting it drift. I would like to see OAE maintain a philosophy where its API keeps full pace with the native application. Perhaps there are ways to ensure both a current API and enact your thinking to improve performance/stability/consistency. -- Nate Angell Sakai Product Manager rSmart http://www.rsmart.com http://twitter.com/xolotl http://xolotl.org On Wed, Apr 18, 2012 at 10:57 AM, Scot Hacker <[email protected]> wrote: > Before we get into specifics about what would make a better front end, I > think we need a clearer picture of what it will mean for us to move to > server-side template rendering, since that move changes *everything* about > how the front end works. > > In my view/experience, it means that we take data objects handed to us by the > back-end and generate pre-rendered HTML. IOTW, it means we will no longer be > constructing the DOM client-side. This, in turn, means that the server is > not spitting out JSON* - we go straight from back-end logic to a > sophisticated template language that generates HTML (you've already seen my > wishlist for server-side template features and functionality). After initial > page load, any needed Ajax interactions will happen against callback > functions on the server. > > A change like this would mean a huge win in performance, and a huge win in > developer productivity. It would also mean a ton of work to rewrite all views > in the system. But most of the questions we're discussing here take a > completely different form if we're going to make this change. > > Can anyone say more about what it is intended with the move to server-side > template rendering? > > ./s > > * If we still need JSON to represent a public-facing API, we can do that by > allowing something like ?format=json on URLs, but JSON wouldn't be the > primary output of views. > > __________________________ > Scot Hacker > Senior Software Developer @ CalCentral > Educational Technology Services, UC Berkeley > > [email protected] > (510) 292-5586 > __________________________ > > > > > > > > _______________________________________________ > oae-dev mailing list > [email protected] > http://collab.sakaiproject.org/mailman/listinfo/oae-dev _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
