[Neurodebian-devel] How can Blends techniques be adapted to NeuroDebian

[Andreas Tille]

On Sun, Aug 26, 2012 at 12:05:11PM +0200, Michael Hanke wrote:
> 
> > I think if you don't know a fitting templating system I could write a
> > rst_output method and we might proceed from here.
> 
> I think we should not decide on a templating engine for the purpose of
> an interface for portal builders. Whatever decision we are going to
> make, the next blend will needs something else. I'd prefer to store the
> _input_ into whatever templating engine instead.

Could you please define "input" more precisely?

> In other words,
> something like a JSON (or similar) structure that holds the description,
> screenshot link, available versions, architectures per version, ... for
> each package. And that maybe wrapped into a larger structure that has
> all the packages per task (per blend).  If the information is broken
> down to a level where no markup in the respectives values is required,
> we should be able to feed that into ANY templating language and should
> hence be relatively future proof.

If I understand you correctly you mean the following:

  Current system:

     1. Script drains information from UDD and creates HTML pages
        using some templates

  Your proposal:

     1. Script drains information from UDD and creates some structured
        information in a to be defined format
     2. Another script generates
         a) Current blends pages using the just existing templates
         b) Dynamic pages as they are currently used by NeuroDebian
         c) Some other nifty things

Is this correct?

> If we have all the information aggregated in this way, we could even
> decide at some point to put it all back into a DB (if access latency and
> such ever becomes an issue). Since you must have all relevant information
> already represented in some form to be able to feed genshi, I'd assume
> that it should be relatively straightforward to export it right at this
> point, or am I wrong?

If I understand correctly than this is quite simple to do.  We just need
to agree about the format and I can easily do the output even in the
current script which enables a quite smooth migration path.  Considering
that I would like to have some "user response system" on the web
sentinel pages which is not possible with the current static pages I
consider to start a GSoC project next year to enhance this anyway which
somehow might be an argument to use a database (with the option to store
this input) as the "to be defined format" mentioned above.

So lets discuss this along these line.  Does this fit your proposal and
what database would you suggest?

Kind regards

       Andreas.

-- 
http://fam-tille.de