ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Kenneth Tilton
Screenshots: http://github.com/kennytilton/qooxlisp/downloads

Intro: http://wiki.github.com/kennytilton/qooxlisp/

Congrats to the qooxdoo team for a great product.

kt

--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Thomas Herchenroeder
Nice work, Kenny. Maybe you want to add yourself to the development
platforms wiki page.

T.

On 05/24/2010 09:53 PM, Kenneth Tilton wrote:
> Screenshots: http://github.com/kennytilton/qooxlisp/downloads
>
> Intro: http://wiki.github.com/kennytilton/qooxlisp/
>
> Congrats to the qooxdoo team for a great product.
>
> kt
>

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Jean-Baptiste BRIAUD -- Novlog
In reply to this post by Kenneth Tilton
Congratulation ! I like LISP :-)

Just curious :
On software architecture point of view, you may not use all the power of client-side CPU.
Why did you use server-side CPU to produce GUI ?
GUI doesn't need to be served by server, only data has to ...

On 24 mai 2010, at 21:53, Kenneth Tilton wrote:

> Screenshots: http://github.com/kennytilton/qooxlisp/downloads
>
> Intro: http://wiki.github.com/kennytilton/qooxlisp/
>
> Congrats to the qooxdoo team for a great product.
>
> kt
>
> --
> http://www.stuckonalgebra.com
> "The best Algebra tutorial program I have seen... in a class by itself."
> Macworld
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Kenneth Tilton


Jean-Baptiste BRIAUD -- Novlog wrote:
> Congratulation ! I like LISP :-)

:)

>
> Just curious :
> On software architecture point of view, you may not use all the power of client-side CPU.
> Why did you use server-side CPU to produce GUI ?
> GUI doesn't need to be served by server, only data has to ...

Right now I am just exploring. If performance is good we have the
advantage of a seamless application model vs one with the client over
here and the data over there and forever linking the two with HTTP
requests. So far performance looks good. btw, the client CPU /is/
serving the GUI: the server just sends over some strings (JS code) that
direct the building of the GUI. If the GUI is static, no strings need
get sent after start up. Startup already sends over quite a bit of code
so I do not think this will stand out. Yes, once up more events get
flown back to the server, but then most event handling will need data so
a request (or three) happens anyway.

Meanwhile, if something in particular turns out to be slow, nothing
stops us from writing some JS the usual way. Kinda like the days of
hand-coding assembler if the 3GL compiler could not generate tight
enough code. Possibly something like tracking mouseover or individual
keypresses might require this. We'll see, but even if so it will be a
local optimization leaving the big win of seamless development intact.


The interfaces I create tend to be dynamic and change shape as the user
works and the underlying data model changes. This means the bifurcation
of data and GUI is not really there: the GUI /is/ data decided by the
server code in contemplation of the model data. ie, Yes, I have real
problems with the classic idea of model-view in which the view is so
detached from the model. It's a good dichotomy, but should not be
reflected in a division of the code base into client code and server
code, as I see it.

But that is just rationalization: the really big win is being able to
forget the client-server interface, almost forget qooxdoo/javascript,
and have the whole application in one place, both for coding ease and
for communication of view with model -- it's easy, they are in the same
program! A Lisp program. :)

cheers, ken



>
> On 24 mai 2010, at 21:53, Kenneth Tilton wrote:
>
>> Screenshots: http://github.com/kennytilton/qooxlisp/downloads
>>
>> Intro: http://wiki.github.com/kennytilton/qooxlisp/
>>
>> Congrats to the qooxdoo team for a great product.
>>
>> kt
>>
>> --
>> http://www.stuckonalgebra.com
>> "The best Algebra tutorial program I have seen... in a class by itself."
>> Macworld
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> qooxdoo-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.437 / Virus Database: 271.1.1/2895 - Release Date: 05/25/10 06:26:00
>

--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Dave Baggett
Another approach you could take is to generate JavaScript code from Lisp code. Google Web Toolkit does this using Java as the source language.

It would be a bit of work, but you'd never really have to look at JavaScript code again. :)

Dave
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Kenneth Tilton
In reply to this post by Thomas Herchenroeder


thron7 wrote:
> Nice work, Kenny.

Thx!

> Maybe you want to add yourself to the development
> platforms wiki page.

Is there a procedure for that, or do I just need to create an account
and then edit the page?

kt


------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Kenneth Tilton
In reply to this post by Dave Baggett


Dave Baggett wrote:
> Another approach you could take is to generate JavaScript code from Lisp
> code. Google Web Toolkit does this using Java as the source language.
>
> It would be a bit of work, but you'd never really have to look at JavaScript
> code again. :)

There actually exists a package called ParenScript that translates Lisp
to JS, I just had bad luck with it when I tried it. But it is definitely
a candidate for future use. What I would really like would be a
syntax-aware editor that would let me edit JS in strings in Lisp
functions (but I am not holding my breath <g>). Truth be told, so far I
do not need to write very much JS to do qooxlisp, so it's no big deal
(and not worth the trouble of Parenscript).

cheers, ken



--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Dave Baggett
You could hack this to do that:

  http://code.google.com/p/js2-mode/

It's in lisp, after all. :)

Dave
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Thomas Herchenroeder
In reply to this post by Kenneth Tilton
> Is there a procedure for that, or do I just need to create an account
> and then edit the page?

Yes, that's it.

T.

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Thomas Herchenroeder
In reply to this post by Kenneth Tilton
Kenny,

Thinking about it, I would be interested to know how you handle
dependencies between qooxdoo classes in qooxlisp.

Do you generate the initial GUI from the Lisp code using the Generator,
or do deploy your own dependency tracking and class packaging?

Then, with the user interacting with the GUI, you said something like
you would be sending JS strings from the server and eval them on the
client. Do those strings introduce new dependencies, e.g. use so far
unused qooxdoo classes, or do they just manipulate what's already there?
If they introduce new dependencies, would those JS strings themselves
contain the additonal class code? Or do they expect that all necessary
qooxdoo classes be already at the client?

Thanks,
T.

On 05/24/2010 09:53 PM, Kenneth Tilton wrote:
> Screenshots: http://github.com/kennytilton/qooxlisp/downloads
>
> Intro: http://wiki.github.com/kennytilton/qooxlisp/
>
> Congrats to the qooxdoo team for a great product.
>
> kt
>

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Kenneth Tilton
On Thu, May 27, 2010 at 12:22 PM, thron7 <[hidden email]> wrote:
> Kenny,
>
> Thinking about it, I would be interested to know how you handle
> dependencies between qooxdoo classes in qooxlisp.
>
> Do you generate the initial GUI from the Lisp code using the Generator,
> or do deploy your own dependency tracking and class packaging?


>
> Then, with the user interacting with the GUI, you said something like
> you would be sending JS strings from the server and eval them on the
> client. Do those strings introduce new dependencies, e.g. use so far
> unused qooxdoo classes, or do they just manipulate what's already there?
> If they introduce new dependencies, would those JS strings themselves
> contain the additonal class code? Or do they expect that all necessary
> qooxdoo classes be already at the client?
>
Pretty simple: the app developer has to throw a mention of any
"built-in" qooxdoo class they want to use into Application.js. By the
same token, any new class they want to use should be authored the
usual way, by adding a .js file and doing the generate step.

That might sound like it would lead to a lot of JS authoring, but one
of the surprising benefits of Cells is that, because any given
instance of a class can have its own rule to produce a slot value,
there is much less need to subclass. In effect, we get a lot more
re-use out of OO, which was the Grail back in the day.

Also, because the Lisp programmer is working with CLOS (Lisp OO)
instances on the server-side they can do as much sub-classing as they
like there.

So qooxdoo truly is just the view layer, including handling GUI events
of course, but not the application layer, including not even the
widget linkage. Here's an example from the demo app: I wanted to
disable the Search button if the text input for the search string was
blank. So I had various editing events piped back to the server, which
returned JS code to enable/disable the search button as needed. That
may seem like a long way to go to do what could easily be done on the
client, but as long as performance keeps up I like just sitting in my
application (in whatever language it might be) and forgetting the
client is on the other side of http. If performance is a problem, I
will look at using the qooxdoo databinding mechanism to achieve the
same end, but strive to do so by programming qooxdoo from the
server/Lisp application. ie, I will try not to have to subclass or end
up with application-specific code in the static JS.

I have done this sort of thing with Tcl/Tk, by the way, which someone
ported to GTk. It has gone well in the past, tho now I am going across
HTTP instead of a C interface so I'll have my eye open for performance
issues, but I suspect they will all roll over for me with sufficient
clever hacking. The big win is just sitting in a big language with
ready access to server data and almost forgetting HTTP and even
qooxdoo exists.

About that last: no, we are still programming qooxdoo, and qooxdoo
documentation will be qooxlisp documentation, but the design goal is
to minimize what the application developer must specify by having
qooxlisp intelligently fill in the needed boilerplate to make things
work.

kt

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Werner Thie
Hi

> Pretty simple: the app developer has to throw a mention of any
> "built-in" qooxdoo class they want to use into Application.js. By the
> same token, any new class they want to use should be authored the
> usual way, by adding a .js file and doing the generate step.
That's exactly how I do it with the qooxdoo/nevow integration, although
I do quite some JS programming for the GUI but I rely on the
divmod/nevow JS enhancements, using qooxdoo objects only for the
visualization of whatever happens in the live widgets. The
nqx.thieprojects.ch site is up again, showing as an example a 'live'
calculator with all the calculator logic sitting on the server. Silly to
think that somebody would do that, but just to prove the point...

Werner

> That might sound like it would lead to a lot of JS authoring, but one
snip...

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Thomas Herchenroeder
In reply to this post by Kenneth Tilton
> Pretty simple: the app developer has to throw a mention of any
> "built-in" qooxdoo class they want to use into Application.js. By the
same token, any new class they want to use should be authored the usual
way, by adding a .js file and doing the generate step.

Ok, so if I got that right, as far as the GUI is concerned you create a
usual (however thin) qooxdoo application upfront that will contain all JS
classes that will possibly be used during run time. This application is
send down to the client on first request. On subsequent requests, the
server sends JS code strings that manipulate existing objects or
instantiate new objects from the already loaded classes. - Did I get that
right?!

> That might sound like it would lead to a lot of JS authoring, but one of
the surprising benefits of Cells is that, because any given
> instance of a class can have its own rule to produce a slot value, there
is much less need to subclass. In effect, we get a lot more re-use out
of OO, which was the Grail back in the day.

Sorry, but I'm unfamiliar with Cells. I read your announcement back then,
but never got around to actually grok it. But nevermind...

> I have done this sort of thing with Tcl/Tk, by the way, which someone
ported to GTk. It has gone well in the past, tho now I am going across
HTTP instead of a C interface so I'll have my eye open for performance
issues, but I suspect they will all roll over for me with sufficient
clever hacking. The big win is just sitting in a big language with ready
access to server data and almost forgetting HTTP and even
> qooxdoo exists.

I don't want to bother you with "inferior" Lisps, but that reminds of Lutz
Mueller's "newlisp" (newlisp.org) who is driving Java GUI's from Lisp (I
believe he uses sockets).

> About that last: no, we are still programming qooxdoo, and qooxdoo
documentation will be qooxlisp documentation, but the design goal is to
minimize what the application developer must specify by having qooxlisp
intelligently fill in the needed boilerplate to make things work.

So are you generating qooxdoo code/templates from the application's Lisp
code?

T.






------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Thomas Herchenroeder
In reply to this post by Kenneth Tilton
> nqx.thieprojects.ch site is up again, showing as an example a 'live'
calculator with all the calculator logic sitting on the server.

Very nice, Werner! If there is a chance that this demo stays online for
the foreseeable future, consider making an entry for it in the "real life
examples" wiki page.

T.




------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Kenneth Tilton
In reply to this post by Thomas Herchenroeder
On Thu, May 27, 2010 at 3:24 PM, thron7 <[hidden email]> wrote:

>> Pretty simple: the app developer has to throw a mention of any
>> "built-in" qooxdoo class they want to use into Application.js. By the
> same token, any new class they want to use should be authored the usual
> way, by adding a .js file and doing the generate step.
>
> Ok, so if I got that right, as far as the GUI is concerned you create a
> usual (however thin) qooxdoo application upfront that will contain all JS
> classes that will possibly be used during run time. This application is
> send down to the client on first request. On subsequent requests, the
> server sends JS code strings that manipulate existing objects or
> instantiate new objects from the already loaded classes. - Did I get that
> right?!

Yes.

>
>> That might sound like it would lead to a lot of JS authoring, but one of
> the surprising benefits of Cells is that, because any given
>> instance of a class can have its own rule to produce a slot value, there
> is much less need to subclass. In effect, we get a lot more re-use out
> of OO, which was the Grail back in the day.
>
> Sorry, but I'm unfamiliar with Cells. I read your announcement back then,
> but never got around to actually grok it. But nevermind...

It works a lot like databinding, I think.

>
>> I have done this sort of thing with Tcl/Tk, by the way, which someone
> ported to GTk. It has gone well in the past, tho now I am going across
> HTTP instead of a C interface so I'll have my eye open for performance
> issues, but I suspect they will all roll over for me with sufficient
> clever hacking. The big win is just sitting in a big language with ready
> access to server data and almost forgetting HTTP and even
>> qooxdoo exists.
>
> I don't want to bother you with "inferior" Lisps, but that reminds of Lutz
> Mueller's "newlisp" (newlisp.org) who is driving Java GUI's from Lisp (I
> believe he uses sockets).

There is another Lisp+Tcl/Tk package that drives Tcl/Tk over sockets.

>
>> About that last: no, we are still programming qooxdoo, and qooxdoo
> documentation will be qooxlisp documentation, but the design goal is to
> minimize what the application developer must specify by having qooxlisp
> intelligently fill in the needed boilerplate to make things work.
>
> So are you generating qooxdoo code/templates from the application's Lisp
> code?

I am not familiar with qooxdoo templates, and did not spot anything in
the doc after a quick scan. Is there a link you can provide?

kt

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Thomas Herchenroeder
>>> About that last: no, we are still programming qooxdoo, and qooxdoo
>> documentation will be qooxlisp documentation, but the design goal is to
>> minimize what the application developer must specify by having qooxlisp
>> intelligently fill in the needed boilerplate to make things work.
>>
>> So are you generating qooxdoo code/templates from the application's Lisp
>> code?
>
> I am not familiar with qooxdoo templates, and did not spot anything in
> the doc after a quick scan. Is there a link you can provide?

No, no, you get me wrong. qooxdoo does not have templates. I was thinking
whether the phrase "minimize what the application developer must specify
by having qooxlisp intelligently fill in the needed boilerplate to make
things work" means you are generating qooxdoo code of some level of
completeness from Lisp code.

T.




------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
flj
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

flj
In reply to this post by Kenneth Tilton
Hi.

> So qooxdoo truly is just the view layer, including handling GUI events
> of course, but not the application layer, including not even the
> widget linkage. Here's an example from the demo app: I wanted to
> disable the Search button if the text input for the search string was
> blank. So I had various editing events piped back to the server, which
> returned JS code to enable/disable the search button as needed. That
> may seem like a long way to go to do what could easily be done on the
> client, but as long as performance keeps up I like just sitting in my
> application (in whatever language it might be) and forgetting the
> client is on the other side of http. If performance is a problem, I
> will look at using the qooxdoo databinding mechanism to achieve the
> same end, but strive to do so by programming qooxdoo from the
> server/Lisp application. ie, I will try not to have to subclass or end
> up with application-specific code in the static JS.
>  
> I have done this sort of thing with Tcl/Tk, by the way, which someone
> ported to GTk. It has gone well in the past, tho now I am going across
> HTTP instead of a C interface so I'll have my eye open for performance
> issues, but I suspect they will all roll over for me with sufficient
> clever hacking. The big win is just sitting in a big language with
> ready access to server data and almost forgetting HTTP and even
> qooxdoo exists.
>  
> About that last: no, we are still programming qooxdoo, and qooxdoo
> documentation will be qooxlisp documentation, but the design goal is
> to minimize what the application developer must specify by having
> qooxlisp intelligently fill in the needed boilerplate to make things
> work.

Idunno. I like Javascript. It may  not be the richest language in the world, but it is built in such a way that you can easily do anything to it in javascript code, except enriching its syntax. Besides, you only have to drive the UI from it.

I suppose qooxlisp has to replicate the entire UI state on the server to be able to properly react to events in the UI. Right? Alternatively you can go the ASP.Net way and pass the state along with each request and response. But somehow state has to be available on the server in order the server to be able to react properly  to UI requests/events.

Therefore, I can't really see the benefit of it. Indeed, you do keep application-specific logic, including UI-related logic, in your preferred language, but IMO there are two significant disadvantages to it, both related to the fat state information corresponding to rich UIs. First, in the case  of large number of users, resource consumption grows much faster than in case of an architecture which requires no state or only slim session state on the server, which also doesn't change very often. Second, in case of fat and dynamic session state which is maintained on the server, clustering becomes complicated (due to complicated replication of the state info across cluster members). Alternatively, if instead of maintaining the fat state on the server it is sent along with each request and response (the ASP.Net way), computational effort to serialize/deserialize it becomes significant, especially for a chatty web app, where ever ything is handled on the server.

All of these are most likely no issues in case of small numbers of users on an intranet. But each of them easily becomes a bad pain if your application is used concurrently by just a few tens of thousands of users,  and it's even worse if your app is accessed over the internet, in which case you have no control over delays, lags, routing speed etc.

A different approach, which IMO allows for faster, less resource hungry applications, is to have the entire UI logic in Javascript code, and define a set of JSON-based requests and responses upon which the UI application has to rely. There are several advantages to such an architecture.

First, you only have to keep very slim session  info on the server. Small session info which almost never changes during a session (a user name, an authentication token, only things like this) allows for much higher scalability.

Second, a natural separation of concerns arises between layers. It's very well defined what the server has to do, in fact, each request/response can be handled in isolation. Similarly, the various UI parts can each be handled in isolation, as they each rely on specific data being retrieved/sent, less on data provided by other UI components. This allows for many programmers working in parallel on the various parts, without needing too much synchronization among them.

Third, the well-defined set of JSON requests/responses constitute a natural interface for third-party apps which need to interact with your app - one which doesn't expose app internals, and thus protects your app from having its data damaged by external code - such as would be the risk when doing integration at the database level.

Fourth, the nice isolation between layers and between components inside a layer allows for improved testability. You can unit test each component in context, without wrapping it in tons of mocks.

Essentially, my point is that now th at we have qooxdoo, to use it with state and UI logic managed server-side would be to some extent a pervertion of its purpose. For years before qooxdoo apps were written this way, and web app development was a pain  in the ass. I for one don't want to go back to that type of apps, even if this would allow me to code everything in my language of choice.

br,

flj



------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Thomas Herchenroeder
Nice write-up, flj.

Kyle Simpson started a promising series of articles about UI
architecture in JSMag, entitled 'The Rise of the "Middle-End"', where he
advocates deployment of JS on the server for some of Kenny's arguments.

T.

On 05/28/2010 05:53 AM, [hidden email] wrote:

> Hi.
>
>> So qooxdoo truly is just the view layer, including handling GUI events
>> of course, but not the application layer, including not even the
>> widget linkage. Here's an example from the demo app: I wanted to
>> disable the Search button if the text input for the search string was
>> blank. So I had various editing events piped back to the server, which
>> returned JS code to enable/disable the search button as needed. That
>> may seem like a long way to go to do what could easily be done on the
>> client, but as long as performance keeps up I like just sitting in my
>> application (in whatever language it might be) and forgetting the
>> client is on the other side of http. If performance is a problem, I
>> will look at using the qooxdoo databinding mechanism to achieve the
>> same end, but strive to do so by programming qooxdoo from the
>> server/Lisp application. ie, I will try not to have to subclass or end
>> up with application-specific code in the static JS.
>>  
>> I have done this sort of thing with Tcl/Tk, by the way, which someone
>> ported to GTk. It has gone well in the past, tho now I am going across
>> HTTP instead of a C interface so I'll have my eye open for performance
>> issues, but I suspect they will all roll over for me with sufficient
>> clever hacking. The big win is just sitting in a big language with
>> ready access to server data and almost forgetting HTTP and even
>> qooxdoo exists.
>>  
>> About that last: no, we are still programming qooxdoo, and qooxdoo
>> documentation will be qooxlisp documentation, but the design goal is
>> to minimize what the application developer must specify by having
>> qooxlisp intelligently fill in the needed boilerplate to make things
>> work.
>
> Idunno. I like Javascript. It may  not be the richest language in the world, but it is built in such a way that you can easily do anything to it in javascript code, except enriching its syntax. Besides, you only have to drive the UI from it.
>
> I suppose qooxlisp has to replicate the entire UI state on the server to be able to properly react to events in the UI. Right? Alternatively you can go the ASP.Net way and pass the state along with each request and response. But somehow state has to be available on the server in order the server to be able to react properly  to UI requests/events.
>
> Therefore, I can't really see the benefit of it. Indeed, you do keep application-specific logic, including UI-related logic, in your preferred language, but IMO there are two significant disadvantages to it, both related to the fat state information corresponding to rich UIs. First, in the case  of large number of users, resource consumption grows much faster than in case of an architecture which requires no state or only slim session state on the server, which also doesn't change very often. Second, in case of fat and dynamic session state which is maintained on the server, clustering becomes complicated (due to complicated replication of the state info across cluster members). Alternatively, if instead of maintaining the fat state on the server it is sent along with each request and response (the ASP.Net way), computational effort to serialize/deserialize it becomes significant, especially for a chatty web app, where ever ything is handled on the server.
>
> All of these are most likely no issues in case of small numbers of users on an intranet. But each of them easily becomes a bad pain if your application is used concurrently by just a few tens of thousands of users,  and it's even worse if your app is accessed over the internet, in which case you have no control over delays, lags, routing speed etc.
>
> A different approach, which IMO allows for faster, less resource hungry applications, is to have the entire UI logic in Javascript code, and define a set of JSON-based requests and responses upon which the UI application has to rely. There are several advantages to such an architecture.
>
> First, you only have to keep very slim session  info on the server. Small session info which almost never changes during a session (a user name, an authentication token, only things like this) allows for much higher scalability.
>
> Second, a natural separation of concerns arises between layers. It's very well defined what the server has to do, in fact, each request/response can be handled in isolation. Similarly, the various UI parts can each be handled in isolation, as they each rely on specific data being retrieved/sent, less on data provided by other UI components. This allows for many programmers working in parallel on the various parts, without needing too much synchronization among them.
>
> Third, the well-defined set of JSON requests/responses constitute a natural interface for third-party apps which need to interact with your app - one which doesn't expose app internals, and thus protects your app from having its data damaged by external code - such as would be the risk when doing integration at the database level.
>
> Fourth, the nice isolation between layers and between components inside a layer allows for improved testability. You can unit test each component in context, without wrapping it in tons of mocks.
>
> Essentially, my point is that now th at we have qooxdoo, to use it with state and UI logic managed server-side would be to some extent a pervertion of its purpose. For years before qooxdoo apps were written this way, and web app development was a pain  in the ass. I for one don't want to go back to that type of apps, even if this would allow me to code everything in my language of choice.
>
> br,
>
> flj
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Kenneth Tilton
In reply to this post by flj


[hidden email] wrote:

> Hi.
>
>> So qooxdoo truly is just the view layer, including handling GUI events
>> of course, but not the application layer, including not even the
>> widget linkage. Here's an example from the demo app: I wanted to
>> disable the Search button if the text input for the search string was
>> blank. So I had various editing events piped back to the server, which
>> returned JS code to enable/disable the search button as needed. That
>> may seem like a long way to go to do what could easily be done on the
>> client, but as long as performance keeps up I like just sitting in my
>> application (in whatever language it might be) and forgetting the
>> client is on the other side of http. If performance is a problem, I
>> will look at using the qooxdoo databinding mechanism to achieve the
>> same end, but strive to do so by programming qooxdoo from the
>> server/Lisp application. ie, I will try not to have to subclass or end
>> up with application-specific code in the static JS.
>>  
>> I have done this sort of thing with Tcl/Tk, by the way, which someone
>> ported to GTk. It has gone well in the past, tho now I am going across
>> HTTP instead of a C interface so I'll have my eye open for performance
>> issues, but I suspect they will all roll over for me with sufficient
>> clever hacking. The big win is just sitting in a big language with
>> ready access to server data and almost forgetting HTTP and even
>> qooxdoo exists.
>>  
>> About that last: no, we are still programming qooxdoo, and qooxdoo
>> documentation will be qooxlisp documentation, but the design goal is
>> to minimize what the application developer must specify by having
>> qooxlisp intelligently fill in the needed boilerplate to make things
>> work.
>

> Idunno. I like Javascript. It may not be the richest language in the
> world, but it is built in such a way that you can easily do anything to
> it in javascript code, except enriching its syntax. Besides, you only
> have to drive the UI from it.

"only have to drive the GUI"? There may be our mileage variation in a
nutshell, and the mileage depends on the application, not us. "only the
GUI" presumes the UI is a simple thing, ignoring what I have said: my
application requires a much more lively GUI than most people imagine
when they start defining "the one right way" to handle model vs. view.

I'll have to end with a teaser until I have time later to respond more
fully by actually describing the application, but another thing I said
already was that I think the common wisdom about "natural decomposition
of layers" does not hold up if one is doing interesting enough things
with a GUI application: they in fact are tightly intertwined, even tho
in the end we do have view instances for model instances. Then the right
mental model is not two layers, one with views that can see each other
and one with model instances that can see each other, rather view
instances that can each see their model instance. model-view, yes.
layers, no. Later I will expand on this.

Final note: "now that we have qooxdoo"? Oh, my. No, it is "now that
qooxdoo let's us create beautiful, rich web applications". And once one
is truly doing that and not just putting up Web 1.0 static pages, as I
said, the isolation of model from view underpinning most of the
arguments below starts to break down.

OK, one more "final" note: not so fast with "except enriching its
syntax". Apologies again for being a tease, but I am motivated to expand
the qooxlisp wiki page to offer examples of how qooxlisp (via the power
of Common Lisp) manages to hide boilerplate without sacrificing needed
access to all of qooxdoo's capabilities.

If anyone can show me the same thing done with javascript, qooxdoo will
soon get a nice contrib. :) And indeed Common Lisp programmers forced to
use other languages are often able to come up with powerful approaches
that any expert in those languages could have created had they had the
motivation that comes from always having such things at hand and
suddenly being asked to do without.

I'll add as much as seems appropriate to the qooxlisp page and let y'all
know here when I do.

cheers, ken


>
> I suppose qooxlisp has to replicate the entire UI state on the server to be able to properly react to events in the UI. Right? Alternatively you can go the ASP.Net way and pass the state along with each request and response. But somehow state has to be available on the server in order the server to be able to react properly  to UI requests/events.
>
> Therefore, I can't really see the benefit of it. Indeed, you do keep application-specific logic, including UI-related logic, in your preferred language, but IMO there are two significant disadvantages to it, both related to the fat state information corresponding to rich UIs. First, in the case  of large number of users, resource consumption grows much faster than in case of an architecture which requires no state or only slim session state on the server, which also doesn't change very often. Second, in case of fat and dynamic session state which is maintained on the server, clustering becomes complicated (due to complicated replication of the state info across cluster members). Alternatively, if instead of maintaining the fat state on the server it is sent along with each request and response (the ASP.Net way), computational effort to serialize/deserialize it becomes significant, especially for a chatty web app, where ever ything is handled on the server.
>
> All of these are most likely no issues in case of small numbers of users on an intranet. But each of them easily becomes a bad pain if your application is used concurrently by just a few tens of thousands of users,  and it's even worse if your app is accessed over the internet, in which case you have no control over delays, lags, routing speed etc.
>
> A different approach, which IMO allows for faster, less resource hungry applications, is to have the entire UI logic in Javascript code, and define a set of JSON-based requests and responses upon which the UI application has to rely. There are several advantages to such an architecture.
>
> First, you only have to keep very slim session  info on the server. Small session info which almost never changes during a session (a user name, an authentication token, only things like this) allows for much higher scalability.
>
> Second, a natural separation of concerns arises between layers. It's very well defined what the server has to do, in fact, each request/response can be handled in isolation. Similarly, the various UI parts can each be handled in isolation, as they each rely on specific data being retrieved/sent, less on data provided by other UI components. This allows for many programmers working in parallel on the various parts, without needing too much synchronization among them.
>
> Third, the well-defined set of JSON requests/responses constitute a natural interface for third-party apps which need to interact with your app - one which doesn't expose app internals, and thus protects your app from having its data damaged by external code - such as would be the risk when doing integration at the database level.
>
> Fourth, the nice isolation between layers and between components inside a layer allows for improved testability. You can unit test each component in context, without wrapping it in tons of mocks.
>
> Essentially, my point is that now th at we have qooxdoo, to use it with state and UI logic managed server-side would be to some extent a pervertion of its purpose. For years before qooxdoo apps were written this way, and web app development was a pain  in the ass. I for one don't want to go back to that type of apps, even if this would allow me to code everything in my language of choice.
>
> br,
>
> flj
>

--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Werner Thie
Kenneth Tilton wrote:

>
> [hidden email] wrote:
>> Hi.
>>
>>> So qooxdoo truly is just the view layer, including handling GUI events
>>> of course, but not the application layer, including not even the
>>> widget linkage. Here's an example from the demo app: I wanted to
>>> disable the Search button if the text input for the search string was
>>> blank. So I had various editing events piped back to the server, which
>>> returned JS code to enable/disable the search button as needed. That
>>> may seem like a long way to go to do what could easily be done on the
>>> client, but as long as performance keeps up I like just sitting in my
>>> application (in whatever language it might be) and forgetting the
>>> client is on the other side of http. If performance is a problem, I
>>> will look at using the qooxdoo databinding mechanism to achieve the
>>> same end, but strive to do so by programming qooxdoo from the
>>> server/Lisp application. ie, I will try not to have to subclass or end
>>> up with application-specific code in the static JS.
>>>  
>>> I have done this sort of thing with Tcl/Tk, by the way, which someone
>>> ported to GTk. It has gone well in the past, tho now I am going across
>>> HTTP instead of a C interface so I'll have my eye open for performance
>>> issues, but I suspect they will all roll over for me with sufficient
>>> clever hacking. The big win is just sitting in a big language with
>>> ready access to server data and almost forgetting HTTP and even
>>> qooxdoo exists.
>>>  
>>> About that last: no, we are still programming qooxdoo, and qooxdoo
>>> documentation will be qooxlisp documentation, but the design goal is
>>> to minimize what the application developer must specify by having
>>> qooxlisp intelligently fill in the needed boilerplate to make things
>>> work.
>
>> Idunno. I like Javascript. It may not be the richest language in the
>> world, but it is built in such a way that you can easily do anything to
>> it in javascript code, except enriching its syntax. Besides, you only
>> have to drive the UI from it.
>
> "only have to drive the GUI"? There may be our mileage variation in a
> nutshell, and the mileage depends on the application, not us. "only the
> GUI" presumes the UI is a simple thing, ignoring what I have said: my
> application requires a much more lively GUI than most people imagine
> when they start defining "the one right way" to handle model vs. view.
>
> I'll have to end with a teaser until I have time later to respond more
> fully by actually describing the application, but another thing I said
> already was that I think the common wisdom about "natural decomposition
> of layers" does not hold up if one is doing interesting enough things
> with a GUI application: they in fact are tightly intertwined, even tho
> in the end we do have view instances for model instances. Then the right
> mental model is not two layers, one with views that can see each other
> and one with model instances that can see each other, rather view
> instances that can each see their model instance. model-view, yes.
> layers, no. Later I will expand on this.
>
> Final note: "now that we have qooxdoo"? Oh, my. No, it is "now that
> qooxdoo let's us create beautiful, rich web applications". And once one
> is truly doing that and not just putting up Web 1.0 static pages, as I
> said, the isolation of model from view underpinning most of the
> arguments below starts to break down.
>
> OK, one more "final" note: not so fast with "except enriching its
> syntax". Apologies again for being a tease, but I am motivated to expand
> the qooxlisp wiki page to offer examples of how qooxlisp (via the power
> of Common Lisp) manages to hide boilerplate without sacrificing needed
> access to all of qooxdoo's capabilities.
>
> If anyone can show me the same thing done with javascript, qooxdoo will
> soon get a nice contrib. :) And indeed Common Lisp programmers forced to
> use other languages are often able to come up with powerful approaches
> that any expert in those languages could have created had they had the
> motivation that comes from always having such things at hand and
> suddenly being asked to do without.
>
> I'll add as much as seems appropriate to the qooxlisp page and let y'all
> know here when I do.
>
> cheers, ken
>
>
>> I suppose qooxlisp has to replicate the entire UI state on the server to be able to properly react to events in the UI. Right? Alternatively you can go the ASP.Net way and pass the state along with each request and response. But somehow state has to be available on the server in order the server to be able to react properly  to UI requests/events.
>>
>> Therefore, I can't really see the benefit of it. Indeed, you do keep application-specific logic, including UI-related logic, in your preferred language, but IMO there are two significant disadvantages to it, both related to the fat state information corresponding to rich UIs. First, in the case  of large number of users, resource consumption grows much faster than in case of an architecture which requires no state or only slim session state on the server, which also doesn't change very often. Second, in case of fat and dynamic session state which is maintained on the server, clustering becomes complicated (due to complicated replication of the state info across cluster members). Alternatively, if instead of maintaining the fat state on the server it is sent along with each request and response (the ASP.Net way), computational effort to serialize/deserialize it becomes significant, especially for a chatty web app, where ever ything is handled on the server.
>>
>> All of these are most likely no issues in case of small numbers of users on an intranet. But each of them easily becomes a bad pain if your application is used concurrently by just a few tens of thousands of users,  and it's even worse if your app is accessed over the internet, in which case you have no control over delays, lags, routing speed etc.
>>
>> A different approach, which IMO allows for faster, less resource hungry applications, is to have the entire UI logic in Javascript code, and define a set of JSON-based requests and responses upon which the UI application has to rely. There are several advantages to such an architecture.
>>
>> First, you only have to keep very slim session  info on the server. Small session info which almost never changes during a session (a user name, an authentication token, only things like this) allows for much higher scalability.
>>
>> Second, a natural separation of concerns arises between layers. It's very well defined what the server has to do, in fact, each request/response can be handled in isolation. Similarly, the various UI parts can each be handled in isolation, as they each rely on specific data being retrieved/sent, less on data provided by other UI components. This allows for many programmers working in parallel on the various parts, without needing too much synchronization among them.
>>
>> Third, the well-defined set of JSON requests/responses constitute a natural interface for third-party apps which need to interact with your app - one which doesn't expose app internals, and thus protects your app from having its data damaged by external code - such as would be the risk when doing integration at the database level.
>>
>> Fourth, the nice isolation between layers and between components inside a layer allows for improved testability. You can unit test each component in context, without wrapping it in tons of mocks.
>>
>> Essentially, my point is that now th at we have qooxdoo, to use it with state and UI logic managed server-side would be to some extent a pervertion of its purpose. For years before qooxdoo apps were written this way, and web app development was a pain  in the ass. I for one don't want to go back to that type of apps, even if this would allow me to code everything in my language of choice.
>>
>> br,
>>
>> flj
>>
>
Hi all

Hmmm, didn't we talk about burning at the stake as a heretic?

So, while the flames are flickering, let's pour some oil into the fire:

Being in this field for more than 35 years I've made the following
observation:

Human - computer interaction theory and implementation was a well
founded and grounded system with a lot of common sense in it. Remember
the 'Human Interface Guidelines' from Apple back in 1984 and later a
similar piece of work from MS. I still own about ten books (sure not
everything) which address this field. Around 1994 the Internet and it's
tools dawned on the greater public. Among the tools was one of the first
usable browser implementation, Netscape 1.0. This point in time I would
mark in the calendar as the single biggest step backward in
human-computer interaction in human history. It was forced down our
throats by a huge inflow of people who never ever thought, cared or had
the will to think about what they were throwing at the user.

Now, 16 years later we have qooxdoo, and here is the second part of my
statement: thank you qooxdoo guys for a great piece of work, which about
corrects that incredible backlash we suffered.

Being back where we have been 1994, let's pick up the books and let the
discussion begin, what's a good GUI and whatnot, what must be
implemented on the server and what goes into the client.

According to system theory there is no such thing as a final system
superceeding all other systems, therefore qooxdoo can be driven by a
metasystem and used as an intermediate language, which makes as much
sense as every other way to do it.

To make a more practical point:
Just think about the lack of a killer qooxdoo grafics tool which would
let you click together a GUI grafically. Such editors abound for other
systems, take one of these and it's output, transform it into JScript
driving the qooxdoo  library. It's doesn't matter if you transform it
statically or do it on the fly while delivering the code to the browser,
this is a separate issue. While editing the GUI you could also throw in
data binding and if you add a decent RPC implementation with a clean
asynchronous design on the runtime side, like what we have with
nevow/athena then we are making headway into the future: Real
'Applications' with an event loop which is open to the server, a dream
we hedged around 1992 where things like Newtons and languages like Dylan
were popular.

My 2cts, Werner

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
12