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

[Souheil CHELFOUH]

Hello Grokkers !!

Sorry, I have been a bit of a ghost, lately, on the mailing list.
I'm preparing everything to move out of Paris during the month of
october. Lots of things to do, and a lot of stress.

Anyway, what am I doing with Grok ?
Well, things didn't change since my last intervention.
I'm still developing Cromlech and Dolmen (for Cromlech).
So far, we have created the equivalent of the old Dolmen, coupled with
more infrastructural things, like native Traject use in Dawnlight
(Cromlech's publisher) and pluggable policy-users management-security
packages.
We also experimented coupling all that with SolR and ZODB-less
applications. This is Freedom, mates, Freedom !  :)

Hope to see you all and hear from you all soon, for a sprint or an equivalent.


2011/9/19 Sebastian Ware <sebastian at urbantalk.se>:
> 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>
>
>  @grok.require('protoncms.ViewContent')
>  def showDashboard(self):
>    self.effects = PageEffects()
>    view = getMultiAdapter((self.context, self.request), name='dashboard')
>    self.effects.simple_popup_message("Message", "Displaying Dashboard!")
>    self.effects.updateContent(view())
>    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
>
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> https://mail.zope.org/mailman/listinfo/grok-dev
>