HTML Generator

[Greig Morrison]

I would like to see the PowerHouse Web client support an Ajax framework,
this uses the same zero footprint architecture and provides a dynamic
web page on the client side. Anything useful on the web has move beyond
simply html and now include some form of script (JavaScript or
ActionScript).
 
http://en.wikipedia.org/wiki/Ajax_framework
 
There are plenty of examples, many are Open Source like:
 
ZK Simply Ajax http://www.zkoss.org/
Thinwire http://www.thinwire.com/
Google Web Toolkit http://code.google.com/p/google-web-toolkit/
 
Regards
Greig Morrison
 
-----Original Message-----
 
----------------------------------------------------------------------
 
Message: 1
 
Date: Wed, 6 Jun 2007 09:19:20 -0400
From: "Deskin, Bob" <Bob.Deskin at Cognos.COM>
Subject: HTML Generator
To: <powerh-l at lists.sowder.com>
 
Message-ID:
<2B4E386EAEC90947802323BF373DC0EC0B971B87 at sottemail1.ent.ad.cognos.com>
 

Content-Type: text/plain; charset="us-ascii"
 
Now that we have put the E version to bed (it's in manufacturing but not
quite available yet), we're busy planning the next release. We have lost
of ideas of course, and I'm not specifically soliciting any more. What I
would like to do is follow up on Ken's idea, which we share, of an HTML
generator. We already know that QDESIGN can generate HTML. And it's not
particularly difficult to add to that. I'm not trying to make it sound
like it's a 5 minute job, but we already know how to do it. It's simply
a case of designing the keyword and determining what HTML should be
generated and where.
 
But I don't think people want PowerHouse Web with it's panel-oriented
stateless architecture that requires converting subscreen calls to
linkscreens and some other way of handling reports and runs. My take is
that people want is something that feels like QUICK (even down to the
Action field is desired) but looks like a web page. And that it runs
over a local network similar to a terminal emulator as opposed to the
internet (although that might be a possibility). So the first question
is - is that a correct assumption?
 
If that is correct, then the next question is how do we do the execution
end of things in a reasonable period of time with limited resources.
Sure, it can be done. The browser engines are available as controls or
applets and we could build the entire infrastructure, but we don't have
a large team and 2 or more years. Rather we have 2 or 3 people and 6
months (no, that's not the whole team but we do have other things to do,
and the 6 months is what I'm aiming for because I know these projects
take longer).
 
So does anyone have any ideas on how to put this sort of thing together?
 
Are there web sites that describe it? Is it even reasonable considering
that a browser is typically block oriented whereas QUICK is field
oriented?
 
Any thoughts? 
 

Bob
 
PS I removed the other portions of Ken's message because I won't get
into pricing policy in a public forum. Ken's 3rd point is somewhat
dependant on the success of the second. These days, you need to look
good to be noticed. However, whatever we do must be in keeping with our
existing architecture. QKView is a step in the right direction.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sowder.com/pipermail/powerh-l/attachments/20070606/8a23d98c/attachment.html