Menu
▾
▴
Re: [Lmappletserver-developers] CustomTableCellRenderer
|
From: Roberto M. <rob...@gm...> - 2007-12-02 19:14:05
|
Hi Peter,
I think that's a great idea, will add a metadata column with data type
bgcolor (for example) and value like "1006=3309:red" or
"1006=3309:#3366aa". It is easy to implement and maintain. I think this
is the simplest yet efficient way. Can I start implementing it?
I deployed the AirportWatch project but there are no pages like metalog,
should I put them my self in the project locally?
Regards,
Roberto
Peter Salomonsen wrote:
> 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...
> <mailto: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... <mailto: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... <mailto:rob...@gm...>> wrote:
>
> Hi Peter,
>
> Read comments inline.
>
> Regards,
> Roberto
>
> On Nov 26, 2007 7:41 AM, Peter Salomonsen
> <co...@pe...
> <mailto: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.getTableCel
> lRendererComponent. 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
>
>
|
