Yes, I misunderstood who Jazzwire was.

I did read Jazzwires original post when it was made - which I agreed with it as an idea, but the point I'd make is that each template is made up of 3 files in his scenario [or 3 logical parts of a single file].
1 For the header, 1 for the 'body' ( the repeated bit for evey tune/playlist) and then 1 for the footer

So thats 3 files/sections to be managed on the Empeg - no problem, except we have to agree what goes in the file in terms of content, special tokens to act as placeholders and styling etc, it also assumes that this structure is enough for our needs - on the surface, yes it does sound ok & we have to have some way to get those files to the empeg in the right place and manage them somehow [as presumably they are not edited on the empeg itself]. And all of that is do-able.

Then you immediately said (more or less) 'but I'd want every other line implemented in alternating colour in my version" ala the Emplode listview.

So suddenly the original implementation needs to be extended to handle odd/even lines in different colours.

No problem there either, except Mark Lord has to implement it somehow, so do we now implement this using 4 templates/sections - header,footer and Body A, Body B templates?

Then, what if someone says, well I would use this except I want either pair of tunes/playlists to be alternating in colour not just every line, and maybe someone else wants to have all Playlists in a different colour from Tunes (more likely given that Playlist contain tunes it useful to show them in a different colour again from odd/even lines in the body).

So, the feature set grows and grows - all of which we expect Mark Lord to put into the Kernel and support - yes we maintain the file contents but the file parser and serialiser to produce the HTML on the fly has to be written by Mark and extended as our needs extend.

And thats before we have even dealt with Platform/Browser/CSS whatever implementation issues for HTML to be emitted.

FWIW: The above feature set of header/footer, alternating body line colours and tunes and playlist in different colours in the table is what I could live with in a template solution.

But its not the full answer to customising the playlists.


Which is why I suggested we apply a simple(r) solution - output a XML file of ALL the information in the *1 files (or the Database), in a structured way that fully describes the current playlist - then let the consumer of the XML choose what format to render it into - HTML for you/your web browser, CSV for someone else, XYZ format for someone else (and what data to show, and what to suppress etc)

Mark could produce a XML version of the playlist pretty easily I would think - provided he had a XML structure to follow that allowed for both Playlist and tunes (and for the nesting of these).

The issue with this is then - where is the XML that is emitted, actually consumed/processed?

Given that a full XML parser implementation on the Empeg would take quite some some resources [e.g. someones time to port a XML parser from elsewhere and the memory usage when its running], it has been suggested [by others as well as me], that we off-load this processing to the Client application who requests the XML data in the first place rather than have the Hijack kernel have to do it.

Since XML also allows us to specify a XSLT tranformation that we want to apply to the XML, we can also have the rendering from XML into HTML suitable for a browser to work with, done on-the-fly by the client, provided we put a reference to the XSLT file in the XML file we produce and that have a web browser thats up to date enough to be able to transform the XML file using the XSLT reference in the XML.

As a nice simple to have extension then we also would like to be able to tell the Hijack Kernel where the XSLT that we want to process the XML with is located - and we provide that on the URL we give to the Hijack http server when we request the XML playlist in the first place - this lets us all share our xslt files that render html versions of our playlists so that others can use it.

Thats it. I think thats pretty simple. The only issues with this approach are:

1. What should the XML file look like? - so Mark can program it.

2. Who will write the XSLT's for the various platforms/browsers out there that support XSLTs in XML?

While I have no simple answer for 2, there are lots of people around this BBS now who can write XLST's well enough to do whats required to produce pretty sophisticated html pages from the XML, theres even some offering to do it now in this very thread. I'm putting my money where my mouth is - I'll produce & publish a XSLT of the playlist that will work in W3C compliant parser as well.

I'm not knocking Jazzwires idea, or yours, I merely caution everyone that we can only avoid lots of trips to and fro to Mark to get this, or that feature added if we do it the right way to start and have a clear idea that the template idea is a reasonably short term workaround/quickfix and no more.

So to move forward - I suggest that we ask Mark to start with a simple template file(s) idea and have the XML export implemented soon after. This will allow a customisable playlist in HTML for those of us who want nice(r) semi-customisable playlist in their browsers now, with the more flexible (fully customisable) XML feature useful for the really advanced stuff and modern web browsers that can support XML into HTML on the fly.

I'll let you guys come up with the Template solution that fits your needs.

If anyone wants to contribute to the designing of the XML file then let me know/start another thread or whatever - once we have a XML file layout, we can then give it to Mark and let him program it, then we can document how the file works, produce some XSLT's that work with it and then put it up on RioCar.org or whereever.