Re: [Lmappletserver-developers] CustomTableCellRenderer

[Peter S. <co...@pe...>]

Hi Roberto,

Your concern about the complexity and performance is very important. The
suggested xml would solve the case, but as you say would lay very heavy
processing on the client. Another concern is that I just remembered that the
xml parser is not default in java 1.5 (comes with java6), which also means
that the applets will be much larger (xml parsing libraries are big). We
still have to support java5 since java6 is not yet supported by default in
Mac OSX.

At this point my need is to be able to set a criteria for one column, and
it's sufficient that the string matches - so I don't really need at this
point the possibility to match complex conditions. Could maybe be solved
using a properties file, but if we then in the future decides to go for more
complex matches, xml is a much better configuration scheme.

Another way, that I just thought about is to put the logic for setting
colors on the server, and rather introduce a MetaDataType just like the
media column, but instead let the value be a color. Just like you recognize
multimedia columns, you'd then recognize a "color column" and use the
information from this to set the color of the row. How do you think this
would work?

regards,

Peter

On Nov 29, 2007 6:43 PM, Roberto Milev <rob...@gm...> wrote:

> Hi Peter,
>
> Making a configuration file like this:
>
> <color-renderer>
>     <metadata-id priority="1">
>         <id>1006</id>
>         <condition>
>             <value>3309</value>
>             <relation>eq</relation>
>             <color>red</color>
>         </condition>
>         <condition>
>             <value>3310</value>
>             <relation>eq</relation>
>             <color>red</color>
>         </condition>
>         <combine-type>or</combine-type>
>     </metadata-id>
>     <metadata-id priority="1">
>         <id>1006</id>
>         <condition>
>             <value>3300</value>
>             <relation>gt</relation>
>             <color>yellow</color>
>         </condition>
>         <condition>
>             <value>3310</value>
>             <relation>lt</relation>
>             <color>yellow</color>
>         </condition>
>         <combine-type>and</combine-type>
>     </metadata-id>
>     <metadata-id priority="1">
>         <id>1006</id>
>         <condition>
>             <value>3300</value>
>             <relation>lt</relation>
>             <color>blue</color>
>         </condition>
>         <condition>
>             <value>3310</value>
>             <relation>gt</relation>
>             <color>green</color>
>         </condition>
>         <combine-type>none</combine-type>
>     </metadata-id>
> </color-renderer>
>
> would solve all possibilities for making a complicated conditions, for
> example this xml file sets the row color to red if its 1006 column has value
> of 3309 or 3310, yellow if the column value is in range of 3300 to 3310,
> green if value is greater than 3310 or blue if less than 3300, where the
> exact value ("eq" relation condition) has superiority when setting the
> color if two conditions overlap. If another metadataId is compared, then
> superiority will be given to the metadataId containing greater priority
> attribute in the config file.  A static method (getting all row values in a
> list) will be created that will decide and return what color should be used
> for the row. The only thing that concerns me here is the speed of the
> application when big conditions are created, or there are a lot of table
> rows, because the color checking operation will be performed for each row.
>
> Regards,
> Roberto
>
>
> On Nov 29, 2007 3:41 AM, Peter Salomonsen <co...@pe...>
> wrote:
>
> > Hi Roberto,
> >
> > The basic need is to be able to set a color for the entire row based on
> > a value in a column. So the configuration would basically be to set a
> > metadata-id, and set a criteria for matching a value. You should be able to
> > set up multiple criterias that each assigns to a separate color for the
> > entire row.
> >
> > I've done some thinking and found that it's possibly better to skip the
> > idea of having custom renderers. In the future we can look at possibilities
> > for referencing custom rendereres in the defaultrenderer config file. But
> > until then you can put the color-config logic and the mms play buttons in
> > the default renderer. So we'll just use the current CustomRenderer as a
> > default renderer.
> >
> > Would you start looking at a color configuration like described above?
> >
> > regards,
> >
> > Peter
> >
> >
> > On Nov 28, 2007 5:45 PM, Roberto Milev < rob...@gm...> wrote:
> >
> > > Hi Peter,
> > >
> > > Read comments inline.
> > >
> > > Regards,
> > > Roberto
> > >
> > > On Nov 26, 2007 7:41 AM, Peter Salomonsen <co...@pe...>
> > > wrote:
> > >
> > > > Hi Roberto,
> > > >
> > > > I've looked at your CustomTableCellRenderer and see that you've put
> > > > the multimedia play button in there. At the same time I'm in the process of
> > > > creating another CustomTableCellRenderer for another project.
> > > >
> > > > The purpose of the tablecell renderer is to able to plug in your
> > > > own, but this won't work default logic is stored in CustomTableCellRenderer
> > > > (which will be replaced in other projects). If this class grows with default
> > > > logic - then there will be a lot I have to paste into other custom
> > > > renderers, and especially when talking about upgrades it will be hard to
> > > > maintain.
> > > >
> > > > Today I invoke getViewerTable().setDefaultRenderer() on a
> > > > MetaDataLogViewer object to replace the default renderer. If the multimedia
> > > > play button needs to be triggered from the renderer, then we maybe need to
> > > > introduce a default renderer that is always there - and this default
> > > > renderer can invoke another custom renderer.
> > > >
> > >
> > > This can be done, by creating a configuration file that can map the
> > > cell types to a specific renderer, for example for multimedia context a
> > > MultimediaRenederer can be mapped, and when the default renderer will be
> > > called than the getTableCellRendererComponent method will check the mapping
> > > and call the appropriate MultimediaRenederer.getTableCellRendererComponent.
> > > If no mapping is present, than the default renderer will be called. Shoud I
> > > start working on this?
> > >
> > >
> > > >
> > > > In addition to this design issue, I'm also considering a way to
> > > > configure basic rendering properties, such as background colors. If we
> > > > introduce a default renderer, then it might be possible to have a
> > > > configuration mechanism for this renderer ( e.g. an xml file), where
> > > > you also could configure colors based on search results values... If one was
> > > > to have specific behaviours this xml could reference class names that
> > > > contained the behavior logic...
> > > >
> > >
> > > I have problems understanding this concept, can you describe your idea
> > > in more details. For example: what will be the condition to make a decision
> > > on what color to use?
> > >
> > >
> > > >
> > > > Could you look at such a configuration mechanism, give a config file
> > > > proposal, and setup an example in the AirportWatch project?
> > > >
> > > > regards,
> > > >
> > > > Peter
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Roberto Milev
> >
> >
> >
>
>
> --
> Regards,
> Roberto Milev