[Grok-dev] The state of Grok projects in the cooking

Sebastian Ware sebastian at urbantalk.se
Mon Sep 19 09:57:52 EST 2011

Our design goal was to keep all the business logic on the server rather than move it to the client side. Also, we wanted to keep the Javascript code as thin and generic as possible in order to make it easier to test and to migrate to different Javascript-frameworks in the future.

We also wanted to make it "DOM-centric" so it looks a lot like standard client side DOM-manipulation. No new skills required.

Basically this is what happens:

1 user manipulates a button or link

2 the thin client intercepts the event and dispatches it to the backend using a couple of different strategies

  - call a JSON-method in the backend (most cases)
  - post to a view in an iframe (multipart posts with file content) which in turn dispatches to a JSON-method

3 the server-side JSON-method renders forms and views and returns HTML in a JSON-structure with instructions on how to update the DOM
  (these instructions map 1-1 to Mootools (in our case) DOM-manipulation features)

4 the thin client follows the instructions, stuff like:
  - inject html
  - update styling on an element 
  - execute client side Javascript code
  - subscribe to DOM-events for injected HTML

What we did server side was package all the DOM-manipulation code in ui-effect classes that are easy to use. Code will look something like this:

  <a target="json" href="/pcc/urbantalk/users/jhsware/showDashboard">Dashboard</a>

  def showDashboard(self):  
    self.effects = PageEffects()
    view = getMultiAdapter((self.context, self.request), name='dashboard')
    self.effects.simple_popup_message("Message", "Displaying Dashboard!")
    return self.effects.result

So we get the AJAX-manipulation stuff but still use the standard Grok form generation and validation. So you don't have to switch between Javascript and Python when implementing UI-features.

The snag is obviously network roundtrip and scaling. Some UI-interaction also require quicker feedback, but we have found that it is pretty snappy and works well both for front and back-end development.

Mvh Sebastian

19 sep 2011 kl. 09.32 skrev Jan-Wijbrand Kolman:

> On 9/16/11 10:43 , Sebastian Ware wrote:
>> Since we have quite low traffic on the Grok mailing lists I thought
>> it would be nice to hear what projects people are currently working
>> on with Grok.
> Thanks Sebastian for your "update". You're working on a lot of project, 
> cool to see they're based on Grok!!
> You might've noticed I've been "under water" for a while. Reason is 
> simple: we're very very busy rebuilding a largish mental health care 
> platform. Using Grok indeed :-)
> We still have all kinds of details to flesh out, and looking at the 
> things Sebastian is doing, I'm confident we indeed *can* flesh out these 
> details.
> Biggest technical hurdle to take at some point is making the UI more 
> dynamic and "application"-like. Currently we're mainly rendering pages 
> and the application flow uses the traditional "form-submit-page-reload" 
> pattern, in the process of getting the application's concepts clear.
> So, Sebastian, I'm very curious for *your* approach to making your 
> applications more "dynamic", like I'm interested to hear from others of 
> course.
> Anyway, I'll try to spend a little more time on Grok again :-)
> regards, jw
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> https://mail.zope.org/mailman/listinfo/grok-dev

More information about the Grok-dev mailing list