Thursday, 12 April 2012< ^ >
arjan has set the subject to: Zotonic - the Erlang CMS
Room Configuration

[00:12:55] maas.maarten.zeeman leaves the room
[07:02:56] maas.maarten.zeeman joins the room
[07:04:54] <maas.maarten.zeeman> The netbook went from 95 requests to 105 on the master. Really like the new admin arjan.
[08:20:33] maas.maarten.zeeman leaves the room
[09:28:37] maas.maarten.zeeman joins the room
[09:32:07] simon.smithies joins the room
[09:57:46] <maas.maarten.zeeman> Thinking about writing a simple dclass ua classification module for 0.8. Nothing fancy, but it would already allow one to simply select the right template from inside a template.
[10:14:20] arjan joins the room
[10:14:59] <arjan> cool
[10:15:05] <arjan> as a filter or something?
[10:15:37] <maas.maarten.zeeman> Or as a model. Don't know yet.
[10:15:59] <arjan> I think the ua itself is already available in the template
[10:16:41] <maas.maarten.zeeman> Yes, via m_req
[10:18:30] <maas.maarten.zeeman> We want to make a mobile version of channel.
[10:19:02] <maas.maarten.zeeman> Filter would nicely too indeed.
[10:21:23] <maas.maarten.zeeman> m_req['user-agent'] | ua[ .. ]
[10:22:22] <maas.maarten.zeeman> m_req['user-agent'] | classify
[10:25:30] <maas.maarten.zeeman> So you can use it as a poor mans template selection with an if tag.
[10:25:48] <arjan> indeed
[10:36:13] <Marc Worrell> The dClass stuff is available via m_req
[10:36:35] <maas.maarten.zeeman> In 0.8 :-)
[10:36:46] <Marc Worrell> m.req.ua_props
[10:36:50] <Marc Worrell> m.req.ua_class
[10:36:55] <Marc Worrell> in 0.9dev :p
[10:37:23] <Marc Worrell> you can backport to 0.8
[10:37:23] <maas.maarten.zeeman> The bleeding edge :-)
[10:39:20] <maas.maarten.zeeman> K. Thanks for pointer. Cool.
[11:24:00] <Marc Worrell> maybe we can borrow some ideas and/or code from this project: http://meteor.com/
[11:24:26] <Marc Worrell> or connect knockout.js to some updating/eventing on the server site.
[11:24:48] <Marc Worrell> which shouldn't be too hard, given our infrastructure :)
[11:25:03] <Marc Worrell> (and mod_signal in particular)
[11:43:20] <maas.maarten.zeeman> That is a really nice library.
[11:43:28] <Marc Worrell> knockout?
[11:43:40] <Marc Worrell> yes, I liked that one, it is small and lightweight
[11:43:47] <maas.maarten.zeeman> meteor
[11:44:02] <maas.maarten.zeeman> have to look at knockout.
[11:44:05] <Marc Worrell> meteor should have a lot of moving parts we can retrofit
[11:44:39] <Marc Worrell> knockout is very nice, I was thinking of hooking that one up, great for live updates.
[11:44:45] <maas.maarten.zeeman> Boy that looks a lot like mod_signal
[11:44:50] <maas.maarten.zeeman> (meteor)
[11:44:56] <Marc Worrell> same pattern :)
[11:45:07] <Marc Worrell> pubsub all over the place :p
[11:45:29] <Marc Worrell> which can be our stronghold, considering our server side technology.
[11:45:50] <maas.maarten.zeeman> We use zotonic rendering though for updates. It is fast.
[11:45:57] <maas.maarten.zeeman> (enough)
[11:46:11] Marc Worrell drawing up flow chart for user-agent classification
[11:46:26] <Marc Worrell> i think rendering on the server has big advantages
[11:46:39] <Marc Worrell> not in the least that we do the processing where the data is
[11:46:53] <maas.maarten.zeeman> Front enders can still do it. Otherwise they have to learn js
[11:47:01] <arjan> that's very different from meteor's philosophy
[11:47:18] <Marc Worrell> indeed, and those that can really use js are called programmers
[11:47:20] <arjan> they only put data on the wire, not HTML
[11:47:29] <Marc Worrell> we can do both :p
[11:47:36] <Marc Worrell> (html and data)
[11:47:40] <maas.maarten.zeeman> Or do they transform from template to js. That would be cool too.
[11:48:11] <Marc Worrell> for apps, yes
[11:48:21] <maas.maarten.zeeman> make a zotonic template which becomes a javascript lib which you can send data.
[11:48:27] <Marc Worrell> for sites, i prefer old fashioned tpls
[11:48:44] <arjan> yes I think handlebars works like that, compiling tpls to js, http://handlebarsjs.com/
[11:48:47] <Marc Worrell> you could compile a template-subset to a javascript
[11:49:14] <Marc Worrell> I like the idea that meteor can push js updates
[11:50:54] <maas.maarten.zeeman> Currently I use actions to push updates to the page based on signals. Works pretty nice.
[11:51:41] <maas.maarten.zeeman> The page hooks into a signal, and selects which action it wants to fire when this signal is emitted.
[11:52:27] <Marc Worrell> I have to build a Web App for a customer the coming weeks, for that I will check those libraries and come with a proposal.
[11:52:42] <Marc Worrell> (when someone else of you doesn't have some great ideas before :) )
[11:56:59] <maas.maarten.zeeman> knockout looks a bit weird.
[11:57:51] <maas.maarten.zeeman> Looks like a cms build on top of zope.
[12:00:32] <maas.maarten.zeeman> O no, zope template language. http://en.wikipedia.org/wiki/Template_Attribute_Language
[12:11:03] <Marc Worrell> Aaarrggghhhhh!
[12:11:36] <Marc Worrell> how does Meteor connect the values in the HTML to the server side values?
[12:13:58] <Marc Worrell> Q: about the user-agent class stuff. There is a nice edge use-case. When the user switches has multiple tabs open and switches to a different ua-class in a tab, what to do with the other tabs? Reload them with the new ua-class? I think we should have only a single ua-class per session/browser, otherwise it is unmanageable,
[12:16:28] <maas.maarten.zeeman> Same as with the language.
[12:17:54] <maas.maarten.zeeman> Don't know how meteor connects. Sounds like some comet/websocket thing.
[12:18:23] <Marc Worrell> probably
[12:18:26] <maas.maarten.zeeman> Funny is that I think they can connect the page when the js is executed.
[12:18:36] <Marc Worrell> it is based on Node.js - so will use that transport mechanism
[12:18:44] <maas.maarten.zeeman> on the client. In zotonic it is already connected :-)
[12:24:21] <maas.maarten.zeeman> It would be nice though to have some generic actions (like the jquery actions) for page updates. (Data or html)
[12:26:49] <Marc Worrell> maybe we can come up with a list.
[12:27:29] <Marc Worrell> I also would like a {% script %} …. {% endscript %} tag, for when you need to add 'onload' scripts to your page, which happens quite often.
[12:28:18] <Marc Worrell> (I wouldn't like to parse the <script> tags :) )
[12:28:45] <maas.maarten.zeeman> aha, was just typing that question
[12:29:01] <Marc Worrell> :p
[12:29:33] <Marc Worrell> shouldn't be too hard, should be mapped to {% wire action={script script="…"} %}
[12:30:16] <maas.maarten.zeeman> I usuaully use that one :-)
[12:30:18] <Marc Worrell> or to a #context{} with the content_scripts[] filled in.
[12:30:25] <Marc Worrell> (which is better)
[12:31:28] <Marc Worrell> Actually I can add this later, will need it :)
[12:33:58] <Marc Worrell> Hmmm, just on the mailing list: mod_menu,remove_invisible,
[12:34:12] <Marc Worrell> I guess the 'undefined' is the non-defined menu in the rsc.
[12:34:21] <maas.maarten.zeeman> Something in the context to send notification after a transaction would also be nice :-)
[12:34:26] <Marc Worrell> :s maybe we need a patch update
[12:34:47] <Marc Worrell> notification after the transaction?
[12:35:51] <maas.maarten.zeeman> Well if you send notifications inside a z_db transaction you are kind of generating a race condition. (and the possibility for multiple notifications)
[12:36:04] <maas.maarten.zeeman> (Found that out the hard way :-)
[12:36:51] <Marc Worrell> hmmm, the mod_menu:remove_invisible/3 should handle that error that is reported: remove_invisible(undefined, Acc, _Context) ->
[12:37:26] <Marc Worrell> @maas - aha, yes, to accumulate notifications, which should be send *after* the transaction is committed
[12:37:58] <Marc Worrell> interesting concept: z_notifier:on_commit (or something similar?)
[12:38:36] <maas.maarten.zeeman> Yeah. It is a kind of a gotcha right now. I had a something notify, transaction not ready, update not there. :-)
[12:39:07] <maas.maarten.zeeman> Or that we just collect the notifies when there is a transaction going.
[12:39:31] <maas.maarten.zeeman> Maybe a bit too magical.
[12:41:39] <maas.maarten.zeeman> Also funny when the transaction is replayed (will happen more often with sqlite)
[12:42:37] <Marc Worrell> dang! there is patch missing in mod_menu in 0.8.x, that is present in mod_menu in new-admin-design
[12:45:41] simon.smithies leaves the room
[12:53:17] <Marc Worrell> See if there are any other reports, otherwise we have to wrap up a 0.8.1 release
[12:53:28] <Marc Worrell> I pushed the patch
[12:53:34] <maas.maarten.zeeman> Are there more of those?
[12:57:36] <Marc Worrell> Not yet - so let's wait for today, otherwise we keep releasing.
[13:05:36] <maas.maarten.zeeman> Hmm, renumbering the category tree is not nice... Have to do something about it.
[13:06:27] <maas.maarten.zeeman> Sigh. Now zotonic things the users are blog articles.
[13:21:56] maas.maarten.zeeman leaves the room
[13:30:23] <arjan> hmmm you should have backported it to master when you fixed it in the other branch...
[13:38:02] <Marc Worrell> yep - guess it was part of the big "let's get the new admin working" effort
[14:19:39] arjan leaves the room
[14:22:21] arjan joins the room
[14:28:51] maas.maarten.zeeman joins the room
[17:08:41] <Marc Worrell> small sketch of the user-agent sniffing
[17:08:41] <Marc Worrell> http://zotonic.com/page/942/zotonic-user-agent-sniffing-draft
[17:09:26] <Marc Worrell> (also on the Zotonic MaxClass class: http://www.maxclass.com/en/media/inline/2012/4/12/zotonic_ua_class.pdf)
[17:09:29] <maas.maarten.zeeman> Nee maar, diagrammen :-)
[17:10:00] <Marc Worrell> isn't it nice ? :)
[17:10:06] <maas.maarten.zeeman> Yes very.
[17:19:41] <maas.maarten.zeeman> What is the js probe?
[17:20:36] <Marc Worrell> a small script in the template. it checks the size of the screen and input devices and posts those results back. Then we check what we got back and assumed it should be, and then re-assess the device class.
[17:21:16] <maas.maarten.zeeman> aha nice
[17:21:23] <Marc Worrell> For example: we might assume that some unknown Android device is a phone, but the probe detects a large touchscreen, so we re-asses it as a tablet. After re-assessing we then force a reload.
[21:39:35] arjan leaves the room
[22:29:31] maas.maarten.zeeman leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!