[opensuse-buildservice] [patch] spec file wizard
Hi, I'm working on a new feature of the buildservice, a wizard that helps with creating spec files (and in the future maybe with other tasks). See http://lizards.opensuse.org/2008/05/26/learning-ruby/ . I now have a working prototype, including a webclient interface. It consists of - A controller on the api (frontend), that sends a set of xml-encoded questions to the client, receives answers from the client and either asks more questions (suggesting defaults where possible) or generates a spec file - A webclient part that converts the xml questions into a HTML form, let's the user fill in the form and sends the responses to the api. It should be possible to also write an osc command that asks the questions on terminal instead. Here are some screenshots of the webclient: http://michal.markovi.net/images/bs-wizard-2008-05-30-1.png http://michal.markovi.net/images/bs-wizard-2008-05-30-2.png http://michal.markovi.net/images/bs-wizard-2008-05-30-3.png http://michal.markovi.net/images/bs-wizard-2008-05-30-4.png http://michal.markovi.net/images/bs-wizard-2008-05-30-5.png http://michal.markovi.net/images/bs-wizard-2008-05-30-6.png http://michal.markovi.net/images/bs-wizard-2008-05-30-7.png http://michal.markovi.net/images/bs-wizard-2008-05-30-8.png http://michal.markovi.net/images/bs-wizard-2008-05-30-9.png An example of the an xml document describing the questions: $ curl -n 'http://localhost:3001/source/home:mmarek/hello/_wizard' <?xml version="1.0" encoding="UTF-8"?> <wizard last="false"> <label>Step 1/2</label> <legend>What do you want to package?</legend> <entry name="tarball" type="file"> <label>Source tarball to upload</label> <legend></legend> <value></value> </entry> </wizard> - label and legend are self-explanatory. - value is the default value to present to the user. - If the last attribute of the root element is true, it means that the client shouldn't send any further replies. - There can be an arbitrary number of <entry> elements, each representing a question to ask - The name attribute of an entry has the same meaning as in HTML forms - type can currently be one of - file: the client should PUT a file to the package directory in a *separate* request and send the filename as response (e.g. tarball=foo.tar.gz) - text or longtext: text data, longtext expects a multiline text (e.g. the package description) Client sends back either a GET request with the data in the query string or a POST request encoding the data either as application/x-www-form-urlencoded or multipart/form-data (i.e. anything rails handles). All communication with the API happens via the /source/<project>/<package>/_wizard url, which means that the client must first create the package by uploading a dummy _meta (see the wizard_new action in the webclient). To maintain it's state, the frontend stores a wizard.xml file in the package directory. I know it's a hack, but it seemed as the easies way for the time being :). $ curl -sn 'http://localhost:3001/source/home:mmarek/hello/wizard.xml' | xmllint -format - <?xml version="1.0"?> <wizard> <data name="name">hello</data> <data name="tarball">hello-2.3.tar.bz2</data> <guess name="license">GPL v2 or later</guess> <guess name="version">2.3</guess> </wizard> The patch is attached. Note that this my first ruby code ever (I started reading some tutorials this week), so please bear with me. If some of the ruby & rails experts have some time to review the patch for security, bugs, style, etc, that would be great. Michal
2008/5/30 Michal Marek <mmarek@suse.cz>:
Hi,
I'm working on a new feature of the buildservice, a wizard that helps with creating spec files (and in the future maybe with other tasks). See http://lizards.opensuse.org/2008/05/26/learning-ruby/ .
I now have a working prototype, including a webclient interface. It Very good, excited to see it in the web client and use it. Do yu plane to use it when we click on the edit link for an already existing spec file. Also i'm working on a Spec manager project : http://sourceforge.net/project/screenshots.php?group_id=226676 consists of - A controller on the api (frontend), that sends a set of xml-encoded questions to the client, receives answers from the client and either asks more questions (suggesting defaults where possible) or generates a spec file - A webclient part that converts the xml questions into a HTML form, let's the user fill in the form and sends the responses to the api.
It should be possible to also write an osc command that asks the questions on terminal instead.
Here are some screenshots of the webclient: http://michal.markovi.net/images/bs-wizard-2008-05-30-1.png http://michal.markovi.net/images/bs-wizard-2008-05-30-2.png http://michal.markovi.net/images/bs-wizard-2008-05-30-3.png http://michal.markovi.net/images/bs-wizard-2008-05-30-4.png http://michal.markovi.net/images/bs-wizard-2008-05-30-5.png http://michal.markovi.net/images/bs-wizard-2008-05-30-6.png http://michal.markovi.net/images/bs-wizard-2008-05-30-7.png http://michal.markovi.net/images/bs-wizard-2008-05-30-8.png http://michal.markovi.net/images/bs-wizard-2008-05-30-9.png
An example of the an xml document describing the questions: $ curl -n 'http://localhost:3001/source/home:mmarek/hello/_wizard' <?xml version="1.0" encoding="UTF-8"?> <wizard last="false"> <label>Step 1/2</label> <legend>What do you want to package?</legend> <entry name="tarball" type="file"> <label>Source tarball to upload</label> <legend></legend> <value></value> </entry> </wizard>
- label and legend are self-explanatory. - value is the default value to present to the user. - If the last attribute of the root element is true, it means that the client shouldn't send any further replies. - There can be an arbitrary number of <entry> elements, each representing a question to ask - The name attribute of an entry has the same meaning as in HTML forms - type can currently be one of - file: the client should PUT a file to the package directory in a *separate* request and send the filename as response (e.g. tarball=foo.tar.gz) - text or longtext: text data, longtext expects a multiline text (e.g. the package description)
Client sends back either a GET request with the data in the query string or a POST request encoding the data either as application/x-www-form-urlencoded or multipart/form-data (i.e. anything rails handles).
All communication with the API happens via the /source/<project>/<package>/_wizard url, which means that the client must first create the package by uploading a dummy _meta (see the wizard_new action in the webclient).
To maintain it's state, the frontend stores a wizard.xml file in the package directory. I know it's a hack, but it seemed as the easies way for the time being :). $ curl -sn 'http://localhost:3001/source/home:mmarek/hello/wizard.xml' | xmllint -format - <?xml version="1.0"?> <wizard> <data name="name">hello</data> <data name="tarball">hello-2.3.tar.bz2</data> <guess name="license">GPL v2 or later</guess> <guess name="version">2.3</guess> </wizard>
The patch is attached. Note that this my first ruby code ever (I started reading some tutorials this week), so please bear with me. If some of the ruby & rails experts have some time to review the patch for security, bugs, style, etc, that would be great.
Michal
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Petit Eric wrote:
2008/5/30 Michal Marek <mmarek@suse.cz>:
I'm working on a new feature of the buildservice, a wizard that helps with creating spec files (and in the future maybe with other tasks). See http://lizards.opensuse.org/2008/05/26/learning-ruby/ .
I now have a working prototype, including a webclient interface. It Very good, excited to see it in the web client and use it. Do yu plane to use it when we click on the edit link for an already existing spec file.
Probably not via the edit link, but there should be a possibility to launch the wizard inside an existing package. One use case that comes in mind is updating to a newer version. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
2008/6/1 Petit Eric <surfzoid@gmail.com>:
2008/5/30 Michal Marek <mmarek@suse.cz>:
Hi,
I'm working on a new feature of the buildservice, a wizard that helps with creating spec files (and in the future maybe with other tasks). See http://lizards.opensuse.org/2008/05/26/learning-ruby/ .
I now have a working prototype, including a webclient interface. It Very good, excited to see it in the web client and use it. Do yu plane to use it when we click on the edit link for an already existing spec file. Also i'm working on a Spec manager project : http://sourceforge.net/project/screenshots.php?group_id=226676 Seems like it's coded using Visual studio. Would be a good tool for me :-) consists of - A controller on the api (frontend), that sends a set of xml-encoded questions to the client, receives answers from the client and either asks more questions (suggesting defaults where possible) or generates a spec file - A webclient part that converts the xml questions into a HTML form, let's the user fill in the form and sends the responses to the api.
It should be possible to also write an osc command that asks the questions on terminal instead.
Here are some screenshots of the webclient: http://michal.markovi.net/images/bs-wizard-2008-05-30-1.png http://michal.markovi.net/images/bs-wizard-2008-05-30-2.png http://michal.markovi.net/images/bs-wizard-2008-05-30-3.png http://michal.markovi.net/images/bs-wizard-2008-05-30-4.png http://michal.markovi.net/images/bs-wizard-2008-05-30-5.png http://michal.markovi.net/images/bs-wizard-2008-05-30-6.png http://michal.markovi.net/images/bs-wizard-2008-05-30-7.png http://michal.markovi.net/images/bs-wizard-2008-05-30-8.png http://michal.markovi.net/images/bs-wizard-2008-05-30-9.png
An example of the an xml document describing the questions: $ curl -n 'http://localhost:3001/source/home:mmarek/hello/_wizard' <?xml version="1.0" encoding="UTF-8"?> <wizard last="false"> <label>Step 1/2</label> <legend>What do you want to package?</legend> <entry name="tarball" type="file"> <label>Source tarball to upload</label> <legend></legend> <value></value> </entry> </wizard>
- label and legend are self-explanatory. - value is the default value to present to the user. - If the last attribute of the root element is true, it means that the client shouldn't send any further replies. - There can be an arbitrary number of <entry> elements, each representing a question to ask - The name attribute of an entry has the same meaning as in HTML forms - type can currently be one of - file: the client should PUT a file to the package directory in a *separate* request and send the filename as response (e.g. tarball=foo.tar.gz) - text or longtext: text data, longtext expects a multiline text (e.g. the package description)
Client sends back either a GET request with the data in the query string or a POST request encoding the data either as application/x-www-form-urlencoded or multipart/form-data (i.e. anything rails handles).
All communication with the API happens via the /source/<project>/<package>/_wizard url, which means that the client must first create the package by uploading a dummy _meta (see the wizard_new action in the webclient).
To maintain it's state, the frontend stores a wizard.xml file in the package directory. I know it's a hack, but it seemed as the easies way for the time being :). $ curl -sn 'http://localhost:3001/source/home:mmarek/hello/wizard.xml' | xmllint -format - <?xml version="1.0"?> <wizard> <data name="name">hello</data> <data name="tarball">hello-2.3.tar.bz2</data> <guess name="license">GPL v2 or later</guess> <guess name="version">2.3</guess> </wizard>
The patch is attached. Note that this my first ruby code ever (I started reading some tutorials this week), so please bear with me. If some of the ruby & rails experts have some time to review the patch for security, bugs, style, etc, that would be great.
Michal
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (3)
-
long hong -
Michal Marek -
Petit Eric