> Something like:
> <display:table id="row">
> <display:column property="name" media="csv,excel"/>
> <display:column property="name" media="html"><b><c:out
> value="${row.name}"></b></display:column>
>
> would otherwise be very ugly to implement.
I wasn't saying that's how we should do it, just suggesting an
alternative. I just thought that tiles might make sense if we are going to
customize output for one particular medium. Something like this:
<display:definition name="templateTable" media="html">
<display:column property="prop1"/>
<display:column property="prop2">
<a href="www.somewhere.com/${prop2}">some text</a>
</display:column>
</display:definition>
<display:definition name="templateTable" media="csv">
<display:column property="prop1"/>
<display:column property="prop2"/>
</display:definition>
These would be defined in an XML file similar to how tiles works. Then in
the JSP, you could just reference the templates:
<display:table template="templateTable" ... />
Then the table tag would render whichever output was most appropriate.
Just an idea. This may just make things too complicated, but could help
with our growing demand for absolute customization.
>
> Headers and footers are a separate issue; I think Fabrizio has been
> doing some work on footers.
I don't think we should be treating headers and footers as anything
special. If we were to implement the tiles-like structure, you could just
define the default headers and footers in the XML and allow complete
customization that way.
> I don't get it. I would think that, if the column body is
> provided, it should ALWAYS be output (this goes back to some
> emails last week:
> http://sourceforge.net/mailarchive/forum.php?thread_id=3506505&forum_id=
> 26581 .)
I guess I should have been more clear. I was just talking in the context
of HTML output. In that case, yes, the body JSP should always be
displayed. But for CSV, XML, or Excel output, it doesn't always make
sense. In my example above, in the HTML, you might display ${prop2} as
part of a link to another page. You wouldn't necessarily want to include
that in a CSV since it is display-specific code. At least in my
application I don't want to display it, and I just need the value of
${prop2} for generating reports.
I suppose that maybe I've taken all this a step too far. It does make
sense to handle the simple case of adding the media attribute, which will
solve some of the issues that our users are having. I think we might want
to investigate this idea further at some point. Unfortunately, planning a
wedding isn't leaving me with much time to spend writing code at the
moment!
+1 for adding the media attribute.
John
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
displaytag-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/displaytag-devel
