Dear Smalltalkers,
I think it can be safely claimed that Aida/Web is a first Smalltalk web framework, even more, one of the first frameworks at all to integrate HTML5 WebSockets for so called realtime web apps. Realtime in sense that values on the page are updated immediately when value changes on the server, without needing to manually reload a page. You can see that in action from WebSocket-capable browsers (latest Firefox and Chrome) if you open in two browsers the online Aida realtime counter demo, click buttons on one and observe changes instantly in both browsers: http://demo.aidaweb.si/demos?view=realtime And how easy is using real-time in your code? See the simplified code of above demo: WebDemoApp>>viewRealtime | e counterElement | self enableRealtime. counterElement := e add: self counterElement. (e addButtonText: ' Decrement ') noSubmit; onClickDo: [self observee decCounter]. (e addButtonText: ' Increment ') noSubmit; onClickDo: [self observee incCounter]. self observee onChangeDo: [counterElement update] on: counterElement app: self. self add: e. WebDemoApp>>counterElement | e | e := WebElement newSpan. e style: 'font-size: 40px'. e addText: self observee counter printString. ^e To describe this code a bit: you first enable realtime for this view of demo App. Element on the webpage to update in realtime must be created in a separate method (#counterElement). After buttons for increment and decrement we come to the main part - registering the block to execute on every change of domain object. Calling simply #update to the counter element is enough to be updated on all browsers which currently observe that counter demo. How this works? Behind the scenes a so called realtime channel is open between browser and Aida server. This WebSocket based channel is bidirectional and full-duplex, meaning that Aida can send back to the browser a message at any time. In above case a command to update the counter element is sent back to all browsers immediately after counter is changed. New Aida 6.5 Interim release is released for Squeak, Pharo and VisualWorks and available from usual places. See http://www.aidaweb.si for more. Everyone is welcome to try it and come with suggestions how to use this new feature, how to improve it, .... Further read: http://www.aidaweb.si/websocket%20support http://www.swazoo.org/websocket Best regards Janko -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si |
On Thu, Nov 01, 2012 at 08:36:35PM +0100, Janko Miv??ek wrote:
> Dear Smalltalkers, > > I think it can be safely claimed that Aida/Web is a first Smalltalk web > framework, even more, one of the first frameworks at all to integrate > HTML5 WebSockets for so called realtime web apps. Realtime in sense that > values on the page are updated immediately when value changes on the > server, without needing to manually reload a page. I'm afraid that I have not been keeping up with web application development, but this sounds really interesting. I have worked with automotive manufacturing for many years, and being able to do real time displays like you describe here could be a real game changer. Dave |
Dne 01. 11. 2012 21:52, piše David T. Lewis:
> On Thu, Nov 01, 2012 at 08:36:35PM +0100, Janko Miv??ek wrote: >> I think it can be safely claimed that Aida/Web is a first Smalltalk web >> framework, even more, one of the first frameworks at all to integrate >> HTML5 WebSockets for so called realtime web apps. Realtime in sense that >> values on the page are updated immediately when value changes on the >> server, without needing to manually reload a page. > I'm afraid that I have not been keeping up with web application development, > but this sounds really interesting. I have worked with automotive manufacturing > for many years, and being able to do real time displays like you describe > here could be a real game changer. I actually need realtime web app support for something similar: to notify about some discrepancies on gas pipeline like some flowmeter overloaded, malfunction of some equipment, some other urgent situation etc. Those notifications will be shown on otherwise normal web app which is open all the time at the user desktops, because it is used daily for other tasks. See also a similar GSoC project by Rustem Khubbatov: HMI (Human-Machine Interface) with Amber http://gsoc2012.esug.org/projects/mmi-amber https://dl.dropbox.com/u/792245/GSoC-HMI_with_Amber.mp4 Best regards Janko -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si |
On Thu, Nov 01, 2012 at 10:53:03PM +0100, Janko Miv??ek wrote:
> Dne 01. 11. 2012 21:52, pi??e David T. Lewis: > > On Thu, Nov 01, 2012 at 08:36:35PM +0100, Janko Miv??ek wrote: > > >> I think it can be safely claimed that Aida/Web is a first Smalltalk web > >> framework, even more, one of the first frameworks at all to integrate > >> HTML5 WebSockets for so called realtime web apps. Realtime in sense that > >> values on the page are updated immediately when value changes on the > >> server, without needing to manually reload a page. > > > I'm afraid that I have not been keeping up with web application development, > > but this sounds really interesting. I have worked with automotive manufacturing > > for many years, and being able to do real time displays like you describe > > here could be a real game changer. > > I actually need realtime web app support for something similar: to > notify about some discrepancies on gas pipeline like some flowmeter > overloaded, malfunction of some equipment, some other urgent situation > etc. Those notifications will be shown on otherwise normal web app which > is open all the time at the user desktops, because it is used daily for > other tasks. Yes, that's the idea exactly. I think I need to educate myself about Aida :) > See also a similar GSoC project by Rustem Khubbatov: > > HMI (Human-Machine Interface) with Amber > http://gsoc2012.esug.org/projects/mmi-amber > https://dl.dropbox.com/u/792245/GSoC-HMI_with_Amber.mp4 > Very interesting stuff. Thanks for these links also. Dave |
In reply to this post by Janko Mivšek
We have two test failures related to time zone offset handling:
TimeStampTest>>testFromSeconds TimeStampTest>>testReadFromA1 In #testFromSeconds, we compare a TimeStamp created from an integer seconds to another TimeStamp created from strings. They are intended to refer to the "same" time stamp, but one has a time zone offset and the other has the offset set to zero (UTC), more or less like this: tsFromStrings := TimeStamp date: ('1-10-2000' asDate) time: ('11:55:00 am' asTime). tsFromStrings. ==> 10 January 2000 11:55 am tsFromStrings offset. ==> 0:00:00:00 tsFromIntegerSeconds := TimeStamp fromSeconds: 3124958100. tsFromIntegerSeconds. ==> 10 January 2000 11:55 am tsFromIntegerSeconds offset. ==> 0:01:00:00 I believe that the discrepancy is related to the change we did in trunk here: Name: Kernel-cmm.671 Author: cmm Time: 10 February 2012, 4:58:49.106 pm Decided against the localized vs. globalized mode. Timespans created in the context of an offset will start in that offset. When no context is available, the defaultOffset for Timespans must be zero. For example, two ways to make a Date for today: Date today. 'start is midnight at offset zero. Will compare successfully to other Date today results.' DateAndTime now asDate. 'In this case, the start is midnight of the local time-zone. It can only compare equally to Dates of its time-zone.' I am not sure how this should be handled. Chris, can you comment? Thanks, Dave |
I see you already committed a patch. TimeStamp will be going away in 4.5.
- Chris On Sun, Nov 4, 2012 at 8:55 AM, David T. Lewis <[hidden email]> wrote: > We have two test failures related to time zone offset handling: > > TimeStampTest>>testFromSeconds > TimeStampTest>>testReadFromA1 > > In #testFromSeconds, we compare a TimeStamp created from an integer seconds > to another TimeStamp created from strings. They are intended to refer to > the "same" time stamp, but one has a time zone offset and the other has > the offset set to zero (UTC), more or less like this: > > tsFromStrings := TimeStamp date: ('1-10-2000' asDate) time: ('11:55:00 am' asTime). > tsFromStrings. ==> 10 January 2000 11:55 am > tsFromStrings offset. ==> 0:00:00:00 > > tsFromIntegerSeconds := TimeStamp fromSeconds: 3124958100. > tsFromIntegerSeconds. ==> 10 January 2000 11:55 am > tsFromIntegerSeconds offset. ==> 0:01:00:00 > > I believe that the discrepancy is related to the change we did in trunk here: > > Name: Kernel-cmm.671 > Author: cmm > Time: 10 February 2012, 4:58:49.106 pm > > Decided against the localized vs. globalized mode. Timespans created in > the context of an offset will start in that offset. When no context is > available, the defaultOffset for Timespans must be zero. For example, > two ways to make a Date for today: > Date today. 'start is midnight at offset zero. Will compare > successfully to other Date today results.' > > DateAndTime now asDate. 'In this case, the start is midnight of the > local time-zone. It can only compare equally to Dates of its time-zone.' > > I am not sure how this should be handled. Chris, can you comment? > > Thanks, > Dave > > |
Free forum by Nabble | Edit this page |