Hi David, On 06/08/14 10:02 , Bernd Machenschalk wrote: > Oliver has already mentioned that we use this approach in the > BOINC-Drupal project and has pointed out the XML specification that was > developed there. I think it would save time and effort for all of us to > use this as a basis.
That's right. Let me give you some background/motivation first: We at Einstein@Home already replaced the stock code for handling project-specific preferences with a libxml2-based solution a couple of years ago because we wanted to use XML attributes which BOINC doesn't support out of the box. However, maintaining the set of project-specific preferences has still remained cumbersome, to say the least. Maintenance like that should require code changes after all. Since we're gearing up to move our project website to Drupal (which went live on our test project today!) we thought hard about how we could provide a much more elegant solution for preference handling. The overall goal was to provide a facility for project admins to just specify their specific set of project preferences easily, without the need to touch any code! This means we needed a way to let them specify the GUI elements as well as the structure of the XML fragment that gets persisted to the DB. This specification would then be uploaded to the website and processed by a parser which then constructs the GUI (view) dynamically. It also provides the structure that the view's controller/model then use to write to and read from the database. In order to facilitate that we came up with a kind of DSL by defining a suitable XML schema that allows for specifying all of the above in a single XML file. Thus the schema defines what the parser and the view have to (are able to) support. They are kept in sync by the developers (not the downstream project admins!). Based on that schema definition downstream project admins are then free to specify any set of preferences they wish. Their XML preference specification is of course validated during upload and only accepted when it's valid. All of this already exists in the BOINC repo, well, in our copy of it. It's ready to be pushed at any point - together with the rest of the generic BOINC/Drupal codebase. If this sounds interesting to you and if you are willing to implement a similar solution for the stock BOINC web code I'll be happy to share the details. I think it would be very useful to ease the maintenance work of all project admins. Cheers, Oliver
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
