Death wrote:And with the browser integration and URL commands, one can already script in JS etc, or export custom flash code to run in it etc. etc.
Note that I didn't really express a criticism against the idea of exporting to the browser (neither did you, I believe).
It's just that I don't really see the contribution of having to create a fully fledge framework that would be able to export about any content that you could have in a xtalk stack into a browser (which I understand to be a point you make as well).
If you read any book about business, one notion that is introduced early is the one of market vs product. A product is what is being bought... by a given market.
"A market consists of a group of current and/or potential customers having the willingness and ability to buy products – goods or services – to satisfy a particular class of wants or needs. Thus, markets consist of buyers – people or organizations and their needs – not products. [...] Markets consist of buyers not products ’’
(Source:
The Business Road Test).
The market of persons who want to write very complex applications on the web seems to be already well served.
That doesn't mean that I believe that it doesn't make any sense to provide export facilities. Look at the above. "Satisfy a particular class of wants or needs".
I believe that when it comes to consider export to the web it makes more sense to adopt a type of templating approach or automatic generation of interface based on predefined standards approach based organization by which you would allow the customer to edit some material in a stack, with the option to save data locally and let him present these data within a browser.
That's the reason why I linked to that
Exercist project of mine, which takes that approach. Export data edited within a revolution stack into some standard format (xml, json, etc.) and use these data to fill in some predefined templates. Sometimes, the templating system can be quite complex. I have for instance designed a fairly generic
learning activity generator that works both in xtalk and in javascript as they generate a visual interface starting from the same xml specification.
I believe in this kind of approach. It makes it possible to have at quite low cost (in terms of development time and complexity) applications with a desktop side and the web-side of things tightly integrated... for products that serve well-defined markets.
There was no attack at all in my invitation to write requirements first. This is a very serious recommendation. It is important to avoid to write too generic a framework and to rather write the specs for a product that might sell. As an example specs that can be written to meet the specific needs of a specific market, feel free to check out the
specs part or the
manual for the exercist project. (There are also
demos but I have been told they don't work well on some version of IE -- sometimes they don't work at all in a IE browser).
And the reason I reacted on the fact that Dan was inviting persons to contact him privately is that once you take this type of approach, competition between developers is importantly reduced. Once you set yourself to serve a niche, then you rapidly discover that there is a huge number of niches to serve out there. In fact, it would rather be beneficial to have the persons interested in this kind of approach to freely discuss and freely share the code that is common to these different approaches.
--------------------------------------------------------------------------------
If you really want to go for something "generic", then an interesting candidate is Zimbra or of more interest, Zimlets
"Zimlets are a mechanism for integrating the Zimbra Collaboration Suite (ZCS) with third party information systems and content as well as creating "mash-up" user interfaces within the Zimbra suite itself."
Not having spent too much time evaluating that technology it seems possible to consider an export mechanism within revolution to get things in zimlet format (again, as a specialized plugin, not a chore revolution module)
White Paper
gallery
The big advantage of zimlets (over xul or other Laszlo) is that rather than propose you some generic framework that can do about anything you could think of, it rather let you reuse components that do a specific task.
--------------------------------------------------------------------------------
Another approach that is worth checking out is
CakePHP
Cake is a rapid development framework for PHP which uses commonly known design patterns like ActiveRecord, Association Data Mapping, Front Controller and MVC. Our primary goal is to provide a structured framework that enables PHP users at all levels to rapidly develop robust web applications, without any loss to flexibility.
--------------------------------------------------------------------------------
And if are not convinced yet that the web market is well served with widget solutions better than we have the time to design within our small community:
Active Widgets,
behaviour,
dojo,
jquery,
jsan (somehow), magnolia,
miraculous,
mochikit,
pajaj,
prototype (with
protowidget based on it),
qcodo,
qooxdoo,
rialto application server,
rico,
sajax,
scriptaculous,
swato engine (java),
symfony (php),
tacos,
textile,
vitamin,
xajax,
xoad (php),
yui,
zapatec,
Zephyr.
Even more at
PHP Ajax Frameworks
--------------------------------------------------------------------------------
No, this list is *really* not to encourage xtalk developers to evaluate these different technologies. The reason I posted a rather short list of solutions available out there is to send the following message. Frameworks are exploding like mushrooms out there. Things are changing, very rapidly changing. Some frameworks disappear, other emerge. Hopefully, most of it will consolidate within 3-5 years. But going for designing a system within xtalk that is too much dependent on any single one of these framework is a bit dangerous right now.
In contrast, if you develop a product with a specific market in mind, where an UI is automatically generated on the basis of specifications that you are the one to fully control, then there are far better chances of making it in the longer terms. My 2 cents.
--------------------------------------------------------------------------------
And if you need to produce web applications with liitle knowledge of javascript, then why not try
ZK
ZK is an open-source, all Java, Ajax Web application framework that enables rich UI for Web applications with no JavaScript and little programming.
Now that ajax is gaining in popularity (if you checked out
sitepoint last report on the state of web development,
Ajax is expected to take over flash in 2007). Because of this, you can be sure that they are very many teams of highly competent engineers who already started designing RAD for javascript/ajax application *months* ago. Very good ones should be available within less than 1 year time. These applications will be better than what can be produced by a team of one or two persons in this community... even if these persons choose xtalk as development environment.
--------------------------------------------------------------------------------
My own view on where xtalk developers should be going: Don't try to design a general framework. Serve niches. Xtalk let you serve niche markets faster and better than any other tools out there.
--------------------------------------------------------------------------------
Then what is common to all the frameworks above. They try to isolate design patterns and propose implementations for design patterns.
That's the thing missing in our community.
A ‘pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice’ (Alexander, 1977). At a simple level patterns are a way of recording the knowledge of experienced practitioners, best practice and lessons learned. Patterns originated in the field of architecture but pattern use has since spread to include:
Concrete examples, in the context of interface design can be found on the
on-line companion to the book "Designing Interfaces". Another example, the very famous
Yahoo! User Interface Library. Another example, the recent book by O'Reilly
Ajax Design Patterns.
And this goes back to what Death said. Let's solidify xTalk first.
Let's provide well thought solutions for well identified types of problems.
Once we have done that within revolution, to provide an export mechanism to any existing mechanism would be a lot easier. We won't need any complex framework or change anything to the engine to do it.