Trying to create a rich ajax web app with grok and KSS is stupid.
I’ve been playing with different ways to build the editable interface for the project using grok/KSS for a while now, and it’s honestly time consuming, repetitive, and painful. I realize there’s probably better ways to do the things I’ve been doing, but why should I have to write code that handles basic things like buttons, etc? I don’t care to write a user interface layer ontop of grok/kss because I’d be wasting my time and rewriting code that already exists.
Why is it stupid?
So, in different sections of the editable buildout I have these little “+” signs that allow you to add a new option or part, etc. So, when you click the “+” sign, a simple inline form appears to allow you to enter your content. In order to achieve this I have to MAP a KSS method to the button and replace its HTML in the DOM with said method. To me this is a bit nasty, and requires you to do tricky things with the elements class and id parameters to get it to work. Once the form is finished you need to have a submit button mapped to another KSS method that allows you to validate the data, and then replace the original form HTML in the DOM, with a rendered view of the new object. To me, it seems like there has to be a better way to do this. It would be really nice if you could have synonymous operation to Zope Schema’s (Create/Edit form views) through ajax. This might be possible, I however just don’t know how to do it.
So i started playing around with OpenLaszlo…
I saw OpenLaszlo in Linux magazine a while back and I remember being extremely impressed. I looked through all of the examples, and it seems to handle everything I want to do. I have to say at first inspection, Laszlo markup doesn’t look anywhere near as clean as python code, but mayb e it will grow on me. I downloaded OpenLaszlo and within 5 minutes I had a simple App running that could retrieve a DOM from a running Grok project. OpenLaszlo will give me a much more powerful framework for user interaction.
Where I’d like to go from here…
In my mind right now I see two final products. A grok application that works as a backend RESTful data source with a few attached RPC methods, and an OpenLaszlo frontend to handle user interaction. The OpenLaszlo frontend will handle browsing preselected buildouts, and providing the user with an easy to use interface for editing buildouts.
Why do i want to do this?
I believe seperating the application into these two distinct entities, will result in much more functional and cleaner code. Also, the backend will provide a good platform for building other tools in the future.
What needs to be achieved…
A simple structure for representing a buildout in a DOM. This will be the standard interface method between the front and back ends.The front end should be able to make changes to a DOM and post them back through a RESTful interface. I’d like to use lxml for most of this.
A function to generate a buildout from the representative DOM and vice verse. Should be rather easy to do.
Extend the current grokproject to use the built in RESTful capabilities of GROK.
Simple OpenLaszlo interface. (Of course the biggest part of the project is described by the shortest sentences.)
Data Flow Questions?
How would the user upload a pre-existing buildout?
The user would upload the file, OpenLaszlo would pass it to the backend through a RPC call to retrieve a DOM representation that would then be loaded into the editor.
How would the user download a created buildout?
Similar as above, except the RPC call would return the serialized buildout file, or a URI to it.
Please let me know if you have any more questions, this is all I can think of for now. As always I’m motivated to create the highest quality output and provide the best user experience. If anyone disagrees with any of this, please let me know.
Regards,
Ken
