On 3/23/07, Simone Deponti <[EMAIL PROTECTED]> wrote:
> In short: put a XML prolog at the start of your template and be done
> with it.
Oh great, I didn't know that: and you can also set the mimetype? Still, I
plan on switching on rdflib for the generation of the feed.
Grr, it appears I was wrong here. *Normally* you can set a template to
be interpreted as XML when starting it with the XML prolog. This is
certainly the case for pure Zope 3 views, and also for CMF skin page
templates. In such a case, the content type is also set to 'text/xml'.
However, Five's wrapper doesn't set the content_type properly, so it
still will interpret the template as HTML, and emit an incorrect
content type. The latter can be corrected by setting the CT header
from your template, but that won't help in your case.
This is a bug in Five, and I'll file it as such.
I'm aware that it's a hack, but from your reply I guess that I expressed
myself pretty badly.
I understood that DOAP specifies that the os tag should only be set
when the product is limited to that platform only, and not at all when
it runs on all platforms.
The second problem I had to face is that the platform for PSC is defined
at release file level, while DOAP wants it to be associated to the
project. I solved this by aggregating all the platforms specified in all
the releases files contained in the project.
Example:
My project has two releases: 0.1 and 1.0. My Project 0.1 was released as
source code ("All platforms") and with a Linux build ("Linux"), and 1.0
was released with three builds; Linux, Windows, Mac OS X and no source.
The doap export will say:
"My project runs (only) on an operating system named All Platforms."
"My project runs (only) on an operating system named Linux."
"My project runs (only) on an operating system named Windows."
"My project runs (only) on an operating system named Mac OS X."
And this is clearly wrong.
Yes, I understood that.
I discussed this with Martin (Aspeli) and he suggested we needed to be
able to find a way to define, for each attribute, if it was to be treated
by DOAP as "All platforms" (hence, if encountered in an export, would
make the export "omit the tag os"). This would have probably meant
turning the availablePlatforms attribute from a Lines field to a Datagrid
field where people would have had to put something like:
All Platforms|True
Linux|False
Windows|False
Mac OS X|False
At this point I thought: although we should try to support all the
possible cases, how many times the user will need to delete "All
platforms" from the list of available ones? Probably very few times.
Agreed.
So my idea is to keep the current Lines field, and have the first line to
implicitly have the "I am an all platforms line" set. In the (rare) case
where your setup explicitly wants to forbid the deployment of a release
file suitable for all platforms, you need a way to skip the first line.
So in the availablePlatforms field you have
-
Linux
Windows
Mac OS X
And the vocabulary returned to the DownloadableFile and Link File simply
says:
[('Linux', 'Linux'),('Windows', 'Windows'),('Mac OS X', 'Mac OS X')]
This is where my hack-alert goes buzzing and wailing like mad, and
where my suggestion comes in.
Just have administrators of PSC specify the platforms as a lines
field, but have the vocalubaries return [('', 'All platforms'),
('Windows', 'Windows'), ..etc..].
In other words, hardcode the All platforms option (with an empty
string as the stored value). Keep it simple, no hackery required with
'-'.
The feature to *not* list an 'All platforms' option is a YAGNI, a "You
ain't gonna need it" feature. By ditching it you avoid the whole
problem of LinesField vs. DataGrid altogether.
As an added advantage, you can now have 'All platforms' translated.
--
Martijn Pieters
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
