Joerg Heinicke wrote:
On 08.11.2004 14:10, Leszek Gawron wrote:

Imagine you have a bunch of java.util.Calendar properties all around your JavaBeans. Now in most of the views you want to render them according to a specific pattern.

Now there are some special cases when you want those dates to get additional styling as long as the date value meets specific criteria so there are two things that decide if the date should be additionaly emphasized:
- view template (some views may render the same property in plain format, some may want if emphasized)


That's pure presentation, no data involved. So put it into the view.

- date value (only the values that meet some criteria are being pretty printed)


That's dependent on data, so put a boolean property into the model (following Terrence Parr). In the view you can ask "if (meetsCriteria) { do emphasize }". A change on the criteria will result in changes to all views referencing the data.
got it. You're right.


Of course I see you add additional stuff to the model though it looks like presentation logic. But you still do not depend on the presentation. If a template asks for this property or not is not important.

I know that this may bring inconsistency among views but as long as only developer knows if the property should be styled or not there is no other way.


Don't know if you mixed something in this sentence, but this is exactly a reason for the above: if only developers know if property should be styled or not let them put a boolean property into the model.

I like Daniels comparison to a CSS class attribute.

Something like ${bean.startDate} or <jx:out value="${bean.startDate}"/> would use default renderer. Something like ${bean.startDate?class=emph} <jx:out value="${bean.startDate}" styling="emph"/> would point that other convertor is needed.

If you need your view to be reusable you can do it and choose convertors. The only thing is that your convertor should generate some markup that will be transformed later and not HTML/WML or anything specific.


I like it too. Nothing of Parr's arguments speak against it. You only must not depend on the data!
Super. The thing I was most scared of was that a simplistic StringTemplate would be main's cocoon WayToGo(tm).

--
Leszek Gawron                                      [EMAIL PROTECTED]
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



Reply via email to