On Fri, 23 Mar 2007 10:07:08 +0100, Martijn Pieters wrote:
> PageTemplates have 2 rendering modes: HTML and XML. The HTML Mode
> lowercases attribute names, the XML mode doesn't. HTML mode is used
> unless the template starts with a proper XML prolog: <?xml
> version="1.1"?> and similar.
>
> 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.
>
> Sounds too much like implicit hackery to me. Vocabularies can
> distinguish between the value and the title, so why not set the value of
> 'All platforms' to the empty string? That's how LinguaPlone treats
> content as 'All languages', and makes for easy catalog searching too.
>
> Avoiding migrations is nobel, but putting hacks into the code like
> a-starting-dash-means-not-all-platforms is not worth it, IMO.
>
I'm aware that it's a hack, but from your reply I guess that I expressed
myself pretty badly.
I'll try to explain the problem making a couple of examples.
The matter is that DOAP needs to be able to say something like:
"My project runs (only) on an operating system named Linux."
or
"My project runs (only) on an operating system named Windows."
This also because the tag we're talking about is called "os" and hence
identifies more an Operating System rather than a platform. In case my
project does run on all OSes, the DOAP export will have to avoid setting
the "os" tag: we can think of the "os" tag being somewhat subtractive,
and specifying a subset only if my project doesn't cover the whole set.
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.
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.
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')]
I hope I made my case clear ;). That said, I'm aware that it adds a sort
of implicit hackery, and I'm the first one that would like to avoid it:
but considering the pros and cons of such a choice (against going for
say, turning availablePlatforms to a DataGrid field) I decided it was the
solution that offered the most advantage with less problems.
If anybody has a better solution, I'm all for it: and if you think that
the datagrid solution is better, I'll give it a look.
Cheers
Simone
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
