Hi Daniel,
Disclaimer: I don't pretend to know anything about BeanModels,
BeanModelSources and Grids.....however
Sounds like a bit of reflection to get field names on your POJOs and
BeanModel.exclude().exclude().exclude().....exclude() or a bit of
recursion til the end of an arraylist of empty/whitespace field values is
reached.
Without actually having done either in years, am i being simple?
Sounds kind of like in network programming with sending results to
specific clients, each connected in their own thread - it's just iterating
a list - not pretty but fast. Or reading bytes out of a buffer - again,
not an elegant task, but fast.
Chris
On Wed, 24 Sep 2014 23:39:59 +1000, Daniel Jue <teamp...@gmail.com> wrote:
Thanks Lance, I think on the surface my problem seems like the one you
gave
the answer for, but in my case it's different. I don't know which fields
I'll need to exclude until I know whether the value is null or
empty-string
for the instance of the bean. For example, one of my classes is a POJO
generated from elsewhere which has dozens of fields. For any given
instance of that POJO, only 30% of the field might be filled with
meaningful, non blank data. But it's not always the same columns/fields
that need to be skipped/excluded. I don't want to write manual glue code
for these, because they are code generated from a schema that changes
often. (not to mention I have close to 100 of these bean types already)
My first attempt at using my own MeaningfulBeanDisplay component based
off
BeanDisplay is not doing what I want yet. Seems like it's hard to get a
handle on the value that the propertyModel is going to try and resolve,
since it needs to go through the BeanDisplay's PropertyDisplay component
before we start to touch the actual value.
On Wed, Sep 24, 2014 at 1:40 AM, Lance Java <lance.j...@googlemail.com>
wrote:
BeanDisplay, BeanEditor and Grid all use a BeanModel to show the fields.
You could either set the "exclude" parameter to the component. Or you
can
call BeanModel.exclude(...) explicitly.
It might be easiest to decorate the BeanModelSource service in
tapestry-ioc
(used when you don't explicitly provide a BeanModel).
--
Using Opera's mail client: http://www.opera.com/mail/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
