On Mar 16, 2008, at 1:09 AM, Tristan Short wrote:

> Mario,
>
> I am at the 'get my head around it' stage with gz. Trying a few things
> out and prototyping a web app (as a hobbyist not a pro). If it were not
> for gz I would use native qp for sure, as I know it and like it lots.
> However, the gz build-upon to qp provides things that native qp does
> not, like linking spec to Mochikit to deliver client side form
> validation, and Directory security, etc.  gz makes technical choices
> that I am happy with (like qp did with Durus) especially if it saves me
> a few days / weeks / months coding (I am a novice with little to no
> time
> to roll-my-own: my LOC rate is very low).

Always be wary of anyone with high-LOC output ;-)

I see the gz extensions of qp as falling under two categories, namely
as either conveniences for using qp  or as providing new
functionaility.

The first of these is essentially tied to qp, how it does things. The
eXportable idea, and how it is used also for declaring and managing
access control, falls into this category. So does all the additional
navigation functions provided by gz -- actually these are more fixes to
what qp already offers for navigation generation out of the box (that
already outshines all other web frameworks I am aware of).

The second, or new functionality, is conceptually not bound to qp,
although in practice that may be difficult to respect. The client-side
form features that you mention fall under this category. The essence of
gz, if there is such a thing, is the dhi object (dhtml info) and an api
for gizmo (widget) objects to interact with the request's dhi.

> My interest in asking when gz is going to get evoque is purely to know
> if I should continue to use gz as it is for my web app or wait a little
> given that a new gz release may be around the corner. However, having
> read your email it sounds like wider changes may be afoot and further
> out than the next couple of weeks.  So for me it is more important you
> make the next gz release a proper full release to fit all your
> requirements rather than an interim release to satisfy any curiosity I
> might have. Given my lack of time, a polished gz is more important than
> (quickly) answering the question how evoque works with gz.

I am looking through the the shortlist of issues to revisit. The
changes are not so extensive, and a release will not take very long.
There is some added flexibility, but in most cases it is just
simplications, for example a much simpler skin mechanism now that
evoque will be the "assumed" templating.

The bigger question that I was probably referring to earlier, and one
that I do not I intend to answer any time soon, is how (for a given
application) should web programming be organized between
client/server... by this I mean the tendency to shift page user
interface complexity from the server to the client e.g. using rich
toolkits such as dojo. And as a consequence the server-side may become
little more than a data services layer, for servicing the ajax data
callbacks from the rich client.

The central idea of gz is to provide mechanisms to help with the
server-side generation of complex pages. But, if a web application is
going to be "data services oriented" on the server then it stands to
gain little from being made with gz over being made with qp. Looking at
an app in this way may help identify whether you gain enough by using
gz, or whether you should just use qp natively, maybe with evoque.

> The doc on using evoque with qp shows how simple (and brilliant) the qp
> design is, and, I guess, also how straight forward the evoque interface
> is. I am looking forward to downloading the next version of gz. I need
> those bells and whistles...

Yes, indeed. And you should always resist any loss of simplicity.... ;-)

mario