>Nico Klasens wrote:
>> You only have to do something like this
>> 
>>      <item displaytype="image">
>>              <field ftype="data" name="title" />
>>              <field ftype="startwizard" 
>wizardname="config/images/images"
>> />
>>      </item>
>> 
>> The displaytype will instruct the editwizard to genereate a img-src to 
>> the imageservlet. The imageservlet does only support one field 
>> (handle) so why should the editwizards support more?
> 
> I find it no matter of support but of clear syntax. I think 
> it would make complete sense that if you type <field 
> ftype="data" name="handle"
> /> that it should than generate a img-src to the 
> image-servlet? What else should it do?

Generate an a-href download link for the attachment handle?

The editwizard generate the attributes dttype and ftype for every field in
the xml which is passed to the xsl-translation.
For the image-handle they are dttype='binary' and ftype='image'
For the attachment-handle they are dttype='binary' and ftype='file'
When the ftype is changed to data then the xsl can't determine what it is.
Solution for this is to add an extra ftype imagedata

  <xsl:template name="ftype-imagedata">
   <img src="{node:function($cloud, string(@number),
concat(&apos;servletpath(&apos;, $cloudkey, &apos;,cache(&apos;, $imagesize,
&apos;))&apos;))}" hspace="0" vspace="0" border="0"
title="[EMAIL PROTECTED]&apos;description&apos;]}"/>
  </xsl:template>

> 'displaytype="images"' would not have been needed, and would 
> not need documentation.

A neat thing about the displaytype is that it displays the image next to all
other fields. An extended wizard.xsl could use the displaytype to display
the list items differently. It is one of the extension points in the wizard
definitions to influence the generated html for the wizards.

> Btw, your point that image-servlet can only serve 'handle' is 
> good, it seems easy to fix that when it is needed, but I 
> hardly think it currently is, because I've never heard any 
> complaints from someone who wanted 2 handle fields in his 
> record or so. But it is imaginable, perhaps we'd ought to 
> make it possible once...

An Extreme programming rule: Do The Simplest Thing That Could Possibly Work.
The requirement now is to have one handle field and the current
implementation does work. No idea why it should be over-designed.

Nico

_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers

Reply via email to