There's been a lot of buzz and other noise going on about how the next generation of Web-based applications will be implemented. The problem that is trying to be addressed is not a new one: HTML forms widgets are truly awful for anything beyond the simple "contact form" apps that informed their design and people want (or think their customers want) richer desktop-app-like interfaces. More than just browser-embedded applets, the trend seems to be toward client-side "runtime engines" that get both their UI definitions and data via XML over HTTP and "web services" interfaces. Examples include Mozilla's XUL, MSFT's XAML, and Macromedia's Flex.
IMO, this trend (if it pans out in reality) puts AxKit in a positive position for faster and wider adoption. AxKit lives on the notion of "one source, many views" and, since the interface definition languages that are emerging all seem to use XML as their syntax, for us, delivering such "phat client" apps are simply another optional runtime transformation. At the highest level, AxKit makes delivering phat client data-- while still offering the same application as HTML for maximum portability-- no more complex than delivering the same narrative article as either HTML or PDF; its just an alternate style that is applied to the common source based on the user's context/preferences.
I've played a bit with Mozilla's XUL (there's even a sample in the book that renders a simple data-entry app as both HTML and Moz XUL, at the user's choice) and it seems like a natural step to me. I'm wondering what folks here think, and if there's anything we (the AxKit developers. or the larger community) could do to foster experimentation in this space easier or to make implementing such apps more straightforward.
First off I don't think MSFT's XAML will work from AxKit - it's a compiled system, rather than anything that can be web delivered.
As far as the rest goes, I'd like to see more progress made in AxKit on forms handling. From the simple end we have a half decent tag library in the name of PerForm - having used PerForm now on a big project I know it works well, although I can see it getting a little hairy with large numbers of controls. The XSP subclassing feature (where an XSP page can be a subclass of a class of your choosing, so validation/save methods can be found in your class) makes XSP+PerForm even more similar to MSFT's ASP.NET (yet more powerful, obviously, because we have a better framework).
But going further on that I think there's more we can do on two fronts: more interactive forms, and easier to develop forms.
For more interactive forms I think we can do something more advanced with PerForm - adding features to automatically add in client side JS code where appropriate. I'd also like to think about how we can extend PerForm so people can create their own PerForm widgets, rather than having to stick to the default ones we provide.
In order to make form development easier it would be nice to have better external control of the flow of forms. This could be done with some sort of XML system, or we could look at developing something more complex like Cocoon's "Flow" system (though emulating that exactly requires continuations, which we don't have).
Unfortunately as with everything in Open Source, it's a matter of someone having to scratch this particular itch. I will soon be passing on this web project to someone else (job still open if anyone's interested), and so will be going back to full time spam detection. But I can certainly point people at what I think might be "quick wins".
Matt.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
