Buildout Builder

All,

   A new demo is up.

http://xkenneth.homelinux.com:8080/lps-4.1.1/my-apps/work/buildoutbuilder/buildoutbuilder.laszlo/src/buildoutbuilder.lzx

Hit it quick before my IP changes! ( I’ll setup dyndns sooner or later. )

I’ll post a much more in depth post soon.

Regards,

Ken

I’m hosting this off of my home server, so of my IP changes or something the demo will go down (i just haven’t setup a dyndns updater yet.) The buildout viewer is up and running, and this proves out all of the basic mechanisms. The buildout DOM exchanges are working, as are the render and generate abilities. I will be uploading these to the PyPI for anyone that cares to work with a buildout in an XML model.

It doesn’t look like much, but %75 of the code base required to complete the project is already there.

http://xkenneth.homelinux.com:8080/lps-4.1.1/my-apps/buildoutbuilder/src/buildoutbuilder.lzx?lzr=dhtml

 The main parts left is the editor and render methods, which in and of themselves aren’t very complex, I hope to have them up and running in the next few days, and then the rest of the time will be spent adding features, such as drag and drop recipes.

Also, I’ve been really enjoying developing in laszlo, it’s a completely different mindset. I suggest you check it out, as well as pyroglyph.googlecode.com

All of the source code is available here.

http://github.com/xkenneth/buildoutbuilder/tree/master

(I will put all of this on googlecode at the end of the project.)

Regards,

Ken

All,

    I’m making good headway on the project, and I will be posting a demo tomorrow night. The backend is essentially complete, and I’m working on useability from the user perspective. The OpenLaszlo toolkit has proved to be amazingly flexible and fast.

   There were some concerns mentioned about using OpenLaszlo for the project, mostly focusing on the point that it would be hard for a generic python developer to pick up the code. OpenLaszlo code is very simple, easy to understand XML, with embedded JS for scripting. While I agree there will be a learning curve for the average python developer, the project will be much more maintainable (and simpler) than if I had attempted to complete the project with KSS/Ajax ontop of vanilla grok. I would also be spending a good deal of time re-inventing the wheel if I had stuck with straight KSS/ajax.

- Ken

  All,

     I’ve been quite satisified with developing on a combined OpenLaszlo/Grok platform. Creating the user interface for the BB is on an order of a few magnitudes simpler than with plane grok/kss. I have found grok as an extremely simple to use persistent backend (as a replacement for CGI,) and I plan to develop further applications in the future on the combined model.

 Here’s a quick update of where I am:

Goal - 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.

Status -  Basic functionality is done. Needs some good unit tests and will probably see a revision or two.

Goal - Extend the current grokproject to use the built in RESTful capabilities of GROK.

Status - Not yet in progress.

Goal - Simple OpenLaszlo interface. (Of course the biggest part of the project is described by the shortest sentences.)

Nearing an acceptable stage for demonstration. Keep posted.

Regards,

Ken

 All,

Here’s a quick status update as to where I am on the project.

Goal - 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. 

Status - The basic DOM has been hashed out and the functions for generating the buildout DOM are nearly complete.

Goal - Extend the current grokproject to use the built in RESTful capabilities of GROK.

Status - Not yet in progress.

Goal - Simple OpenLaszlo interface. (Of course the biggest part of the project is described by the shortest sentences.)

 In the past few days I’ve become very familiar with OpenLaszlo and also learned javascript. I’ve had very little javascript experience in the past, but OpenLaszlo did not prove to have much of a learning curve. I will have a working demo very shortly.

 Expect updates almost daily from this point on.

 Regards,

Ken

 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

All,

   It’s been a while since my last update but here goes!

 Edit Interface 

 I spent this weekend getting rather familiar with grok and KSS. I have to say I really enjoy working in Grok, and not having to write any Javascript to use AJAX is a huge benefit. I’ve nearly finished working on the basic edit interface for buildouts; it should be flexible enough for generic buildouts. I’m also hoping to be able to code in some nice drag and drop capabilities to make editing very smooth.

 Pre-Configured buildouts

The earlier model for distributing buildouts only allowed one buildout per solution, which is fine for a simple buildout. Recently I’ve noticed that solutions like plone4artists use a number of hierarchal buildouts, which would be impossible to distribute with the previous model. Therefore I’ve modified the buildoutbuilder source code to read compressed tarballs containing all of the buildouts/files pertaining to a particular solution. The users are able to view all of the buildouts in the tarball, as well as download it. This is a very easy model for presentation and distribution.

 Subversion thread

I’ve been thinking of writing a background thread that runs once a day or so, to automatically check listed repositories for the latest revs of common buildouts (like p4a), download them, and compress them for distribution/viewing. This should save us a lot of time, and work to keep the site concurrent without the need for human interference.

 Git

I’ve migrated my source control to git after becoming completely frustrated with subversion. (I got really tired of typing “cd trunk”, you can read more about that here: http://xkenneth.blogspot.com/2008/06/goodbye-svn-hello-git.html)

The git repository is located here:  

http://github.com/xkenneth/buildoutbuilder/tree/master

More to come!

Regards,

Ken 

So my self-imposed date for phase 1 has come and past, but did I meet my requirements? Well let’s see….

May 26th: Discuss and finalize options for hosting the Buildout Builder. Begin initial code work. Phase one begins.

 Check.

Week One (May 26th to June 1st): Familiarization with buildoutsystem. Hand pick selected stack configurations and test buildouts.

 I didn’t get as far as I’d like in configuring and selecting the buildout deployments, but this looks like it might be a longer ongoing task for the entirety of the project.

Week Two (June 2nd to June 8th): Begin grok development, initiate website design.

Check.

Week Three (June 9th to June 15th): Develop a backend to thebuildout system inside of grok, complete with unit tests. Populate the site with selected stack configurations in an automated, extensible manner. 

 Check! The unit tests aren’t as nice as I’d like, but they’re there.

I’m working on getting a demo of the current version up on the slice provided by dennisharrison, I’ll update again when that’s ready.

Regards,

Kenneth Miller 

So the PartManager seems to be working now, i was able to decompose a buildout into it’s representative objects, recompose it back into a file, and the build the buildout!

Everything was rearranged (sections appeared in a different order, as well as options, although multi-line options remained unaffected,) but the buildout worked fine! If anyone’s interested it was the plone4usergroups buildout.

You can download the source and give it a try, just hand PartManager.py a URI to a buildout.cfg as the first command line argument. If you want to play with the PartManager and it’s respective arguments you can just call a PDB.set_trace() before it spits it back out to a file.

Regards,

Ken